EDI: How Business Documents Moved Before the Internet

What the standard actually said EDI was

The most useful definition of electronic data interchange is not a vendor's but a government's. FIPS PUB 161-2, issued by the Computer Systems Laboratory at NIST on 29 April 1996 as a successor to FIPS PUB 161-1 of 1993, defines EDI as the computer-to-computer interchange of strictly formatted messages that represent documents other than monetary instruments, and states that the formatted data representing those documents may be transmitted from originator to recipient via telecommunications or physically transported on electronic storage media.

That last clause is worth sitting with, because it contradicts almost every modern retelling. A federal standard still in force in the mid-1990s treated a reel of magnetic tape carried across town by courier as a legitimate EDI transmission, provided the data on it was structured to an adopted standard. What made a document an EDI document was the agreed layout of its fields — where the invoice number sat, how a date was encoded, which separators delimited segments — not the wire it travelled over. The wire was interchangeable from the beginning. Everything that follows in this history is a series of substitutions at that interchangeable layer, made while the layout stayed comparatively fixed.

The founding legend, and what documentation survives

Nearly every account of EDI opens the same way: during the Berlin Airlift in 1948, an American officer named Edward A. Guilbert standardised the cargo manifests that had been arriving in incompatible formats, and had them sent by telex and telephone. The story is repeated so consistently that it functions as the field's origin myth. It should be treated as exactly that. The chain of evidence runs through award citations and trade retellings; a primary archival record of the airlift manifest standard and its transmission does not appear to be publicly available.

The sources cannot even agree on who Guilbert was. X12's own awards material, published by the ANSI-accredited standards developer that named its lifetime achievement award after him, describes him as a U.S. Air Force Colonel. Widely circulated popular accounts describe a U.S. Army Master Sergeant. Both cannot be right, and the discrepancy is instructive: when the standards body's own account of its namesake diverges from the version in general circulation, the version in general circulation has no better claim. What X12 does document is subsequent and checkable — that Guilbert served as president of the Transportation Data Coordinating Committee for nineteen years, and that he later developed a standard electronic message set at DuPont for cargo information exchanged with the carrier Chemical Leaman Tank Lines. It also names Joe Carley, Ralph Notto and Earl "Buddy" Bass as collaborators, three people the single-founder retelling routinely drops.

The point of laying these out side by side is not pedantry. It is that the disagreements cluster precisely where the commercial histories are most confident, and the confident dates are the ones with the weakest paper behind them. An article that picks a single number for any row above is choosing which unsourced tradition to join.

How the bits actually moved

Underneath the standards question sits a plainer one that most EDI histories skip: what physically happened when a purchase order left one company for another in the 1970s and 1980s. For a great deal of that traffic the answer was remote-batch communication over the telephone network. IBM's 2780 and 3780 data communication terminals — devices built around reading and punching card decks and driving line printers at the far end — spoke Binary Synchronous Communications, the half-duplex, character-oriented link protocol documented in Datapro's contemporaneous technical report on BSC. Bisync ran over leased lines where volume justified them and dial-up lines where it did not.

This is the layer that gives the era its texture. A transmission was a scheduled event, often overnight, between two parties who had agreed in advance on the line, the terminal emulation, the block sizes and the file layout. Failure was discovered by someone looking at a console or a printout in the morning. "Integration" frequently meant that the received batch was written to disk in a format the accounting system's import job could read at a fixed hour. The document had become machine-readable long before the exchange had become continuous.

Two answers to the same problem

Point-to-point Bisync scales badly: every new trading partner is another line, another schedule, another set of parameters. Two different infrastructures emerged to absorb that combinatorial cost, and they came from different worlds.

The commercial answer was the value-added network. Functionally, a VAN was a store-and-forward mailbox service: a sender delivered an interchange to the network, the network held it, and the recipient collected it on its own schedule, removing the requirement that both parties be available at once. Around that mailbox the operators sold the services that gave the model its name — translation between transmission protocols so that partners on different equipment could still exchange, translation between document formats where the two sides had standardised differently, and audit trails recording what was deposited and when it was retrieved. That audit function mattered as much as the delivery: it produced a third-party record of a commercial exchange.

