EDI — Electronic Data Interchange
EDI is 1970s technology that still moves an enormous share of global B2B commerce. If you work with retail, automotive, healthcare, or logistics, you will work with EDI. It is not going away.
Why it still exists
- Universally adopted in retail and automotive supply chains
- Large trading partners mandate it — no EDI, no purchase orders
- It works, it’s proven, and it’s cheap per transaction at volume
- Replacing it requires every partner to agree, simultaneously
Walmart, Amazon, Tesco, Toyota, and most hospital groups will not do business with a supplier who cannot receive an EDI 850.
The standards
| Standard | Region | Notes |
|---|---|---|
| ANSI X12 | North America | Numeric transaction sets (850, 810, 856) |
| EDIFACT | Europe/international | Named messages (ORDERS, INVOIC, DESADV) |
| VDA | German automotive | |
| ODETTE | European automotive | |
| TRADACOMS | UK retail (legacy) | Being replaced by EDIFACT |
| HIPAA X12 | US healthcare | 837 claims, 835 remittance |
| cXML / OCI | E-procurement punchout | XML, not classic EDI |
| XML/JSON via API | Modern equivalent | Same semantics, better syntax |
The message set you need to know
| X12 | EDIFACT | Meaning | Direction |
|---|---|---|---|
| 850 | ORDERS | Purchase order | Customer → you |
| 855 | ORDRSP | PO acknowledgement | You → customer |
| 860 | ORDCHG | PO change | Customer → you |
| 865 | ORDRSP | Change acknowledgement | You → customer |
| 856 | DESADV | Advance Ship Notice (ASN) | You → customer |
| 810 | INVOIC | Invoice | You → customer |
| 820 | REMADV | Payment/remittance advice | Customer → you |
| 846 | INVRPT | Inventory advice | Either |
| 852 | SLSRPT | Product activity / POS sales | Customer → you |
| 830 | DELFOR | Planning/forecast schedule | Customer → you |
| 862 | DELJIT | Shipping schedule (JIT) | Customer → you |
| 214 | IFTSTA | Transport status | Carrier → you |
| 940/945 | — | Warehouse shipping order/advice | You ↔ 3PL |
| 997 | CONTRL | Functional acknowledgement | Both |
The 997/CONTRL is the one beginners forget. It’s a receipt confirming the message was syntactically received. Trading partners require it, usually within a contractual window (often 1 hour). No 997 = they assume you didn’t get the order.
Anatomy of an X12 message
ISA*00* *00* *ZZ*SENDERID *ZZ*RECEIVERID *260315*1430*U*00401*000000001*0*P*>~
GS*PO*SENDERID*RECEIVERID*20260315*1430*1*X*004010~
ST*850*0001~
BEG*00*SA*4500012345**20260315~
REF*DP*00123~
N1*ST*MERIDIAN WAREHOUSE DHAKA*92*DHK001~
N3*123 INDUSTRIAL AREA~
N4*DHAKA**1229*BD~
PO1*1*500*EA*12.50**BP*FAB-1000*VP*V-88213~
PID*F****NAVY COTTON JERSEY 180GSM~
DTM*002*20260401~
PO1*2*200*EA*8.75**BP*FAB-2000~
DTM*002*20260401~
CTT*2~
SE*12*0001~
GE*1*1~
IEA*1*000000001~
Structure:
ISA / IEA Interchange envelope (who ↔ who, control number)
GS / GE Functional group (message type, version)
ST / SE Transaction set (one document)
Segments (BEG, REF, N1, PO1…) each with delimited elements
Delimiters are declared in the ISA header: * element, ~ segment, > sub-element. They vary by partner — never hardcode them; read them from the ISA.
EDIFACT is the same idea with different syntax:
UNB+UNOA:2+SENDERID+RECEIVERID+260315:1430+1'
UNH+1+ORDERS:D:96A:UN'
BGM+220+4500012345+9'
DTM+137:20260315:102'
NAD+BY+DHK001::92'
LIN+1++FAB-1000:BP'
QTY+21:500:EA'
PRI+AAA:12.50'
UNS+S'
UNT+9+1'
UNZ+1+1'
The trading partner problem
This is the real work. The standard is a framework, not a specification. Every partner has an implementation guide specifying which segments they send, which they require, and what values they use.
Partner A's 850: ships to N1*ST with a DUNS number, uses PO1*BP for your part number
Partner B's 850: ships to N1*ST with their own store code, uses PO1*IN, and sends
the delivery date in DTM*010 instead of DTM*002
Partner C's 850: sends 40 line items in one PO1 loop with SLN sub-lines
Consequence: a mapping per partner per message type. A supplier with 30 EDI customers has 30 different 850 maps. This is why EDI onboarding takes weeks per partner and why EDI teams exist.
Every partner relationship needs:
- Their implementation guide
- A cross-reference of their item numbers to yours
- A cross-reference of their location codes to your ship-tos
- Their qualifier conventions (DUNS, GLN, or a proprietary code)
- Agreed test cases and a certification process before go-live
Transport
| Method | Notes |
|---|---|
| AS2 | The retail standard. HTTP + S/MIME signing and encryption, with an MDN receipt |
| SFTP | Common, simple, needs key management |
| VAN (Value Added Network) | A managed mailbox service. Still very common. Per-character or per-KC billing |
| AS4 | The modern ebXML-based successor, used in e-invoicing (PEPPOL) |
| OFTP2 | European automotive |
| API | Increasingly offered as an alternative |
AS2 MDNs are receipts — a signed acknowledgement that the message was received and the signature verified. Trading partner agreements specify MDN requirements and response times. Missing MDNs are a support ticket, not a curiosity.
The ERP side
Inbound 850 (PO)
→ parse and validate syntax → send 997
→ map to your sales order structure
→ validate business rules: customer exists, materials exist, prices agree
→ create the sales order
→ send 855 (acknowledgement) with confirmed quantities and dates
Outbound 856 (ASN)
→ triggered by goods issue / packing
→ hierarchical: shipment → order → pack (pallet) → item
→ includes SSCC licence plates matching the physical GS1-128 labels
→ must arrive BEFORE the truck
Outbound 810 (Invoice)
→ triggered by billing
→ must match the PO and the ASN, or it's rejected
The ASN is the one that matters
Retailers scan the SSCC on the pallet at the dock and expect the ASN to tell them what’s inside. If the ASN is late, wrong, or missing:
- The delivery may be refused at the door
- Chargebacks — retailers levy financial penalties, often $200–$500 per occurrence, sometimes a percentage of the invoice
- Your compliance scorecard drops, which affects future business
ASN accuracy is a revenue issue, not a technical one. Getting it right requires the ASN to be generated from what was actually packed, not what was ordered.
Validation layers
1. Syntax Is it valid X12/EDIFACT? → 997 accept/reject
2. Structure Are required segments present per the partner's guide?
3. Data Do codes, dates, and numbers parse and make sense?
4. Business Does the customer exist? The material? Does the price match the contract?
5. Application Can the order actually be created? (credit, availability)
Failures at each level need different handling. A syntax error rejects the whole interchange. A business error on line 7 of a 40-line PO should usually create the order for the other 39 and flag line 7 — dropping the whole order because one item was discontinued makes you a difficult supplier.
Price and quantity discrepancies
The most common EDI business issue:
Their 850 says: 500 EA @ 12.50
Your contract: 500 EA @ 12.75
Options:
a) Accept their price (lose margin)
b) Reject the PO (upset the customer)
c) Accept, confirm your price in the 855, resolve commercially
Option (c) is standard, which is why the 855 acknowledgement carries confirmed prices and quantities — it’s the mechanism for saying “we accept, with these changes.” Build the discrepancy report; someone in sales needs to work it daily.
Testing and certification
Partners require formal certification before production:
- Exchange test messages in a test environment
- Validate structure against their guide
- Run business scenarios: normal order, change, cancel, partial ship, backorder
- Verify 997s flow both ways within the required window
- A parallel period where both EDI and the old process run
- Sign-off, then production cutover
Budget 4–8 weeks per partner. Project plans that assume “EDI setup: 3 days” are why EDI workstreams run late.
Build vs buy
| Option | When |
|---|---|
| EDI provider / managed service (SPS Commerce, TrueCommerce, Cleo, OpenText) | Most companies. They own the maps and the partner onboarding |
| Integration platform with EDI modules (Boomi, MuleSoft, SAP Integration Suite) | You have integration capability in-house |
| Build it yourself | Only with high volume, few partners, and real in-house expertise |
Parsing X12 is not the hard part — libraries exist for every language. The hard part is 30 partner-specific maps, ongoing partner changes, certification, and 24/7 operational support. That’s what providers actually sell.
Modern alternatives
| Approach | Status |
|---|---|
| REST/JSON APIs | Growing, especially with newer retailers and marketplaces |
| cXML PunchOut | Standard for e-procurement catalogues |
| PEPPOL (AS4 + UBL) | Mandated for public procurement in the EU and expanding into B2B |
| GS1 EDI / EANCOM | An EDIFACT subset with GS1 identifiers |
The semantics are identical — a purchase order is a purchase order. The syntax changes; the trading partner mapping problem does not. Don’t assume moving to JSON removes the work.
Developer notes
- Read the delimiters from the ISA/UNA header. Never hardcode.
- Always send the 997/CONTRL, promptly.
- One map per partner per message type. Structure your code for that reality.
- Cross-reference tables are mandatory: their item codes, their location codes, their qualifiers.
- Archive every raw message, inbound and outbound, for at least the retention period. Disputes are settled by the raw file.
- Log the full lifecycle: received → parsed → validated → posted → acknowledged.
- Monitor for silence. A partner who normally sends 200 orders a day and sends zero is an incident, not a quiet day.
- Test with real partner data, not synthetic samples. Real data has the edge cases.
- Certificate and key expiry for AS2 is a top outage cause. Alert 30 days ahead.