EDI STRUCTURE
How to Read an EDI File Without Guessing
Identify the syntax and delimiters first, reconcile the envelopes second, and only then interpret the business transaction against the partner guide.
SHORT ANSWER
The decision in one minute
Treat an EDI file as nested, position-sensitive records—not prose. Preserve the raw interchange, identify X12 or UN/EDIFACT and its separators, then walk from outer envelope to group or message to individual segments. A syntactically readable file is not necessarily valid for a trading partner.
Freeze the evidence before formatting
Keep an untouched copy and record how the file arrived. Line wrapping, “smart” punctuation, character-set conversion, or a global find-and-replace can alter separator characters and make a valid interchange unreadable. Work on a copy and compare byte-level differences when corruption is suspected.
Do not begin by splitting on an expected asterisk, plus sign, or apostrophe. X12 declares separators through fixed positions in ISA; UN/EDIFACT can declare service characters with UNA, while syntax rules also define defaults. Let the actual interchange tell you how it is delimited.
Read from the outside inward
In a typical X12 interchange, ISA/IEA form the interchange envelope, GS/GE contain a functional group, and ST/SE contain a transaction set such as an 850 purchase order. Control numbers at each paired boundary should agree. SE01 counts segments from ST through SE, including both.
In UN/EDIFACT, UNB/UNZ bound an interchange and UNH/UNT bound a message; optional functional groups use UNG/UNE. UNECE defines a message as an ordered series beginning with the message header and ending with its trailer. That hierarchy gives you checkpoints before you interpret fields.
Separate syntax from business meaning
A segment tag identifies the record type; elements and composite components are positional. Empty positions can still matter. A formatter can expose structure, but it cannot infer that a code, qualifier, date, or identifier is commercially correct.
Read the standard directory for the declared version, then the trading partner implementation guide and agreement. A standard message deliberately permits more data than one implementation normally uses; the partner guide determines which optional segments become required and which code values are accepted.
Use counts and control numbers as invariants
Reconcile declared transaction, message, and group counts before troubleshooting business content. A mismatch often points to truncation, concatenated interchanges, a damaged terminator, or an edit that introduced a false boundary.
Control numbers are identifiers, not arithmetic proof that the payload is correct. Preserve leading zeros and compare the exact strings in matching header and trailer elements. Duplicate control numbers may be a partner-specific replay concern even when the envelope is structurally sound.
A practical workflow
- Save the original bytes and work on a copy.
- Identify X12 or UN/EDIFACT, version, encoding, and declared separators.
- Format into numbered segments without changing content.
- Reconcile envelope pairs, control numbers, and declared segment/message counts.
- Use the correct directory and partner implementation guide to interpret fields.
- Record findings with the original interchange and acknowledgment.