When a large retail chain buys from a supplier, it doesn't send an email with a PDF for someone to key in on the other side. It sends a purchase order the supplier's computer understands on its own, loads into its system and answers with an invoice through the same channel. That dialogue between machines —with no humans in between— has had a name for half a century: EDI. It's one of the oldest and most ignored pipes in commerce, and it still moves an enormous volume.
What EDI is
The idea is simple to state and powerful in its consequences: instead of two companies sending each other documents that a person reads and re-types, their systems exchange them directly in a format both agreed to understand.
EDI (Electronic Data Interchange) is the exchange of business documents —purchase orders, invoices, shipping notices— directly between computers, in a standard format and with no human intervention.
It was born in the 1970s and 80s, decades before web APIs. It's not a new technology reinventing itself: it's infrastructure that has been running since before the internet as you know it existed.
How it works
The cycle, seen end to end, is a clean handoff between two systems that speak the same agreed language:
- The source system generates the document —for example, an invoice— and translates it into a standard EDI format. It stops being a PDF or a screen and becomes a rigid, predictable data structure.
- The document is transmitted to the counterparty over whatever channel both use (more on this below).
- The destination system interprets it automatically and loads it into its ERP, with no one typing it. It flows straight into purchasing, accounts payable or logistics.
The key that holds it all together: both systems agree on the exact format in advance. There's no room for ambiguity. Every field sits in a defined position or segment, with an expected type and length. That discipline is what lets the machine on one side trust blindly what the machine on the other side sends it.
The standards
EDI isn't a single format but a family of standards. Two dominate the landscape:
- ANSI X12 — the dominant standard in North America. Each document type has a numeric code: 850 is a purchase order, 810 is an invoice, 856 is a shipping notice.
- EDIFACT — the international standard, maintained by the UN. It plays the same role as X12 but with its own nomenclature (ORDERS for an order, INVOIC for an invoice).
It may seem bureaucratic that there's a code for every document, but that's precisely the point. The rigidity of the standard is what makes automation possible: if the supplier knows that "850" always and everywhere means a purchase order with a fixed structure, its system can process it without a human confirming what it is. Flexibility would be the enemy here.
How it's transmitted
The format of the document is one thing; the path it travels is another. EDI has used several throughout its history:
- VANs (Value-Added Networks) — private intermediaries that act as a mailbox between trading partners. Historically they were the default medium: each company drops off and picks up its documents on the VAN, which handles routing.
- AS2 — a modern protocol that carries EDI over HTTP, with signing and encryption, and with delivery receipts. It removes the intermediary: partners connect point to point.
- SFTP — the exchange of EDI files over an encrypted channel on SSH, very common in integrations that already move batches of files.
This last one is worth pausing on: EDI and file transfer go hand in hand, and that's where it matters that the channel is secure. If you're curious why SFTP and not FTP to move these files, I went into it in FTP vs SFTP: why banking never transfers over FTP.
Common mistakes
"EDI is a thing of the past, everything is an API now." False. EDI still moves a large share of world commerce —retail, logistics, healthcare, banking— thanks to volume, maturity and contracts already established between partners. It doesn't compete with APIs: it coexists with them. APIs cover the new and the real-time; EDI holds up what already works at scale.
Beyond the obsolescence myth, there are two practical mistakes that keep coming up:
- Believing EDI is "just any file". It isn't. It's a strict standard: every segment, every separator and every field has rules. A document that doesn't meet the standard to the letter gets rejected by the destination system.
- Underestimating the mapping between the standard and your own system. Translating your internal invoice into an 810 —or an 850 into your purchase order— is the real work of an EDI project. That's where the hours go, not in "sending the file".
The banking angle
In banking, EDI shows up where the business meets companies. Banks and corporate clients use it for remittances, payments and B2B integration: payment instructions, collection notices, reconciliation with large clients who want their ERP to talk directly to the bank's platform.
And because those exchanges carry money and sensitive instructions, they don't travel over just any channel: they usually go over MFT or SFTP, secure transports with encryption, access control and an audit trail for every delivery. The format is EDI; the envelope is encryption.
EDI isn't glamorous. It doesn't show up in architecture talks or product launches. But it's the quiet pipe through which commerce runs: while the spotlight is on the latest API, the 850 and the 810 keep moving orders and invoices by the millions, with no one typing them.
