X12 basics: envelopes and control numbers

The 60-second anatomy of an X12 file: ISA, GS, and ST envelopes, control numbers, ISA IDs and qualifiers, and why version 4010 is still everywhere.

You never have to read raw X12 to use EDISQ — but when a retailer's EDI team emails you about "the ISA qualifier" or "an ST/SE mismatch," this page decodes them.

Three envelopes, nested

Every X12 file is envelopes inside envelopes, each opened and closed by a paired segment:

ISA interchange — who's sending, to whom, when IEA GS functional group — documents of one kind, batched GE ST transaction set — one document (an 850, an 810…) SE the segments you actually care about live here

Each envelope's opener and closer carry a matching control number, and the closer states how many pieces it wraps. Receivers verify all of it — an ST/SE count mismatch or an unpaired control number is an automatic rejection before anyone looks at the contents. This bookkeeping is exactly the kind of thing EDISQ generates and verifies for you.

ISA IDs and qualifiers

The ISA segment names sender and receiver with an ID plus a qualifier saying what kind of ID it is — 01 is a DUNS number, ZZ is "mutually defined," 12 is a phone number. Your retailer's spec dictates which pair identifies them and what identifies you; those values are configured once per partner in EDISQ, usually by us during certification.

Versions

X12 publishes new versions continuously, but retail programs overwhelmingly still run 004010 ("4010"), with some on 5010. There's no upgrade race to win — you trade whatever version each partner's program mandates, and the per-partner map handles it.

The 997 speaks envelope

A 997 acknowledgment references these envelopes: it names the group and transaction-set control numbers it's answering and accepts or rejects at that level. That's why the 997 can say "received and parsed" but never "we agree with the contents" — business-level responses ride documents like the 855.