What Is EDI? Electronic Data Interchange Explained

If you have ever wondered how a retailer with tens of thousands of suppliers manages to send a purchase order to each of them, receive an invoice back, and reconcile the two without an army of clerks typing numbers into screens, the answer is almost certainly EDI. Electronic Data Interchange is the machinery underneath most of the world's B2B commerce, and it has been for more than forty years. It is unglamorous, it is standardised to the point of tedium, and it works. This article is the honest, practical version of what EDI is and how it fits into a wider integration estate. It sits inside a broader picture, so before we go deep it is worth reading the enterprise system integration pillar, which frames where EDI belongs among the other ways systems talk to each other.

The message up front: EDI is not a piece of software you buy, it is an agreement between two organisations to exchange business documents in a shared, structured format so that each side's computer can read them without a human retyping anything. The format and the transport are the boring parts. The value is that a purchase order leaves one company's system and arrives inside another's, already understood, ready to be processed automatically.

1. What EDI actually is

Electronic Data Interchange is the computer-to-computer exchange of business documents in a standard electronic format between trading partners. Strip away the jargon and it is a very old, very sensible idea: instead of one company printing a purchase order and posting or faxing it to a supplier, who then rekeys it into their own order-entry system, the two companies agree on a structured layout for that document so it can pass directly from one system to the other. No paper, no rekeying, no transcription errors, no waiting for the post.

The word that carries all the weight is standard. An EDI document is not a free-form email or a PDF that a person reads. It is a rigidly structured message where every field has a defined position, format and meaning that both sides have agreed in advance. A purchase order number goes in a specific place. A quantity is expressed in a specific way. A ship-to address occupies specific segments. Because the structure is fixed and shared, the receiving computer knows exactly how to interpret every element without any human involvement. That is the whole trick, and it is why EDI is often described as a language for machines to conduct business.

It helps to be precise about what EDI is not. It is not the internet, though it often runs over it. It is not a single product or vendor, though many vendors sell EDI software and services. It is not email with attachments, and it is not a modern web API, though it overlaps in purpose with both. EDI is a family of agreed document standards plus the transports that move them, and this combination has become the default way large organisations and their suppliers transact at scale. To understand where it fits among other approaches, the broader what is system integration primer is a useful companion.

2. Why EDI has endured for decades

People have been predicting the death of EDI for at least twenty years. XML was going to kill it. Web services were going to kill it. REST APIs were going to kill it. None of them did, and understanding why tells you something important about how enterprise technology actually evolves, as opposed to how the trade press imagines it evolves.

The first reason is that EDI works and it is already installed. A large retailer, manufacturer or distributor may have thousands of trading-partner relationships wired up through EDI, each one tested, agreed and running in production. Replacing that estate with something newer is an enormous, risky, low-reward project. The systems are not broken, so nobody funds the replacement. The economics of ripping out something that works to install something merely more fashionable rarely add up.

The second reason is that EDI is genuinely standardised across entire industries. When a new supplier wants to trade with a big retailer, the retailer hands them an EDI specification that hundreds of other suppliers already follow. There is a shared vocabulary, a shared set of transaction types, and a well-understood onboarding path. That network effect is powerful. The more partners speak a standard, the more valuable it is to speak it too, and the harder it is to displace.

The third reason is regulatory and contractual inertia. In sectors such as retail, automotive, healthcare and logistics, trading via EDI is often a contractual requirement imposed by the larger party. If a major grocer says you must exchange orders and invoices via EDI to be a supplier, you comply, because the alternative is not being a supplier. That top-down mandate keeps the standard alive across whole supply chains regardless of any individual company's preference.

The practitioner's read: EDI has endured not because it is elegant, but because it is entrenched, standardised and mandated across the exact industries where B2B volume is highest. Elegance loses to network effects almost every time. If you work in or sell to retail, logistics, automotive or healthcare, you will meet EDI, and you should plan to speak it rather than hope to avoid it. The pillar on enterprise system integration covers how to run EDI and modern APIs side by side without treating either as the enemy.

3. How EDI works

At its core, an EDI exchange is a three-step story: one partner's system generates a structured document, that document travels across an agreed connection, and the other partner's system receives and processes it automatically. The document is translated out of the sender's internal format into the agreed EDI standard, transmitted, then translated from the standard into the receiver's internal format. That translation on each end is the job of an EDI translator or mapping layer, and it is where most of the real engineering effort lives.

Consider a simple, everyday flow between a buyer and a seller. The buyer's purchasing system decides it needs to order goods. It produces a purchase order, which the EDI layer converts into a standard 850 transaction and sends to the supplier. The supplier's system receives the 850, converts it into its own order format, and creates a sales order automatically. When the goods ship, the supplier sends back an advance ship notice, and when they invoice, they send an 810. Each document flows machine to machine, and at every hop an acknowledgement confirms receipt. The diagram below shows this exchange running through the two common transport paths, a Value Added Network or a direct AS2 connection.

