In 2026, a large customer's order lands in your shop's cart less and less often -- it arrives as a structured document straight from the customer's procurement system. Already more than 90 percent (Digital Commerce 360) of B2B transactions are electronic, and a large share of those run over EDI, electronic data interchange. The underlying UN/EDIFACT standard covers over 200 (UN/CEFACT) message types for orders, despatch advices and invoices. Any supplier that wants to stay deliverable for enterprise procurement and public buyers therefore needs a second, invisible channel next to the shop front end: machine-to-machine integration via EDIFACT and VDA. This article explains the EDI fundamentals, the core message types, the difference between VAN and AS2, and shows how classic document exchange combines with modern real-time interfaces into a hybrid integration model.
Why Large Customers Order via EDI
For an enterprise procurement team, ordering manually in a supplier's web shop is a break in the process. Large buying organizations work with central ERP and procurement systems in which needs, budgets and approvals are modeled. An order should originate in that system, run through the approval path and arrive at the supplier without re-entry. That is exactly what EDI delivers: it transfers business documents from system to system in a standardized, machine-readable format -- without anyone retyping. The effect is measurable. B2B e-commerce in the US grew 13 percent to USD 2.93 trillion in 2025 (Digital Commerce 360), and the growth comes above all where orders flow automatically into customers' systems.
EDI is no passing fashion but has been the backbone of professional trade for decades. On the basis of the EDIFACT subset EANCOM alone, around 1 billion (GS1 Germany) invoices are transmitted electronically in Germany each year. For the supplier, EDI capability often means more than efficiency: it is the precondition to be listed at all. In many framework contracts and tenders, a working EDI connection is a must-have criterion. Whoever cannot offer it drops out of automated procurement -- regardless of how well the shop itself is designed.
EDI complements the shop, it does not replace it
What EDI and EDIFACT Technically Are
EDI stands for Electronic Data Interchange -- the structured exchange of business documents between the application systems of two partners. EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) is the cross-industry standard for it, maintained by the United Nations. It defines a fixed grammar: a message consists of segments, segments of data elements. An envelope of header and trailer segments (UNB/UNZ for the interchange, UNH/UNT for the individual message) brackets the payload. Because the standard is so precise, every receiving system can interpret an EDIFACT file without individual arrangement -- that is the core of interoperability.
Because the full EDIFACT standard is very extensive, industries have defined their own binding subsets. In the consumer goods and retail sector, GS1's EANCOM is the most widely adopted standard, a UN/EDIFACT subset used worldwide by around 126,000 (GS1) companies. In the automotive industry, the VDA takes this role. These subsets define which segments and fields are mandatory for a given business case and thus reduce room for interpretation. The UN/EDIFACT standard itself is updated semi-annually in so-called directories -- the message names are always six characters long, such as ORDERS or INVOIC (UN/CEFACT).
Segment and message
Every EDIFACT message is built from segments that bundle data elements. Header and trailer segments enclose the payload and make the document uniquely assignable.
UN/EDIFACT
The cross-industry UN standard with over 200 message types (UN/CEFACT). Semi-annual directories secure a common, versioned language across national borders.
EANCOM
The GS1 subset for retail and consumer goods -- the most widely used EDI standard in Germany, the basis for around one billion invoices per year (GS1 Germany).
VDA and ODETTE
The automotive industry standards. The former fixed-record VDA formats are now EDIFACT-based, for example DELFOR as a delivery schedule (VDA).
Verifiable
Because structure and mandatory fields are standardized, every message can be checked against the schema. Format errors surface before the document enters order processing.
Machine-readable
Orders, deliveries and invoices flow from system to system without manual capture. That is the actual reason large customers demand EDI.
The Core Message Types in the Order Process
A complete ordering cycle maps in EDIFACT onto a chain of clearly defined messages. The three most frequently used types are ORDERS, DESADV and INVOIC (GS1 Germany) -- complemented by the order response ORDRSP. Each message carries a unique reference, so that order, delivery and invoice stay connected across the whole cycle. This referencing bracket is decisive: it lets the ERP automatically assign incoming documents to the right transaction and detect discrepancies.
| Message | Meaning | Direction | Content |
|---|---|---|---|
| ORDERS | Purchase order | Customer to supplier | Line items, quantities, prices, delivery date, references |
| ORDRSP | Order response | Supplier to customer | Confirmation, changes, availability, confirmed dates |
| DESADV | Despatch advice | Supplier to customer | Shipment content, pack structure, dispatch data, delivery note |
| INVOIC | Invoice | Supplier to customer | Invoice line items, taxes, payment terms |
| DELFOR | Delivery schedule | Customer to supplier | Framework quantities and dates, typical in the automotive industry |
In the automotive industry, the chain is often clocked more tightly. The VDA has defined its own EDI recommendations for communication between manufacturers and suppliers since the 1970s (VDA). Today these recommendations are EDIFACT-based: the delivery schedule DELFOR controls framework quantities and dates, the despatch advice DESADV announces the shipment. For suppliers, correct and timely message processing is directly business-relevant, because it feeds into supplier ratings and conformity frameworks such as MMOG/LE (VDA). An error in message processing here is not a technical detail but a reputation risk in the supply chain.
VAN or AS2: the Transmission Paths
An EDIFACT document is at first just a file -- what matters is how it reaches the partner. Historically this ran over a Value Added Network (VAN), a kind of operated postal network for EDI. Both partners maintain a mailbox there, the VAN operator accepts messages, logs them and delivers them. The VAN decouples the partners technically and handles conversion and tracking. The price is transaction- or volume-based fees and dependence on an intermediary.
The more modern alternative is AS2 (Applicability Statement 2), a protocol for direct, encrypted exchange over the internet. Partners send their messages point to point via HTTPS, sign them digitally and receive a verifiable acknowledgement with the MDN receipt. AS2 avoids ongoing transaction fees and speeds up transmission, but requires both sides to maintain certificates and endpoints. In practice, both paths coexist: which one is used is usually dictated by the large customer. A robust connection should therefore be transport-agnostic and able to serve both.
| Attribute | VAN (mailbox network) | AS2 (point-to-point) |
|---|---|---|
| Principle | Operated intermediary network with mailboxes | Direct connection over HTTPS |
| Cost | Transaction- or volume-based | No transaction fee, own operation |
| Receipt | Network-internal logging | Signed MDN acknowledgement |
| Effort | Low, intermediary operates it | Maintain certificates and endpoints yourself |
| Speed | Depends on the delivery interval | Near real time |
EDI and API as a Hybrid Model
The most interesting trend is not EDI versus API but EDI with API. Classic document exchange and modern real-time interfaces have different strengths, and in 2026 they merge into hybrid integration models. EDI is strong in the standardized, legally binding exchange of large document volumes -- the order, the order response, the despatch advice, the invoice. These documents are asynchronous: they are created, transmitted and processed without anyone waiting. A REST or GraphQL interface, by contrast, shines at synchronous single queries that need a current answer at the moment of the request.
In practice, you combine both. The ordering process runs as a document chain over EDIFACT, while the customer checks in real time via an API what they need right now. This split plays to the respective strengths and avoids misusing a tool for the wrong task (project experience).
Prices via API
Customer-specific net prices and tiers change constantly. A real-time query delivers the valid price before the order, instead of guessing it from a static catalog.
Stock via API
Availability is volatile. A synchronous stock query shows the buyer whether the desired quantity is deliverable before the ORDERS message is even created.
Tracking via API
Shipment status is queried frequently and rarely cast into a document. An API delivers the current state on demand, complementing the DESADV despatch advice.
Asynchronous documents, synchronous lookups
Mapping onto Shopware and ERP
Between the EDIFACT message and the data structures of shop and ERP lies the actual work: the mapping. An ORDERS message speaks in segments and codes, a Shopware shop and an ERP speak in their own fields and objects. The mapping translates both directions: it breaks the incoming order down into customer, line items, quantities and terms, and conversely assembles the outgoing order response, despatch advice and invoice from the order data. This translation layer is the core of every EDI project.
The most common source of error is not the technology but data maintenance. The customer's article numbers differ from your own, units are coded differently, a price is missing or a reference does not match. Without clean master data, the mapping fails on exactly these details (project experience). A well-maintained PIM integration with unique identifiers and cross-references between customer and supplier article numbers is therefore the quiet precondition of a stable connection. The mapping is a clearly bounded interface project that can be cleanly separated from the rest of the shop development.
- Receive and validate the message: Check incoming ORDERS against the schema and the agreed subset, catch format errors early.
- Map the fields: Translate customer, article and terms fields onto the objects of shop and ERP, normalize units and codes.
- Reference articles: Resolve customer article numbers via a cross-reference to your own numbers.
- Create the order: Generate an order in order processing from the purchase order, set references for the document chain.
- Produce responses: Generate ORDRSP, DESADV and INVOIC from the order data and hand them over in a standard-compliant way.
- Handle errors: Route unassignable messages into a controlled clarification instead of silently discarding them.
Distinction: Punchout, API and E-Invoice
EDI is easily confused with neighboring integration patterns, although each serves a different purpose. In the punchout procedure via OCI, the buyer briefly leaves their procurement system, browses the supplier's catalog live and transfers the filled cart back -- it is about the interactive catalog session in the procurement system, not the asynchronous document exchange. A REST or GraphQL architecture in turn serves synchronous system-to-system calls in real time. EDI, by contrast, is the standardized, asynchronous exchange of large document volumes with established trading partners. The three patterns do not compete, they complement each other in a well-designed system landscape.
Closely related but not identical is the invoice. The INVOIC message is the classic EDI invoice, and under the conditions named by law, EDI can serve as a structured e-invoice. How this fits into the coming e-invoicing mandate from 2027 and the formats ZUGFeRD and XRechnung is covered in a separate article. And whoever orders their master and transaction data for EDI at the same time builds the basis for further data obligations such as the digital product passport. Cleanly maintained data is the shared foundation of all these requirements.
EDI, punchout and API are not competing camps. They are three tools for three tasks -- document exchange, catalog session and real-time lookup. The art lies in using each where it has its strength.
Onboarding Trading Partners
An EDI connection is rarely finished once the first partner is live. Every new large customer brings their own subset, their article numbers and their requirements for transport and fields. Partner onboarding is therefore a recurring process, not a one-off project. Because billions of EANCOM messages are exchanged between trading partners each year (GS1 Germany), it pays to design onboarding as a practiced routine -- with a binding field mapping, a test phase using real documents and a monitored go-live.
The test phase in particular decides on stability. Total B2B sales rose just 0.4 percent in 2025 (Digital Commerce 360), while the digital channels grew significantly -- the pressure to get every new connection cleanly and quickly into production is real. A structured onboarding catches the customer-specific quirks early, instead of discovering them in live operation.
- Define subset and message types bindingly with the customer's procurement team
- Clarify the transport path: VAN or AS2, align certificates and endpoints
- Document the field mapping and the article-number cross-reference
- Run a test with real documents across the entire message chain
- Define error handling and an escalation path for unassignable messages
- Start the go-live monitored and closely accompany the first documents
Set up onboarding as a repeatable process
Sources and studies