EDI and SAP: the plumbing nobody thanks you for

Integration is the only part of enterprise technology that is judged entirely by its absence.

In February 2025 I completed the Pro5 technical assessment for Technical Analyst in EDI and SAP integration, and was recognised in the top 5 percent. Preparing for it made me think properly about a layer of enterprise technology that most people never see and only notice when it stops.

Invisible by design

When integration works, nothing happens. An order placed in one company's system appears in another's. An invoice arrives already structured. A shipping notice updates a record without anyone typing.

Nobody sends an email about that. But when it breaks, it breaks with consequences that are immediately commercial — goods that cannot be released, invoices that cannot be matched, a partner ringing about a document they say they sent three days ago.

Standards that are not quite standard

EDI formats like X12 and EDIFACT are the agreed vocabulary for this exchange. In principle a document type has a defined structure, so two organisations that have never spoken can transact.

In practice, every trading partner has interpretations. An optional segment that one partner always sends and another never does. A field used for a purpose slightly different from the specification because it has been that way for fifteen years. A qualifier that means something particular to one industry.

So integration work is rarely about the standard. It is about the gap between the standard and how a specific partner actually behaves, and that gap only appears in production traffic.

The specification tells you what should arrive. The logs tell you what does. The difference between them is the job.

Where ERP makes it harder

Mapping into an ERP such as SAP adds a second problem. The inbound document has to become a transaction that satisfies the receiving system's own rules — master data that exists, values within tolerance, references that resolve. A message can be perfectly valid EDI and still fail, because the customer record it points at was blocked last week.

This is why integration troubleshooting is a distinct skill. The failure is usually not in one system or the other. It is in an assumption at the boundary that both sides believed the other was handling.

Why it matters for automation

Everything I do in process automation sits on top of this layer. An automated finance process assumes data arrives in a known shape at a known time. When integration is unreliable, automation inherits that unreliability and passes it on with more confidence than it deserves.

So I treat integration quality as an automation prerequisite rather than a separate concern. If the input is not dependable, the correct next step is fixing the input, not building something clever to compensate for it.