EDI, or Electronic Data Interchange, was invented in the 1960s to replace paper documents like purchase orders and invoices. It grew in popularity with the rise of the internet, moving from an option to a necessity for global business. EDI is used in 60 to 86 percent of businesses focused on supply chain and healthcare, running quietly in the background of Fortune 500 companies. While newer ideas emerge for distributing business documents, EDI remains dominant because of the infrastructure built over many years. Switching to a modern approach carries enormous cost and risk.

How EDI Works

EDI uses a strict standard format built on universal codes instead of plain language. Instead of saying “send to the warehouse,” you put code 92 in position A4. The automated receiver reads that code and the computer instantly knows what to do.

Every EDI document, called a transaction set, has a number. An 810 is an Invoice. An 850 is a Purchase Order. Just like human languages, EDI has dialects depending on geography: ANSI X12 is the standard in North America while Europe and Asia use EDIFACT.

A few numbers that illustrate the scale:

• 5 to 10 major global standards
• 300+ transaction types in X12 alone
• Over 2000 unique data elements grouped into segments in X12

EDI Mapping: The Critical Bridge

Internal databases do not store data in EDI format. Systems export files as CSV, JSON, or XML, then translate that output into the strictly typed EDI format. This translation process is called EDI mapping, and it acts as a critical bridge between the flexible human-readable structures used in modern development and the rigid, highly compressed segments required for commerce.

Because EDI is designed to be processed at high speeds, it strips away descriptive labels. A clear field like <CustomerName> becomes a cryptic segment code like N1*BT. The translator relies on a pre-defined specification or implementation guide to know exactly which piece of data belongs in which slot.

If your internal database structure changes, the map needs to be updated to find that data. If it is not, “drift” occurs: your internal reality no longer matches the outgoing EDI contract. The result is rejected transmissions and expensive troubleshooting.

Reading an EDI File

Below is a minimal EDI 850 Purchase Order. Real files are much larger, but this captures the essential structure.

ISA*00*          *00*          *ZZ*SENDERID       *ZZ*RECEIVERID
*260121*1230*U*00401*000000001*0*P*>~
GS*PO*SENDERID*RECEIVERID*20260121*1230*1*X*004010~
ST*850*0001~
BEG*00*SA*PO12345**20260121~
SE*4*0001~

Each segment serves a specific purpose:

ISA is the Interchange Control Header, the outermost envelope. It identifies the sender and receiver, the date (260121 = Jan 21, 2026), and the interchange control number used for tracking.

GS is the Functional Group Header. It groups similar transaction sets together. PO indicates this group contains Purchase Orders, and 004010 is the specific X12 version in use.

ST is the transaction set header, the inner envelope marking the start of a single document. 850 confirms this is a Purchase Order. The control number 0001 must match the number in the SE trailer.

BEG is the Beginning Segment for a purchase order, the first content segment with actual order details. 00 is the purpose code (Original), SA means stand-alone order, PO12345 is the purchase order number, and 20260121 is the order date.

Why This Matters

The translator that converts your internal data to EDI is only as good as the map it follows. That map is built against a partner’s implementation guide, which is a living document. Partners update their requirements, add required segments, change field formats, and deprecate old codes. When those changes happen silently and your map is not updated, drift occurs.

Most legacy EDI tools only confirm delivery. They do not check whether the content inside matches what the partner currently expects. That gap is where chargebacks and compliance violations originate.

Schema drift is not a rare edge case. It is the normal state of long-running B2B integrations.