The standards-body answer came from the OSI side of the world: carry EDI inside the X.400 message handling system. ITU-T Recommendation X.435 defines an EDI messaging system built on X.400, with a dedicated EDI content type and notification semantics appropriate to commercial documents rather than personal mail. Its lineage is documentable where much of this history is not. X.435 was issued by CCITT in 1991; the ITU-T edition approved on 18 June 1999 replaces that recommendation and consolidates its amendments, and the same text was published as ISO/IEC 10021-9. It remains listed as in force.

It is tempting to file X.400 under failed standards. That is a verdict rather than a finding, and it flattens a longer story — X.400 messaging persisted for years in aviation, military and some government settings. What can be stated without editorialising is narrower and more useful: X.435 was published, revised, and republished by ISO/IEC, and it lost commercial ground to internet transport.

Two syntaxes, two governance chains

The documents themselves were written in one of two major families, and their provenance is regularly mangled. The North American family is maintained by ASC X12, the ANSI-accredited standards committee — written without a period, as X12 and not "X.12". The stray period is common enough to appear in vendor page titles, and it invites confusion with the ITU-T X-series recommendations, an entirely separate lineage that happens to include the X.400 and X.435 documents discussed above.

The international family, UN/EDIFACT, is not a single standard and is not simply "an ISO standard". ISO 9735, first published on 15 July 1988 and reprinted with amendment in November 1990, specifies the application-level syntax rules only: the structure of the interchange and message envelope, the separators, the service segments. The message directories, data element definitions and code lists that make an EDIFACT invoice an invoice are UNTDID, maintained on the United Nations side by UNECE and later UN/CEFACT, with trade data elements governed separately. ISO/TC 154, the committee of record, describes a Joint Syntax Working Group established with UNECE in the late 1980s and a convergence in 1987 of separate United Nations and US/ANSI syntax proposals before ISO approval. Two governance chains, joined at the syntax layer — which is why "the UN invented EDIFACT" and "EDIFACT is an ISO standard" are both distortions of a shared arrangement.

That the two families were expected to converge is not hindsight. FIPS 161-2 cites ASC X12W/95-137, the X12 committee's own plan for technical migration to UN/EDIFACT, in a document whose purpose was to tell US federal agencies which standards to use.

The internet bridge

The IETF's involvement began with encapsulation rather than security. RFC 1767, published in March 1995 on the standards track, registers MIME content types for EDI objects — application/EDI-X12, application/EDIFACT, and application/EDI-consent for formats agreed bilaterally between the parties. It does not define an EDI syntax. It declares that these existing syntaxes are things internet mail can legitimately carry, and leaves their meaning to the bodies that own them.

The applicability statements that followed added what commercial exchange required: confidentiality, integrity, non-repudiation, and above all a receipt. RFC 3335 (September 2002, standards track) specifies AS1, EDI over SMTP with S/MIME or OpenPGP protection and signed message disposition notifications as acknowledgements. RFC 4130 (July 2005) specifies AS2, the same security model over HTTP — the transport to which VAN store-and-forward mailboxes are generally described as having given way. RFC 4823 (April 2007) specifies AS3 over FTP and completes the set — but it was published as Informational rather than on the standards track, and calling AS3 an internet standard misstates its status.

1. 15 July 1988

   ISO 9735 first published — the EDIFACT application-level syntax rules only; reprinted with amendment 1 November 1990.

2. 1991

   CCITT issues Recommendation X.435, carrying EDI messages within the X.400 message handling system.

3. March 1995

   RFC 1767 registers MIME content types for EDI objects: application/EDI-X12, application/EDIFACT, application/EDI-consent.

4. 29 April 1996

   FIPS PUB 161-2 issued by NIST, superseding FIPS PUB 161-1 (1993) and adopting the X12, UN/EDIFACT and HL7 families for federal EDI.

