EDI (electronic data interchange)
EDI is the exchange of standard business documents, such as purchase orders and invoices, between two companies' systems in a fixed format agreed in advance. In North America that usually means the ANSI X12 standard, where an 850 is a purchase order and an 810 is an invoice.
In practice
For most suppliers EDI arrives as a requirement rather than a choice. It appears in a large customer's supplier onboarding packet, naming the document types you must support and how they must be transmitted, and the alternative to implementing it is not winning the account. That is worth stating plainly, because EDI is often discussed as a technology decision when it is a commercial qualification.
The documents themselves are standardised [1], but the way each trading partner fills them is not. Every partner publishes its own implementation guide with its own conventions about which optional fields are mandatory for them, so ten customers on EDI is closer to ten small projects than to one. Transmission happens either through a value-added network, which handles delivery for you, or directly over AS2, a specification published as RFC 4130 [2].
EDI moves in batches. Documents are picked up and processed on a schedule, which means order status is only as current as the last run. That is fine for the job it does and useless for anything a customer sees, so a company with excellent EDI still cannot show live order status on its website without a separate API.
It persists for an unglamorous reason. The large buyers who mandate it have refined the process over decades and bear none of the cost of changing it, while thousands of suppliers bear all of it. Predictions that APIs would replace EDI keep underestimating that asymmetry.
Worth knowing before you scope it: EDI is a specialism, and the people who do it well are generally not the people who build your website. Most established suppliers either buy a managed service that handles translation and transport, or hire a consultant per trading partner. Treating it as an in-house IT project is where timelines slip, because the difficulty is less technical than administrative: reading somebody else's implementation guide and testing against their system on their schedule.
One thing worth checking today: find out who reads your functional acknowledgments. A 997 or 999 comes back to confirm a document was received and readable, and a rejection sits in that acknowledgment until a person looks. If nobody on your team can say where those land, you have a failure mode that stays invisible for a week at a time.
Common questions
Is EDI still used?
Widely, particularly in retail, automotive, aerospace, healthcare and government supply chains. It has outlasted repeated predictions of its replacement because the buyers who require it have no incentive to change and every incentive to keep requiring it.
What is the difference between EDI and an API?
EDI exchanges standardised business documents on a schedule, and is usually mandated by a customer. An API answers a request in real time and is something you build. EDI is a compliance requirement; an API is a capability. Most established suppliers need both, and the two are compared in detail on our EDI vs API page.
What does an EDI 850 mean?
An 850 is the ANSI X12 transaction set for a purchase order. Other common ones are the 855 purchase order acknowledgment, the 856 advance ship notice, the 810 invoice and the 997 functional acknowledgment. Europe more often uses the UN/EDIFACT equivalents.
How much does EDI cost?
It varies too much for a headline figure to be useful, and the structure matters more than the number: setup and mapping per trading partner, plus recurring network or per-document fees that scale with trade. Get quotes against your real partner list rather than a per-month advertised rate.
Sources
- X12, the North American EDI standards body x12.org
- RFC 4130, MIME-based secure peer-to-peer business data interchange (AS2) rfc-editor.org/rfc/rfc4130