EDI, Electronic Data Interchange, is the long-established practice of exchanging structured business documents between trading partners in an agreed machine-readable format, system to system and without human transcription. Purchase orders, invoices, despatch advices and acknowledgements are the core set in procurement.
EDI is routinely described as legacy, and that description is misleading in a way worth correcting early. It is old, it is awkward, and very large amounts of commercial traffic run on it every day in exactly the industries where a failed order costs the most. What is true is narrower: EDI is a poor fit for the long tail of smaller suppliers, for reasons of cost per connection rather than anything to do with the formats themselves.
The two standards families
Almost all procurement EDI belongs to one of two families, split largely along geographic lines.
ANSI X12
X12 is developed by the Accredited Standards Committee X12 and is dominant in North America. Its documents are called transaction sets and are identified by number:
- 850 is the purchase order.
- 855 is the purchase order acknowledgement, the supplier’s business-level answer accepting, rejecting or changing the order.
- 856 is the advance ship notice, describing what is in the shipment and how it is packed.
- 810 is the invoice.
- 997 is the functional acknowledgement, confirming that a transmission arrived and parsed.
Others appear regularly: 860 and 865 for order changes and the response to them, 832 for a price and sales catalog, 846 for inventory advice, 820 for payment and remittance detail.
UN/EDIFACT
EDIFACT is maintained under the United Nations and dominant in Europe and international trade generally. Its documents are called messages and are named rather than numbered, which makes them easier to discuss:
- ORDERS is the purchase order.
- ORDRSP is the order response, the counterpart to the X12 855.
- ORDCHG is an order change.
- DESADV is the despatch advice, the counterpart to the 856.
- INVOIC is the invoice.
- RECADV is the receiving advice, sent by the buyer to report what actually arrived.
- CONTRL is the syntax-level acknowledgement, the closest counterpart to the 997, with APERAK carrying application-level acceptance or rejection.
Industry subsets exist and matter more than the base standard in practice. EANCOM, the GS1 subset of EDIFACT, is the version most retail and grocery supply chains use.
What an EDI document looks like
Both families are positional: a document is a sequence of segments, each segment a tag followed by data elements in a fixed order, separated by delimiters. There are no field names in the payload: meaning comes entirely from position, and position is defined in the specification rather than in the file.
An X12 purchase order, wrapped in its interchange and group envelopes:
ISA*00* *00* *ZZ*BUYERID *ZZ*SUPPLIERID *260913*1030*U*00401*000000001*0*P*>~
GS*PO*BUYERID*SUPPLIERID*20260913*1030*1*X*004010~
ST*850*0001~
BEG*00*SA*4500012345**20260913~
REF*DP*00123~
DTM*002*20260930~
N1*ST*Hotel Bergamo Centro~
PO1*1*24*CA*18.50**VP*SKU-99213*BP*MAT-4471~
CTT*1~
SE*8*0001~
GE*1*1~
IEA*1*000000001~The same order in EDIFACT:
UNB+UNOC:3+8712345678901:14+8798765432109:14+260913:1030+000000001'
UNH+00001+ORDERS:D:96A:UN:EAN008'
BGM+220+4500012345+9'
DTM+137:20260913:102'
DTM+2:20260930:102'
NAD+BY+8712345678901::9'
NAD+SU+8798765432109::9'
LIN+1++5901234123457:SRV'
IMD+F++:::CHOPPING BOARD 450MM'
QTY+21:24'
PRI+AAA:18.50'
UNS+S'
CNT+2:1'
UNT+13+00001'
UNZ+1+000000001'Neither is readable without the specification open alongside it. DTM*002*20260930 is a requested delivery date only because qualifier 002 means that in the relevant code list. QTY+21:24 is twenty-four units ordered only because 21 is the ordered-quantity qualifier. CA is a case and EA is each because a code list says so.
This is not bad design, it is design for different constraints. These formats were written when transmission was billed by the character and storage was scarce, so compactness was the priority and readability was not. They are also extremely stable, a real virtue in systems running the same integrations for thirty years.
The envelope structure matters operationally. X12 nests a transaction set (ST to SE) inside a functional group (GS to GE) inside an interchange (ISA to IEA), each with its own control number. EDIFACT nests a message (UNH to UNT) inside an interchange (UNB to UNZ). Control numbers and segment counts are how receivers detect duplicates and truncation, and mismatched counts are among the most common reasons a file is rejected in full.
Implementation guides are the real cost
The most important thing to understand about EDI is that the standard is not the agreement.
X12 and EDIFACT define what is possible: which segments may appear, in what order, how often, and which code values are legal in each element. What they do not define is what any particular trading partner requires. That is the job of an implementation guide, a per-partner document that says which optional segments are mandatory here, which code values are actually accepted, what goes in each reference field, and what the partner will do if something is missing.
The consequence is blunt. An X12 850 from one buyer is not interchangeable with an X12 850 from another. Both are valid 850s. One requires a department number in REF and rejects the order without it; another ignores REF entirely and requires a cost centre in a different segment. One accepts a buyer part number only; another demands both buyer and supplier part numbers on every line. A supplier who has implemented one buyer’s 850 has implemented one buyer’s 850.
That per-partner mapping work, repeated for each trading partner and maintained as guides are revised, is the actual cost of EDI. Not the software, which is commodity, and not the transport: the specification reading, mapping, testing and maintenance, multiplied by the number of partners. The same multiplicity problem shows up in cXML integrations, but EDI has the highest fixed cost per connection of any of them.
How EDI moves
The formats say nothing about transport, which has changed several times while the documents stayed the same.
- Value-added networks. The traditional method. A VAN is a commercial intermediary holding a mailbox per partner: you deposit an interchange addressed to a partner and they collect it. VANs handle routing, retention and delivery tracking, and historically charged by volume transmitted.
- AS2. Direct partner-to-partner exchange over HTTP with signing, encryption and a signed receipt confirming delivery. It removed the intermediary and its per-character billing, and is now the default for large trading relationships.
- SFTP. A shared directory with scheduled pickup. Cheap, ubiquitous, and offers no delivery receipt of its own, so acknowledgement handling has to carry that weight.
- Web services and APIs. Increasingly the pipe, sometimes carrying the same X12 or EDIFACT payload unchanged inside a modern request.
Sector protocols exist alongside these, OFTP2 in European automotive being the most visible.
EDI compared with cXML and PEPPOL
Against cXML. cXML covers the same ordering and invoicing ground in a far more verbose format, and gains readability, HTTP-native transport and a much lower barrier to entry for a supplier without EDI infrastructure. The decisive difference is not verbosity: it is that cXML supports interactive PunchOut, letting a requisitioner shop a supplier’s live catalog and return a cart. EDI has no equivalent and never did. Catalog data can be transmitted by EDI as a file, in a 832 or a PRICAT, but an interactive session is outside the model entirely. That distinction is what hosted catalog versus PunchOut turns on.
Against PEPPOL. PEPPOL is a different kind of thing, and the comparison is often made badly. X12 and EDIFACT are document formats exchanged point to point between two parties who have agreed everything bilaterally. PEPPOL is a network: a participant directory, certified access points, a defined transport, and published validation rules that everyone on the network shares. Because the profile is common rather than bilateral, connecting to the network connects you to everyone on it, which per-partner EDI cannot do. For invoicing under European mandates PEPPOL is increasingly not optional, and the direction of travel is covered in PEPPOL e-invoicing and the 2026 shift.
The realistic picture in a large European estate is all three at once: EDI with the large established suppliers, cXML or OCI for catalogs and PunchOut, and PEPPOL for compliant invoicing.
Why EDI stays, and where it does not fit
EDI is not going away in large-enterprise supply chains, and predictions that it will have been wrong for a long time. The integrations exist, they are tested, they carry high volumes reliably, and the cost of replacing a working connection is real while the benefit is theoretical. Retail, automotive, grocery and pharmaceutical distribution are built on it. A buyer proposing to migrate three hundred functioning EDI relationships to something newer is proposing a large project with no operational upside.
Where EDI does not fit is the long tail. The cost of an EDI connection is largely fixed per partner: guide analysis, mapping, testing, certification, transport setup. That cost is trivially absorbed across a supplier shipping millions of euros a year and prohibitive for one shipping tens of thousands. So the long tail stays on email, PDF and manual entry, exactly where invoice exceptions, price errors and maverick spend concentrate.
How EDI goes wrong in practice
- Implementation guide drift. A partner revises their guide, the supplier does not notice, and documents start failing. Worse, they start half-failing: a newly mandatory element is silently ignored by a mapping that predates it, and the orders keep flowing while the data quietly degrades.
- Unmonitored acknowledgements. The 997 and CONTRL exist to tell you a transmission arrived and parsed. They are configured at go-live, they work, and then nobody watches them. The failure mode is a rejected interchange that generates a negative acknowledgement into a mailbox nobody reads, so a day of orders simply does not exist on one side while both parties assume all is well. Acknowledgement monitoring should be an alert, not a report.
- Code list assumptions. Unit of measure, currency and qualifier codes come from long standard lists of which each partner uses a handful. Sending a legal code the partner does not accept fails validation, which is the good case. Sending a legal code they interpret differently does not fail at all.
- Envelope control numbers. Duplicate interchange control numbers after a system restore, or a segment count that does not match what was sent, cause whole-file rejection.
- Onboarding cost stranding small suppliers. The most expensive failure is structural rather than technical: suppliers who cannot justify the setup never connect, and their spend stays manual indefinitely.
Where this fits
EDI is one of several formats a supplier has to speak to be reachable across a buyer base, alongside cXML and OCI for catalogs and PunchOut. Each carries its own per-partner mapping cost, and that is why so much supplier spend never gets integrated at all.
That is the problem SupplierForge is built around: CSV, API, SFTP and EDI ingestion into one catalog management layer, so a supplier’s data is structured once rather than remapped for every buyer relationship.