EDI — Electronic Data Interchange
EDI (Electronic Data Interchange) describes the structured, machine-to-machine exchange of business documents between trading partners using standardised message formats. EDI predates the internet, dates back to the 1970s, and remains the backbone of B2B supply-chain communication — particularly in the German automotive industry, food retail (REWE, EDEKA, Aldi, Lidl) and pharmaceutical distribution. Modern ERP systems either ship with EDI integration or connect to specialised EDI service providers.
Relevant EDI standards
- EDIFACT (UN standard) — dominant in Europe and the DACH region. Subsets: ODETTE (automotive), EANCOM (retail/food), CEFIC (chemicals).
- ANSI X12 — dominant in North America, occasionally relevant for DACH companies trading with the US.
- VDA recommendations — German automotive industry specifications layered on EDIFACT (VDA 4905, 4915, 4938).
- OFTP2 / AS2 — transport protocols. AS2 is dominant globally; OFTP2 is used heavily in German automotive.
How ERP-EDI integration works
An incoming order arrives as an EDI message (EDIFACT ORDERS or VDA 4905). The EDI converter maps the message structure to the ERP's sales-order data model. The order is created automatically, with stock availability and pricing applied per the customer master data. Outgoing dispatch advices (DESADV) and invoices (INVOIC) are generated by the ERP and sent back through the converter. Errors trigger manual review in an exception queue.
ERP vendor EDI capabilities
Strong native EDI: SAP S/4HANA, abas ERP, proALPHA, IFS Cloud, Microsoft Dynamics 365 F&O. Cloud-native ERP usually connects to external EDI service providers (Procuros, ecosio, SEEBURGER) via REST API — typical for weclapp, Xentral, NetSuite, Odoo. For most mid-market companies, a managed EDI service costs 200-2,000 EUR per month depending on transaction volume.
EDI message types in daily DACH operations
A typical DACH supplier-to-customer EDI flow uses 6–10 message types. ORDERS (EDIFACT D.96A or VDA 4905): the incoming purchase order. ORDRSP: order response, confirming acceptance and committed delivery date. DELFOR / DELJIT: rolling forecast and just-in-time call-offs, dominant in German automotive supply (Bosch, ZF, Mercedes-Benz, Volkswagen). DESADV (Dispatch Advice / VDA 4913): ASN sent when goods leave the dock, often required to be transmitted 1–2 hours before truck arrival. RECADV: receiving acknowledgement from the customer. INVOIC: the electronic invoice. REMADV: payment remittance advice. SLSRPT / INVRPT: sales and inventory reports, common in vendor-managed inventory arrangements with retail giants like REWE, EDEKA, Aldi or Lidl. Translation between these standards and the ERP's internal data structures is the EDI converter's core job. Modern EDI service providers (ecosio, Procuros, SEEBURGER BIS) handle thousands of these mappings as preconfigured templates per trading partner — a significant cost saving versus building each mapping from scratch.
EDI vs API-first ERP — the strategic question
For new B2B trading relationships in 2026, the legitimate question is whether to roll out EDI at all or to start with modern REST/GraphQL API integration. EDI remains the right answer when (1) the customer mandates EDIFACT or VDA, which the German automotive supply chain still does for most established suppliers; (2) the trading partner uses asynchronous batch processing; (3) regulatory or industry standards prescribe specific message types (e.g. EANCOM for retail). API-first integration (REST/GraphQL via iPaaS platforms like SAP Integration Suite, MuleSoft, Boomi, ecosio API Gateway) is preferable when (1) both parties have modern ERPs with proper API coverage, (2) the integration needs to be real-time, (3) the data model is richer than legacy EDI standards can carry. In practice, many DACH mid-market companies operate hybrid landscapes: EDI for the historic customer base, API integration for new partners, with the EDI service provider acting as a translation layer that converts API calls into EDI messages where needed. ZUGFeRD and XRechnung are emerging XML-based standards that fit between classic EDI and pure API integration, especially for invoicing.
Operating an EDI environment in practice
Beyond initial setup, daily EDI operations involve a recurring pattern of exception handling that any procurement team should understand. Mapping changes: trading partners revise their EDI specifications (new fields, changed segments, version upgrades from EDIFACT D.96A to D.10B) typically once or twice a year. Each change requires testing and a coordinated cutover. Reject monitoring: incoming messages that fail validation queue in an exception list for manual review. Common causes: unknown article numbers, customer-specific item codes not mapped, missing master data, expired pricing. Mature operations clear the queue daily; below that cadence, reject volume accumulates and trading-partner relationships suffer. Acknowledgement tracking: EDIFACT CONTRL or AS2 MDN messages confirm receipt — missing acknowledgements within the SLA window must trigger an investigation. Performance under peak load: order-call-off bursts during retail promotion periods or just-in-time automotive end-of-quarter typically spike volume 3–5x normal — the EDI infrastructure must scale or queue gracefully. Onboarding new partners: each new customer or supplier adds 1–6 weeks of mapping and certification work. Managed-EDI providers maintain libraries of pre-built mappings that compress this. Audit trail: every inbound and outbound message must be archived for GoBD-relevant transactions (order confirmation feeds into eventual invoice), typically 10 years. The volume can be substantial — mid-market companies in automotive supply routinely store 50–200 GB per year of EDI messages.