The important thing to notice is that neither the buyer nor the seller sees the raw EDI format day to day. Their people work in their own ERP or order-management screens, in language that makes sense to them. The EDI translator on each side does the conversion into and out of the shared standard, and the transport in the middle carries the message and returns the receipts. When it works, the whole exchange is invisible: an order placed in one company simply appears as a sales order in another, minutes later, with no one having touched a keyboard in between.

4. EDI standards and transaction sets

Because EDI depends on both sides agreeing on structure, standards are the heart of it. There are two dominant standards families in the world, and which one you meet depends largely on geography and industry. In North America the prevailing standard is ANSI ASC X12, maintained by the Accredited Standards Committee X12. Internationally, and especially in Europe and across global trade, the prevailing standard is UN/EDIFACT, the United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport. They express the same business documents in different syntaxes, so a purchase order is an 850 in X12 and an ORDERS message in EDIFACT.

Within a standard, each type of business document is a transaction set, identified in X12 by a number. You do not need to memorise the whole catalogue, but a handful of transaction sets carry most of the everyday traffic in order-to-cash and procure-to-pay. The table below covers the four you will encounter first, with the EDIFACT equivalent noted so you can map across the two worlds.

The pattern is worth internalising: the 850 opens the order, the 856 announces the shipment, the 810 requests payment, and the 997 is the quiet handshake that confirms each of these was received. Beyond these four there are hundreds more transaction sets for everything from freight tendering to healthcare claims to funds transfer, but if you understand this quartet you understand the shape of the whole system. Note too that the 997 is not a business reply; it says only "your file arrived and was structurally valid," not "your order is accepted." Confusing structural acknowledgement with business acceptance is a classic beginner's error.

5. EDI transports: VAN, AS2 and SFTP

Agreeing on the document format solves half the problem. The other half is moving the document securely and reliably from one company to another, and there are three transports you will meet most often, each with a different heritage and trade-off.

• Value Added Network (VAN): the traditional path. A VAN is a third-party network that acts as a managed post office between trading partners. Each partner connects to the VAN, drops documents into the recipient's mailbox, and the VAN handles routing, delivery receipts, retries and an audit trail. It is reliable and requires little technical effort from either partner, but it is a paid intermediary, often charged per document or per character, which at high volume adds up.
• AS2: a direct, internet-based transport defined in RFC 4130, which specifies how to send EDI (and other) payloads over HTTP with encryption, digital signatures and a signed receipt called an MDN. AS2 lets two partners connect point to point over the public internet without a VAN in the middle, cutting the per-document cost and giving real-time delivery. The trade-off is that each partner runs and secures its own AS2 endpoint, including certificate management, so it moves cost from network fees to in-house technical effort.
• SFTP: the pragmatic workhorse. Many partners simply exchange EDI files over SFTP, dropping structured documents into secure directories on an agreed schedule. It is simple, cheap and universally understood, though it lacks the built-in signed-receipt semantics of AS2 and the managed routing of a VAN, so you build acknowledgement and monitoring around it yourself. For the mechanics and pitfalls of file-based B2B exchange, see the SFTP integration pillar.

In practice a large organisation runs all three at once. Some partners insist on a shared VAN, some are wired point to point over AS2, and some legacy or lower-volume relationships run over SFTP. Part of the discipline of running an EDI estate is knowing which partner uses which transport and monitoring all of them for the acknowledgements that prove documents are getting through. A missing 997 is often the first sign that a transport has quietly broken.

6. The strengths of EDI

It is easy, from a modern software perspective, to be dismissive of a decades-old batch standard. That would be a mistake, because EDI has real, durable strengths that explain its longevity and that many newer approaches struggle to match.

• Genuine standardisation at industry scale: because whole sectors speak the same transaction sets, onboarding a new partner means following a known specification rather than negotiating a bespoke interface from scratch. That shared vocabulary is EDI's single biggest advantage.
• Elimination of manual data entry: documents flow machine to machine, which removes transcription errors, cuts labour, and speeds every cycle from order to payment. The original business case for EDI, no rekeying, is still the core of the value.
• Reliability and auditability: acknowledgements, receipts and the managed audit trails of VANs and AS2 give a defensible record of what was sent, when and to whom. In regulated and contractual trade, that provenance matters.
• Maturity and stability: the standards change slowly and deliberately. An integration built against X12 or EDIFACT does not break because a vendor shipped a breaking change last week. In enterprise operations, boring stability is a feature.
• Ubiquity of tooling and skills: because EDI has been around so long, there is a deep ecosystem of translators, service providers and experienced people. You are never the first organisation to solve a given EDI problem.

7. The weaknesses of EDI

Honesty about EDI means being equally clear on where it hurts, because its weaknesses are real and they are exactly the areas where modern integration approaches look attractive.

