In short: UK retail EDI runs on three message standards. Tradacoms is the UK-only legacy format still used by several large grocers. EDIFACT is the UN/international standard adopted by most European retailers and by newer UK implementations. ANSI X12 is the North American standard you will meet if you supply Amazon or a US-owned retailer. They carry the same business documents in different syntaxes, with different envelopes and different ways of saying “received”. Suppliers to more than one retailer usually need all three.
Why there are three
Tradacoms was published by the UK Article Numbering Association (now GS1 UK) in 1982, before EDIFACT existed. UK retailers built their systems on it and many never moved. EDIFACT arrived in 1987 as the UN’s international standard and became the norm in mainland Europe, so German and continental-owned retailers (Lidl, Aldi) brought it to the UK. X12 was standardised in the US in 1979 and is what Amazon, Walmart and most American businesses use.
None of the three is going away soon. Tradacoms was formally frozen in 1995, but “frozen” means “stable”, and retailers running it see no reason to migrate a system that works.
The same document, three ways
All three standards describe a purchase order, an ASN, an invoice and so on. The names differ:
| Business document | EDIFACT | Tradacoms | X12 |
|---|---|---|---|
| Purchase order | ORDERS | ORDHDR (Order) | 850 |
| Order response | ORDRSP | ACKHDR (Acknowledgement of order) | 855 |
| Advance shipping notice | DESADV | DELHDR (Delivery notification) | 856 |
| Invoice | INVOIC | INVFIL (Invoice) | 810 |
| Credit note | INVOIC (with BGM 381) | CRDHDR (Credit note) | 812 |
| Remittance advice | REMADV | PAYHDR | 820 |
| Functional acknowledgement | CONTRL | none | 997 |
| Product/price catalogue | PRICAT | PRIHDR | 832 |
Syntax and segments
Each standard is a stream of segments, each starting with a tag and containing data elements separated by delimiters. Beyond that they diverge.
EDIFACT
Segments end with ', elements are separated by +, and components within an element by :. Every message starts with UNH and ends with UNT. The header of an order looks like this:
UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+PO4471823+9'
DTM+137:20260915:102'
DTM+2:20260918:102'
NAD+BY+5000119000004::9'
NAD+SU+5012345000009::9'
NAD+DP+5000119004965::9'
LIN+1++05012345678900:SRV'
QTY+21:48'
UNT+10+1'BGM+220 says this is an order (220), with document number PO4471823, original (9). DTM+137 is the document date and DTM+2 the requested delivery date; the 102 qualifier means CCYYMMDD. NAD segments carry buyer, supplier and delivery point as 13-digit GLNs. The version in UNH (here D:96A, EAN008 subset) matters: Tesco, Sainsbury’s and Lidl each specify their own version and subset, and the same segment can have slightly different rules in each.
Tradacoms
Tradacoms uses ' as segment terminator, + between elements and : between sub-elements, like EDIFACT, but the segment vocabulary is entirely different and every message is wrapped in a file with a header and trailer. It uses 13-digit ANA codes rather than GLNs (they are numerically compatible) and dates are YYMMDD.
STX=ANA:1+5000119000004:TESCO+5012345000009:SUPPLIER+260915:143012+000123++ORDHDR'
MHD=1+ORDHDR:9'
TYP=0430+NEW-ORDERS'
SDT=5012345000009:SUPP001'
CDT=5000119000004'
FIL=0001+1+260915'
MTR=6'
MHD=2+ORDERS:9'
CLO=5000119004965:DEP17'
ORD=PO4471823++260915'
DIN=260918'
OLD=1+5012345678900+:+48+'
OTR=1'
MTR=6'
MHD=3+ORDTLR:9'
OFT=1'
MTR=3'
END=3'Note the structure: a file (STX…END) containing several messages (MHD…MTR), where the first is a header (ORDHDR), the middle ones are the actual orders (ORDERS), and the last is a trailer (ORDTLR) with counts. CLO is the customer’s location, ORD the order reference and date, DIN the delivery instruction date, and OLD an order line. Tradacoms element separators are = after the tag and + between elements, which trips up parsers written for EDIFACT.
Tradacoms has some quirks EDIFACT lacks. Prices are in pence with implied decimals, VAT is summarised in a dedicated STL/VAT structure in invoices, and the DNA (data narrative) segment is the free-text catch-all where retailers put anything the standard did not anticipate.
ANSI X12
X12 uses ~ as segment terminator, * between elements and > (or :) between components. Every transaction set starts with ST and ends with SE. An 850 begins:
ST*850*0001~
BEG*00*SA*PO4471823**20260915~
DTM*002*20260918~
N1*ST*AMAZON.CO.UK*92*XUKA~
N1*SU*SUPPLIER LTD*92*SUP12345~
PO1*1*48*CA*4.25**UP*501234567890~
CTT*1~
SE*8*0001~BEG*00*SA is an original (00) stand-alone order (SA). PO1 carries the line: quantity, unit (CA = case), price, and the product ID qualified by UP (UPC/GTIN-12). X12 dates are CCYYMMDD; identifiers are usually retailer-assigned codes (92 = assigned by buyer) rather than GLNs. Version is declared in the GS envelope (004010 is by far the most common).
Envelopes
Each standard wraps messages in an interchange envelope that identifies sender, receiver and a control number. Get these wrong and the retailer’s system will not even open the message.
| EDIFACT | Tradacoms | X12 | |
|---|---|---|---|
| Interchange header / trailer | UNB / UNZ | STX / END | ISA / IEA |
| Functional group | UNG / UNE (rarely used) | none | GS / GE |
| Message | UNH / UNT | MHD / MTR | ST / SE |
| Sender / receiver ID | GLN or agreed code, qualifier 14 (EAN) or ZZ | ANA code plus name | ISA06/ISA08 with qualifier (01 DUNS, 12 phone, ZZ mutual) |
| Optional service string | UNA:+.? ' declares delimiters | none | ISA is fixed-width, 106 chars |
The ISA segment in X12 is fixed-width and positional, so a missing space breaks it. Amazon’s onboarding tests fail on this more than on anything else.
Acknowledgements
This is where the three really differ, and where most missed-delivery arguments come from.
- EDIFACT: CONTRL. A syntax-level acknowledgement saying the interchange was received and either accepted or rejected, with error codes per segment. Not every retailer sends it; Lidl does, Tesco does for some message types. A CONTRL is not a business acceptance; an ASN can pass CONTRL and still be rejected at the depot.
- Tradacoms: nothing. There is no acknowledgement message in Tradacoms. If a retailer wants to confirm receipt they do it out of band (a report, a portal, or simply silence). Suppliers on Tradacoms should insist on transport-level confirmation (AS2 MDN or SFTP file listing) because it is the only proof of delivery they will get.
- X12: 997 (or 999). The Functional Acknowledgement confirms receipt of a functional group and reports syntax errors. Amazon sends a 997 for everything and expects one back for everything it sends; a missing 997 from you is treated as a failed delivery and counts against your vendor metrics.
Business-level acknowledgements (order responses, invoice status) are separate messages in all three standards (ORDRSP/ACKHDR/855, and for invoices APERAK or 824).
Which UK retailers use which
Retailers change over time, and many support more than one standard, but as of writing the common picture is:
| Retailer | Primary standard | Notes |
|---|---|---|
| Tesco | Tradacoms, EDIFACT | Tradacoms for many long-standing suppliers; EDIFACT (D96A) for newer onboarding and some categories |
| Sainsbury’s | EDIFACT, Tradacoms | Migrated much of its estate to EDIFACT; Tradacoms still live for some suppliers |
| Lidl GB | EDIFACT | EDIFACT throughout, via AS2, with CONTRL acknowledgements |
| Aldi UK | EDIFACT | EDIFACT (D01B), AS2 |
| Morrisons | Tradacoms, EDIFACT | Tradacoms for most grocery suppliers |
| Asda | Tradacoms, EDIFACT, X12 | Walmart heritage means X12 in some flows |
| Boots | Tradacoms, EDIFACT | |
| Waitrose | Tradacoms | |
| Amazon UK (Vendor Central) | X12, EDIFACT | X12 004010 by default; EDIFACT available on request |
| Ocado | EDIFACT |
Always confirm with the retailer’s EDI team. The specification they send you overrides any general table.
Choosing an approach
If you supply one retailer, implement their standard and nothing else. If you supply two or more, you will almost certainly need at least two standards and possibly all three, plus AS2 for some and SFTP for others. At that point the sensible design is a single internal representation of an order, an ASN and an invoice, with translators to and from each standard at the edge. That way your warehouse and accounts system see one format, and each retailer sees theirs.
How FTP EDI helps
FTP EDI speaks all three standards and translates them into one canonical model, so your WMS and accounts system only ever deal with one format. Each retailer’s version, subset and envelope rules are maintained by us. We send and chase acknowledgements (CONTRL, 997, MDNs) and alert you when a retailer’s system has rejected something, so a silent failure never becomes a missed delivery.
- See the translation and acknowledgement flow on the product tour.
- Read how we produce ASNs and labels and invoices in every standard.
- Retailer specifics: Tesco, Sainsbury’s, Lidl, Amazon UK, Boots, Morrisons.