X12 vs EDIFACT: envelopes, syntax and versions compared

The short answer

X12 and EDIFACT do the same job with different syntax. X12, maintained by the X12 committee under ANSI, identifies documents by number and is the standard of North American retail. UN/EDIFACT, maintained under the United Nations, identifies them by name and is the common standard in Europe, mostly through GS1's retail subset EANCOM.

You do not choose between them. The trading partner's implementation guide names the standard, the version and the subset, and a supplier with partners on both continents runs both. What changes between them is the envelope, the delimiters, the version scheme, the acknowledgment and, most of all, the identifiers the partner expects. The business content of an order, a ship notice or an invoice stays close; the overview of what EDI is covers the shared ground.

X12 and EDIFACT side by side

The delimiter row matters in practice. EDIFACT has a release character: ?' inside a value is an apostrophe, not the end of the segment, so a name like O'NEILL can be written as O?'NEILL. X12 did not allow a delimiter character inside data at all; X12.6 states that delimiters "shall not be used in a data element value elsewhere in the interchange". X12 added a release character, ISX01, in version 8010 of January 2020. Retail guides are written for 4010, 4030 and 5010, so for most partners the old rule applies: an asterisk in a product description has to be removed or replaced before the file is built.

One purchase order in both

The order used across these pages, PO 4500018236 for 24 and 16 units, in an X12 850 and in an EANCOM ORDERS message. X12 first, without its envelope:

ST*850*0001~
BEG*00*SA*4500018236**20260928~
N1*ST*HARBOR RETAIL DC 07*92*0007~
PO1*1*24*EA*12.50**UP*614141104826*VP*10482~
PO1*2*16*EA*8.75**UP*614141104994*VP*10499~
CTT*2*40~
SE*16*0001~

That is an excerpt; the full order on the 850 page has 16 segments, with addresses, item descriptions and a total. The same order in EANCOM:

UNH+1+ORDERS:D:01B:UN:EAN010'
BGM+220+4500018236+9'
DTM+137:20260928:102'
DTM+2:20261006:102'
NAD+BY+0012345000010::9'
NAD+DP+0012345000072::9'
NAD+SU+0614141000005::9'
LIN+1++0614141104826:SRV'
QTY+21:24'
PRI+AAA:12.50'
LIN+2++0614141104994:SRV'
QTY+21:16'
PRI+AAA:8.75'
UNS+S'
CNT+2:2'
UNT+16+1'

Both messages count 16 segments, for different reasons. The X12 order spends 5 of its 16 on the ship-to (N1, N3, N4) and item descriptions (two PID segments), because the buyer identifies the DC by its own code 92*0007. The EANCOM order replaces names and addresses with three GLNs, puts the order date and the delivery date in DTM segments, and adds the UNS separator. The counts are checked the same way: SE01 and UNT 0074 both count from the header to the trailer inclusive, and a wrong count rejects the message before anything else is read.

The conversion rules are mechanical for five of the six facts. The UPC 614141104826 becomes the 13-digit GTIN 0614141104826 with a leading zero. The date gets the format code 102 (CCYYMMDD). CTT01 counts line items, like CNT+2. The ship-to does not convert: 0007 is a code from the buyer's own list, and the GLN 0012345000072 has to come from a table that the supplier keeps per partner. That table is mapping, not syntax, and it is where a converted order goes wrong.

Versions: releases and directories

Both standards publish new versions and neither retires the old ones in practice.

A supplier connected to Walmart and Kroger already runs two X12 versions. Between 4010 and 5010 the ISA11 element changed from a standards identifier (U) to the repetition separator, and codes and element lengths differ per release, so a map is tied to a version. The same holds for EDIFACT: a partner on EANCOM 1997 sends D.96A structures, a partner on EANCOM 2002 sends D.01B, and the syntax version, 3 or 4, is stated in UNB. GS1's syntax 4 examples for EANCOM 2002 start UNB+UNOC:4. UNOC is character set level C; level A, UNOA, allows upper case only, which is a common reason for a European partner to reject names with lower-case letters.

Tradacoms, the third standard in UK retail

UK retail had its own format before EDIFACT. Tradacoms was developed in the early 1980s as an EDI standard for retailers and wholesalers based mainly in the UK, used to process orders and invoices, and its manual was published by the Article Number Association (UK), the body that became GS1 UK. GS1 UK states that it has not provided support for it since 1 July 2017, and that it is not a GS1 global standard for EDI. Integration software still supports it: SAP's Integration Suite, for example, ships B2B scenarios for Tradacoms.

Its structure is its own. A transmission opens with STX and closes with END, each message is framed by MHD and MTR, and MTR carries the segment count, the job SE and UNT do in the other two. A UK partner that has not moved to EANCOM sends it, and its map is a third one next to X12 and EANCOM.

What this means for your integration

The standard is the partner's choice, and the difference that costs time is rarely the syntax. It is the identifiers: GLNs and GTIN-13s for an EANCOM partner, location codes and UPCs for an X12 partner, and the tables that turn each into your customer, address and item records.

We build the EDI integration per partner and per standard: X12, EANCOM or both, mapped to your ERP with the lookup tables kept next to the maps, counts and character sets checked before sending, and every 997 or CONTRL matched to its document. Tell us which partners and standards you deal with.