EDI: Concepts and Vocabulary

Updated Jul 26, 2026
EDI

EDI: Concepts and Vocabulary

EDI — Electronic Data Interchange — is how trading partners exchange business documents as structured files instead of as paper, PDFs or email. A customer sends you a purchase order as a file your system can read; you send back a shipment notice and an invoice the same way. No one rekeys anything.

If you make things for automotive, steel, food or retail customers, EDI is usually not optional: your customer mandates it, hands you a specification, and tests you against it before you go live. This page is the short version of the vocabulary in that specification. The rest of this section assumes it.

Two standards

StandardWhereLooks like
X12North AmericaNumbered documents — 850, 856, 810 — with segments like BEG, PO1, N1.
EDIFACTEurope and internationalNamed documents — ORDERS, DESADV, INVOIC — with segments like BGM, LIN, QTY.

DataMagik reads and writes both. Which one you use is decided by your customer, not by you.

The envelope

An EDI file is not one document. It is a set of nested wrappers, and almost every problem you will ever troubleshoot lives in one of them.

ISA  interchange header   — who sent it, who it is for, one control number
 GS  group header         — one business function (all the purchase orders)
  ST transaction set      — ONE document. This is the purchase order.
     ...the actual content: BEG, N1, PO1, ...
  SE transaction set trailer  — segment count + the ST control number
 GE  group trailer        — how many ST sets + the GS control number
IEA  interchange trailer  — how many GS groups + the ISA control number

EDIFACT uses UNB/UNG/UNH for the same three levels, and an optional UNA segment to declare its punctuation.

Three things about the envelope matter in practice:

  • The ISA identifies the sender. ISA05/ISA06 are the sender's qualifier and ID — for example qualifier ZZ with ID ACMESTEEL. This pair is how DataMagik decides which trading partner a file came from. Get it wrong and nothing else works.
  • The delimiters are declared in the file itself. The ISA header states the element separator, sub-element separator and segment terminator. DataMagik reads them from the file rather than assuming * and ~.
  • Every trailer carries a count. SE counts segments, GE counts transaction sets, IEA counts groups. If a count disagrees with reality, the file is malformed — this is the single most common reason a partner rejects what you send.

Transaction sets

A transaction set is one business document. The number (or name) tells you what it is:

X12EDIFACTWhat it is
850ORDERSPurchase order — your customer is ordering something
855ORDRSPOrder acknowledgment — your answer to the 850
856DESADVAdvance ship notice (ASN) — what is on the truck
810INVOICInvoice
830DELFORPlanning schedule / material release — a forecast
862DELJITShipping schedule — a firm call-off against a release
820REMADVRemittance advice — what a customer paid, and against which invoices
997 / 999CONTRLFunctional acknowledgement — "your file arrived and here is what I thought of it"

DataMagik ships starter mappings for 26 of these. See Mapping Specs for the full list.

Control numbers

Each envelope level carries a control number: ISA13 on the interchange, GS06 on the group, ST02 on the transaction set. They exist so both sides can refer to a specific document unambiguously — "we never received interchange 000000101".

Control numbers are expected to increment and not repeat. Partners monitor for gaps and for reuse, and some reject a duplicate outright. DataMagik keeps a counter per trading partner and reserves the next number atomically each time it builds a document, so two documents built at the same moment cannot collide. It is also why replaying a document deliberately does not consume a control number — a replay is a re-run of a decision, not a second transmission.

Why acknowledgements exist

EDI is asynchronous. You drop a file somewhere and the other side picks it up later. Without a reply you have no idea whether it arrived, whether it parsed, or whether it was silently discarded.

The functional acknowledgement — 997 in X12, 999 in some healthcare and automotive profiles, CONTRL in EDIFACT — closes that loop. It says, per transaction set:

  • A — accepted
  • E — accepted, but with errors worth telling you about
  • R — rejected

A 997 says nothing about whether anyone agreed to your order — only that the file was structurally acceptable. A business-level rejection ("we do not make that part") is a different document: an 824 Application Advice, or an 855 with rejected lines.

Next: set up who you exchange documents with in Trading Partners, then teach DataMagik to read their documents in Mapping Specs.
Was this page helpful?