What is EDI?

Electronic Data Interchange is the structured, automated and standardised exchange of commercial documents between the information systems of two distinct organisations, with no human intervention on the transactional content.

Definition

We speak of EDI as soon as a commercial document — purchase order, order acknowledgment, despatch advice, invoice, inventory report — is generated automatically by an information system, transmitted in a structured format that the recipient system can interpret unambiguously, and processed by it without any human intervention on the transactional content. The content follows a normalised syntax — EDIFACT under the United Nations, X12 under the American ANSI, cXML in the Ariba/SAP ecosystem, UBL/PEPPOL for European e-invoicing — and travels over a secure transport protocol: AS2, OFTP2, SFTP, AS4, or a value-added network (VAN).

The scope of EDI is deliberately commercial: it covers transactional flows between buyers and suppliers, between shippers and carriers, between payers and healthcare providers, between administrations and filers. It does not cover inter-application communication inside a single organisation (that falls under EAI or the application bus), nor non-transactional content flows — product documentation, marketing, arbitrary flat files.

Historical roots

The concept of EDI was born in the late 1960s in North American rail and road transport. Carriers had long exchanged shipping manifests by telex or paper form; they were looking for a way to automate these transmissions at growing volume. Edward A. Guilbert, nicknamed the "father of EDI", piloted as early as 1965 at DuPont the first automated exchange of cargo lists with a carrier by telex, in a proprietary format: that is the direct ancestor of what we call EDI today.

America: TDCC then ASC X12

By the 1970s the need to standardise such exchanges became pressing. The Transportation Data Coordinating Committee (TDCC) published in 1975 the first multi-party EDI standard in the United States, focused on transport. The American National Standards Institute (ANSI) commissioned in 1979 an accredited committee — the Accredited Standards Committee X12 — to broaden the approach to every industry. The first X12 transaction set (version 003010) was ratified in 1983, followed by 004010 in 1997 — the version that remains, in 2026, the most widely deployed in North American retail despite the arrival of 005010 (mandated by HIPAA for healthcare) and 006020.

Europe: EDIFACT and UN/CEFACT

In Europe, several national standards emerged in parallel throughout the 1970s and 1980s — TRADACOMS in the UK, GENCOD in France, SEDAS in Germany. The United Nations Economic Commission for Europe (UNECE) launched the UN/EDIFACT project (EDI For Administration, Commerce and Transport) in 1986 to unify these approaches. The syntax was carved into ISO 9735 as early as 1988, and the message directory has been updated twice a year since 1993, with releases named D.<YY>A in spring and D.<YY>B in autumn — from D.93A in 1993 to D.24B in 2024. The custodian of the standard is now the UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business), which gathers national and sectoral delegations on a volunteer basis.

The three distinctive characteristics

EDI is not defined merely by the fact that a document is sent electronically: three conjoined properties distinguish it from plain file exchange.

1. Normalised structure

An EDI message is not an arbitrary string but a structure published and versioned by a standards body. In EDIFACT D.96A, the segment BGM+220+ORDER789+9 is not free text: BGM is the Beginning of Message, 220 is the "Order" value in UN/EDIFACT list 1001, ORDER789 is the business number, and 9 means "Original" in list 1225. Any integrator anywhere in the world can read and interpret that segment in exactly the same way by referring to UN/CEFACT directories; the same holds for an X12 transaction, a cXML document or a UBL invoice. It is this de jure portability that distinguishes EDI from a proprietary CSV export between two private companies.

2. Mutual identification

Each party to an EDI exchange is identified by a stable, persistent and international code that is neither an email address nor a URL. The most widespread schemes are the GLN (Global Location Number, GS1, ICD 0088) in retail, the DUNS (Dun & Bradstreet, ICD 0060) in North American industry, the SIRET in France for public-sector flows, or the PEPPOL identifier in the form iso6523-actorid-upis::<ICD>:<value> for European invoicing. The practical consequence is that a message remains interpretable even when a partner changes information system, operator or email domain: the economic identifier survives infrastructure changes.

3. Two-way acknowledgment

EDI finally requires a formalised return. In EDIFACT, that return is CONTRL for the syntactic acknowledgment (the recipient confirms that the interchange has arrived and is well-formed) and APERAK for the application acknowledgment (the business engine confirms that the message has been accepted or rejected with a reason). In X12, the transaction 997 (Functional Acknowledgment, legacy) or 999 (Implementation Acknowledgment, recent, 5010+) plays that role. Above these business acknowledgments, the AS2 transport protocol adds a cryptographic MDN (Message Disposition Notification) that yields a non-repudiation-of-receipt proof (NRR). No EDI exchange can be designed without that loop — it is what distinguishes EDI from a plain SFTP drop "in the hope that it lands".

What EDI is not

A few frequent misconceptions deserve to be defused upfront:

• An email with an XML attachment is not EDI — there is no formalised acknowledgment, no stable mutual identification, and most often no compliance with a public standard.
• A regular SFTP drop of CSV files is not EDI either — the transport is fine but the structure is not standardised and there is no acknowledgment.
• EDI does not require a specific syntax: segment-based EDIFACT, segment-based X12, XML cXML, XML UBL, or even a future JSON payload — all of them can be EDI as long as the three characteristics above are present.
• EDI is not the whole of B2B: every EDI exchange is a B2B exchange, but a good half of modern B2B exchanges (REST APIs, supplier portals, marketplaces) are not structured as EDI. The next page handles that question in detail.

Further reading

Three natural doors to keep going:

• B2B vs EDI — the exact boundary between the broad B2B perimeter and the strict EDI perimeter.
• Interchange journey — the concrete steps, ERP by ERP, of an ORDERS that leaves, travels and gets acknowledged.
• EDIFACT ORDERS D.96A — the canonical page for the most exchanged message on the planet.
• EDIFACT Validator — to learn by doing on a real message.