• Rigidity: the same fixed structure that makes EDI reliable also makes it inflexible. Adding a new field or changing a document layout means coordinating a spec change across every partner that uses it, which is slow. EDI does not bend easily to fast-moving business requirements.
• Batch orientation: much EDI is still exchanged in batches on a schedule rather than in real time. For order-to-cash flows that is usually fine, but if your business needs an instant, synchronous answer, such as a live inventory check or an immediate price quote, the batch rhythm of traditional EDI is a poor fit.
• Onboarding cost and time: bringing a new trading partner onto EDI involves mapping, testing and certification that can take weeks and real effort on both sides. For a company with a long tail of small suppliers, the per-partner onboarding cost can outweigh the benefit for the smaller relationships.
• Opacity to newcomers: raw EDI is dense and cryptic to anyone who has not learned it. The barrier to entry is not conceptual but cultural, and it makes EDI feel alien to teams raised on JSON and web APIs, which in turn makes it easy to under-resource.

The honest limitation: EDI is superb at high-volume, stable, standardised document exchange between committed partners, and awkward at everything that needs to be real-time, flexible or lightweight to onboard. If you try to force interactive, fast-changing use cases through EDI, you will fight the format the whole way. The skill is knowing which flows genuinely belong on EDI and which belong on an API, rather than treating one as the answer to everything.

8. EDI in the API era

The tempting narrative is that modern REST APIs will finally replace EDI, and every few years someone declares the transition underway. The reality on the ground is more interesting and more durable: EDI and APIs coexist, each handling the work it is suited to, and the mature organisations are the ones that stop treating this as a battle to be won.

APIs excel where EDI struggles. They are real-time, so they suit interactive queries like checking stock, validating an address or getting a live shipping rate. They are flexible and quick to change, so they suit fast-evolving digital products. They are lightweight to onboard, so they suit reaching a long tail of smaller partners who would never justify a full EDI project. For a direct comparison of the two philosophies, the EDI versus API pillar lays out where each wins.

EDI, meanwhile, keeps its ground exactly where its strengths lie: high-volume, standardised, batch document exchange with the large, committed partners who already mandate it. Nobody is going to re-onboard ten thousand established retail suppliers onto a bespoke API because a new protocol is more fashionable. The order-to-cash backbone of retail, automotive, logistics and healthcare will run on EDI for a long time yet.

The pattern I see working is a hybrid one. Modern platforms increasingly wrap EDI in an API-friendly layer, so an internal system can send a clean JSON message that a middleware component translates into an outbound 850, and receive inbound 810s translated back into JSON. The business logic speaks a modern idiom while EDI continues to do the partner-facing heavy lifting. ERP platforms follow the same idea from the other direction, exposing both EDI connectors and REST endpoints. If your backbone is Microsoft Dynamics 365 Business Central, for example, the way it surfaces integration is worth understanding on its own terms; see the Business Central APIs and integrations pillar. The point is that EDI is not being replaced, it is being wrapped, and a strong integration strategy plans for both to run together for years. The enterprise system integration pillar sets out how to architect that coexistence deliberately rather than by accident.

9. References

The facts in this article rest on established, publicly maintained standards. Rather than link to deep pages that move over time, the authoritative sources are named here so you can go to the standards bodies directly:

• ANSI ASC X12: the Accredited Standards Committee X12, chartered by the American National Standards Institute, which develops and maintains the X12 EDI transaction sets (850, 810, 856, 997 and the rest) used predominantly across North America.
• UN/EDIFACT: the United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport, maintained under UN/CEFACT, which defines the internationally used EDIFACT messages such as ORDERS, INVOIC and DESADV.
• AS2 (RFC 4130): the Internet Engineering Task Force Request for Comments that specifies MIME-based secure peer-to-peer data interchange over HTTP, the basis of the AS2 transport for EDI.

Final thoughts

EDI is one of those technologies that is easy to underestimate precisely because it works so quietly. It has no marketing buzz, no annual conference hype cycle, and no one builds a startup pitch around it. Yet it moves an enormous share of the world's B2B documents every single day, reliably and at a scale that newer approaches have not displaced. Understanding it is not optional if you work anywhere near supply chains, procurement or retail integration.

The balanced view is the correct one. EDI is neither a relic to be sneered at nor a universal answer to be forced onto every problem. It is a mature, standardised, entrenched way of exchanging structured business documents between committed trading partners, with real strengths in stability and scale and real weaknesses in flexibility and real-time responsiveness. The modern skill is not choosing EDI or APIs, it is placing each flow on the transport that fits, and wiring the two together so a business speaks a modern idiom internally while still meeting its partners on the standard they mandate. Do that, and EDI stops being a legacy burden and becomes exactly what it has always been: the dependable machinery underneath the deal.

Related reading: Enterprise system integration explained, EDI vs API, SFTP integration, Business Central APIs and integrations, What is system integration.