EDI Integration: Coupling EDIFACT to the Shop 2026

EDI stands for Electronic Data Interchange, the automated exchange of business documents between the IT systems of two partners without manual intervention. EDIFACT is the standard that dominates this in Europe: a rule set maintained by the United Nations that defines how an order, a delivery note or an invoice looks as a sequence of segments and data elements. While ANSI X12 is widespread in North America, Europe predominantly uses UN/EDIFACT (Wikipedia, EDIFACT). An EDIFACT message is not made for humans: it consists of segments such as UNB for the envelope, BGM for the document header and NAD for addresses, each with delimiters rather than plain-text field names.

This compactness is both a strength and a hurdle. It keeps the exchange lean and machine-readable but requires a translation into the shop's data model. More than 160,000 companies worldwide now use some form of EDI, processing over 23 billion transactions annually (market.us, EDI Software Market). For a Shopware CE shop this means: as soon as large trading partners, suppliers or retail chains appear as customers, there is rarely a way around EDI. The integration happens not in the shop itself but in an upstream integration layer that translates EDIFACT into API calls and back.

Economically the trend is clear: the global EDI market is projected to grow from USD 36.58 billion in 2024 at an annual rate of 12.1 percent to USD 91.22 billion by 2032 (Fortune Business Insights). The drivers are cloud-based EDI solutions and increasing B2B integration. Those who open their shop to trade with large partners benefit from this standardization but must build the bridge between EDIFACT and modern API development deliberately and cleanly rather than treating it as a sideshow.

A small number of message types appear especially often in the order process between trading partner and shop. The EANCOM subsets, a variant of EDIFACT maintained by the standards organization GS1, single out ORDERS, DESADV and INVOIC as the three most frequently used messages (GS1, EANCOM). They form the core of the order-to-cash flow: order, despatch advice and invoice. They are complemented by technical acknowledgements that confirm a message has arrived in syntactically correct form.

Each partner can fill the same message type slightly differently, because EDIFACT allows many optional segments and organizations define their own subsets. In practice this means: an ORDERS from partner A is not one-to-one the ORDERS from partner B. This is precisely why every integration needs its own partner profile with its own mapping. A well-designed interface concept models these profiles cleanly separated, so that a change for one partner does not touch the others.

The heart of any EDI integration is the converter. It receives the raw EDIFACT message, decomposes it into its segments and data elements and maps them onto the data model of the target system. An incoming ORDERS thus becomes an order object with customer, line items, quantities and prices, which the shop or ERP accepts via its REST or GraphQL API. In the other direction the converter produces a valid EDIFACT message again from a shop object, such as an INVOIC from a finished invoice.

The example shows the basic structure: UNB opens the envelope with sender and receiver, UNH names the message type and version, BGM carries the document number, NAD the partner address and LIN together with QTY an order line with quantity. The converter reads these segments and writes their values into the fields the shop expects. A pure format conversion is not enough: codes must be translated, units checked and article numbers mapped onto internal identifiers. This business logic belongs in the middleware, not in the shop, so that the shop's core functions stay lean.

An EDIFACT message must reach the other system securely. Three transports dominate B2B data exchange, and the choice depends on industry and partner. AS2 is defined in the IETF specification RFC 4130 and is based on HTTP and S/MIME (IETF, RFC 4130). It wraps EDI messages in standardized MIME structures, signs and encrypts them and returns a signed acknowledgement in the form of the Message Disposition Notification, MDN for short. AS2 has established itself as the de facto standard through its adoption in retail (Wikipedia, AS2).

OFTP2 is the current version of the Odette File Transfer Protocol and is common in the automotive sector. It offers data compression, file encryption and the exchange of digital certificates between partners (Odette, OFTP2). SFTP is the simplest path: an encrypted file transfer over SSH where a key pair suffices and no certificate exchange is needed. The price of this simplicity is that SFTP knows no acknowledgement at the protocol level; a business CONTRL or status response must then be organized separately. Which variant fits is decided by the middleware design per partner; an integration often runs several paths in parallel.

Before an incoming message flows into the shop, the middleware must check whether it is valid at all. This validation happens in several stages. First the syntax: does the message conform to the structure of the stated message type and version? Then the keys: can partner, article and addresses be resolved via the mapping? Finally the business logic: are quantities plausible, prices present, mandatory fields filled? A message that fails here must not vanish silently but must trigger a clear response.

This is exactly what the CONTRL message exists for. It acknowledges at the syntax level that a message was received correctly, or reports specifically which segment was faulty. Business responses such as an ORDRSP order response go beyond this and report whether the order was also accepted in substance. Security plays a central role: according to the OWASP API Security Project, missing or faulty authentication and authorization are among the most frequently exploited weaknesses in interfaces (OWASP API Security Top 10, 2023). An EDI integration verifies the signature and origin of every message before it processes its content.

The economic benefit of this diligence is considerable. In our experience, automation typically reduces manual effort in EDI processes significantly because error-prone manual entry is eliminated (project experience). A clean validation addresses exactly these sources of error by catching faulty messages early instead of letting them cause harm in downstream systems. An in-depth treatment of handling errors, retries and duplicate messages is shown in the sister article on the PIM integration product-data pipeline.

The greatest effort of an EDI integration rarely lies in the transport but in the mapping. EDIFACT gives organizations a lot of latitude in which segments they use and how they assign codes. Every large trading partner therefore maintains its own implementation guide that describes its variant of the standard. An integration with three partners usually means three mappings that share much but differ in details. Those who try to serve all partners through a single rigid schema build a construction that is hard to maintain.

The proven approach separates a shared internal data model from partner-specific profiles. The converter first translates every incoming message into the internal model and from there into the shop object, and vice versa. Changes for one partner touch only its profile. This architecture pays off as soon as partners are added or adjust their guides. Across over 50 integration projects (project experience) this clean separation has proven considerably easier to maintain than a monolithic mapping. How to design this internal model for master data is explored in the article on shipping and logistics interfaces.

A resilient EDI integration places all the logic in a middleware between trading partner and shop, not in the shop itself. This layer receives the message over AS2, OFTP2 or SFTP, checks signature and syntax, persists every message with a unique key and processes it asynchronously toward shop and ERP. The advantage of this decoupling is robustness: if a target system fails briefly, the message stays safely in the queue and is retried without the partner noticing. According to Gartner, integration initiatives fail above average on non-functional requirements such as load behavior and fault tolerance (Gartner, 2024), not on the business logic.

Persistence with an idempotency key is central here, because even in EDI exchange a message can arrive more than once, for example after a repeated delivery. The key, often the document number from the BGM segment, ensures that the same order is not created twice. This decoupling also makes it possible to separate heavy processing from fast acceptance: the acknowledgement confirms safe receipt, the actual order creation happens in the background. These principles apply equally to a SAP integration and to coupling with another ERP.

Economically the effort pays off because B2B trade keeps growing. German B2B e-commerce, with a sales volume in the triple-digit billions, is among the fastest-growing distribution channels (BEVH, 2024), and the industry association BITKOM sees the automation of business processes as one of the most important levers for efficiency gains (BITKOM, 2024). Statista reports sustained double-digit growth of digital commerce in German e-commerce over recent years (Statista, 2024). An EDI integration is the technical prerequisite for participating in this growth with large partners without drowning in manual effort. An accompanying integration consultation helps align the integration to your specific partners and processes.