5. 18 June 1999

   ITU-T approves the X.435 edition replacing the 1991 CCITT recommendation and consolidating its amendments; identical text published as ISO/IEC 10021-9.

6. September 2002

   RFC 3335 specifies AS1 — EDI over SMTP with S/MIME or OpenPGP and signed MDN acknowledgements.

7. July 2005

   RFC 4130 specifies AS2 — the same secure MIME model over HTTP.

8. April 2007

   RFC 4823 specifies AS3 over FTP, published as Informational rather than standards track.

The transport changed; the syntax stayed

Put the two primary documents next to each other and the central claim of this page assembles itself. In 1996, a US federal standard adopted the X12, UN/EDIFACT and HL7 families for federal EDI — not mandating that agencies conduct EDI, but mandating these standards where they did. In 2005, an IETF specification for moving business data over HTTP named X12 and UN/EDIFACT as payloads it packages inside MIME. The internet did not displace those syntaxes. It arrived and offered to carry them, and the carriage was cheaper and more ubiquitous than a leased line or a subscription mailbox.

What died, then, was not EDI but a business model and a network topology. The VAN's core products — availability decoupling, protocol translation, and third-party evidence of delivery — were each answered by something in the internet stack. Store-and-forward availability became a server that stays up. Protocol translation became a smaller problem once both ends could speak HTTP. The audit trail became a cryptographically signed receipt returned by the trading partner itself. Later, SFTP and web APIs absorbed still more of the same traffic. Through all of it, the segment-and-element structure of the documents inside was substantially the structure agreed decades earlier, which is why the field's characteristic artefact — an integration specialist reading a raw X12 or EDIFACT interchange to find out why a partner's file rejected — is still a recognisable job.

Who EDI never reached

The second-order fact about this history is the one the standards documents cannot state, because it lives in commercial arrangements rather than specifications. Every EDI relationship rested on a trading-partner agreement: a negotiated document settling which standard and version applied, which message types were in scope, how identifiers mapped, what constituted acknowledgement, and what happened when a file failed. Add to that the network membership, the translation software, and the staff time to onboard each partner, and the cost of an EDI relationship was substantially fixed — largely independent of how many documents crossed it. That reading should be marked for what it is: the documentation behind it is commercial rather than standards-based, and thin. No specification states it, and this archive has not located authoritative figures for what a trading-partner agreement or a network account cost.

Fixed costs are amortised by volume, and only volume. A manufacturer exchanging tens of thousands of order and despatch messages a year with a distributor recovered that outlay quickly. A firm sending forty invoices a year to twenty different customers never could, and no improvement in transport changed the arithmetic, because the expensive part was never the wire. This is why EDI settled where it did — inside high-volume, long-lived supply-chain relationships between parties large enough to negotiate — and why it remained invisible to most businesses that issue invoices at all. Open interoperability networks, in which a participant connects once to reach many counterparties rather than negotiating each link, exist precisely because that per-relationship cost was the binding constraint; modern structured e-invoicing formats are treated separately in this archive.

But generalising the transmission problem does not touch the creation problem. The businesses EDI excluded were never going to emit a machine-readable interchange in the first place; they needed to produce a correct, complete, self-contained document — the right identifiers, the right dates, the right tax treatment, laid out so a human on the other side can read it and pay it. They produced those documents individually through the whole EDI era, and many businesses still do. Tooling aimed at that end of the market is therefore document-production tooling rather than interchange tooling: an invoice generator such as Invoice Maker addresses the composition and export problem that EDI's standards deliberately assumed away by starting from the premise that both parties already ran systems capable of speaking to each other.

Read that way, the history stops being a story about a technology that was superseded. It is a story about a layer that kept being swapped underneath a document format that mostly held still — and about a threshold, set by negotiation costs rather than engineering, that determined for decades which businesses got to stop printing and posting their paperwork and which did not.