Skip to main content
Back to the blog
Enterprise8 min read02 October 2026

Connecting EDIFACT to SAP: architecture, flow and typical mistakes

How an EDI connection to SAP should be built: inbound, validation, mapping, hand-over and monitoring. With the most common mistakes from practice and how to avoid them.


Anyone who exchanges EDI with customers or suppliers knows the picture: messages arrive, some go through, others end up on an error list that someone works through by hand. The problem is rarely the format itself. It is almost always the architecture in between.

The five stages of a robust connection

1. Inbound

Messages arrive via AS2, SFTP, VAN or API. Every message is archived unchanged before anything else happens to it. Without the original, no error can be traced properly later.

2. Validation

Check the syntax (is this valid EDIFACT?), then the content (does the article exist, is the partner correct, are quantities and dates plausible?). Errors are caught here, not later in the ERP.

3. Mapping and enrichment

The message is converted into the target format, for example an IDoc or a REST call. Partner-specific rules belong in a maintained mapping table, not in special cases scattered across the code.

4. Hand-over to SAP

The hand-over must be idempotent: if the same message is processed twice, no duplicate order may be created. A unique reference per message is mandatory for this.

5. Monitoring

Every message has a status, every error a cause and an owner. Problems are reported before the customer calls.

Typical mistakes from practice

  • •Errors are detected too late. If validation only happens in the ERP, follow-up errors have already occurred.
  • •No idempotency. Repeated transmissions create duplicate orders.
  • •Mapping as spaghetti. Every new partner gets its own special logic until nobody knows why something works the way it does.
  • •Monitoring via a shared inbox. Error messages land in a shared mailbox and get lost there.
  • •No reprocessing. After an outage, someone has to replay messages by hand.
  • What this can mean in numbers

    At a manufacturing company I rebuilt the order processing along exactly this pattern. Result: more than 90 % fewer processing errors at more than 4,000 records a day. Details are in the case study.

    How to start

    The first step is not a technology decision but an assessment: which partners, which message types, where do errors happen today and who fixes them? That tells you whether a single connection is enough or a central integration layer makes sense.

    Suitable entry points are the interface analysis or an EDI connection directly, both on the page EDI and SAP integration.

    Planning a project?

    Free initial call, no obligation.