TRADACOMS: The UK Retail EDI Standard Explained

If you are setting up EDI with a UK retailer, you may be handed a TRADACOMS specification rather than an EDIFACT one. It looks like EDIFACT at first glance, but it is a separate standard with its own envelope, its own file structure, prices with no decimal point, and a strongly UK-specific design. Plenty of established UK supplier relationships still run on it.

This guide covers where TRADACOMS came from, why it is still here, how its syntax and files work, two live examples (an order file and an invoice file) you can open in the inspector, and how it maps to EDIFACT and the GS1 EANCOM subset that UK retail is gradually moving to.

What is TRADACOMS?

TRADACOMS (Trading Data Communications) is an EDI standard developed for the UK retail sector, introduced in 1982 and maintained by the Article Numbering Association (ANA), which is now GS1 UK. It was built on the UN/GTDI syntax, one of the precursors of EDIFACT, which is why the two look alike.

A short history

GS1 UK's own EDI guidance for new users describes TRADACOMS as commonly used in the UK, designed only for the UK market, and not developed and only minimally supported since the 1990s. It says the industry is slowly moving to EANCOM and recommends EANCOM or GS1 XML for new implementations.

Why UK retail still uses TRADACOMS

• It works. The order, delivery and invoice files cover what UK grocery and general merchandise trading needs, and the links were built and tested decades ago.
• UK VAT is built in. Every invoice carries VAT totals per rate, and every invoice file carries a VAT summary for the whole file. That suited UK accounts payable teams from day one.
• Migration costs both sides. Moving a supplier community from TRADACOMS to EANCOM means every supplier re-mapping and re-testing. Retailers tend to move gradually, often starting with new suppliers.
• The book trade standardised on it. The UK book trade uses TRADACOMS-based messages maintained for that industry by BIC, which publishes its own invoice specification.
• Retailers still publish TRADACOMS specs. The John Lewis Partnership, for example, publishes a TRADACOMS invoice specification on its supplier portal.

Requirements differ by retailer, and many run TRADACOMS and EANCOM side by side. Check your customer's own guide: our UK pages for Tesco, Sainsbury's, Asda, Morrisons, Ocado, Waitrose, Marks & Spencer, Boots and the Co-op are a starting point.

TRADACOMS syntax

TRADACOMS uses the same separators as default EDIFACT, with one visible difference: the segment tag is followed by = instead of +.

EDIFACT:    NAD+BY+5012345000008::9'
TRADACOMS:  CDT=5012345000008+HARBOUR LANE STORES LTD'

Specific segments, few qualifiers

EDIFACT has one generic NAD segment and a qualifier for each party. TRADACOMS defines a separate segment for each purpose: SDT for supplier details, CDT for customer details, CLO for the customer's delivery location. Each field has a fixed position and a short mnemonic name in the specification, such as SNAM (supplier's name) or QTYI (invoiced quantity). Reading a TRADACOMS segment means counting + signs against the spec.

Implied decimals

TRADACOMS numbers carry no decimal mark. The specification of each field says how many decimal places are implied. BIC's TRADACOMS trade invoice specification shows how this works in the invoice file:

The V marks where the decimal point would be. BIC also notes that all four decimal places should be sent on cost prices, padding with zeros. Implied decimals are where most TRADACOMS mapping bugs live: £6.50 sent as 650 in a four-decimal field is read as 6.5p.

Dates and other conventions

Dates are YYMMDD and times HHMMSS, so 261011:091500 is 11 October 2026 at 09:15:00. The UK VAT category codes in invoice files are single letters; the John Lewis spec lists S (standard), Z (zero), X (exempt) and L (lower rate).

How a TRADACOMS transmission is built

The biggest structural difference from EDIFACT is the file. In EDIFACT, each message stands alone. In TRADACOMS, a transmission contains files, and each file is a sequence of messages: a header message, one or more detail messages, and one or more trailer messages. Data common to every order or invoice is sent once in the header instead of being repeated.

STX                            start of transmission: sender, receiver, date, reference
  MHD 1  ORDHDR                file header message
         TYP SDT CDT FIL
  MTR    6 segments
  MHD 2  ORDERS                detail message: one order
         CLO ORD DIN OLD OLD OTR
  MTR    8 segments
  MHD 3  ORDERS                detail message: another order
         ...
  MTR
  MHD 4  ORDTLR                file trailer message
         OFT
  MTR    3 segments
END                            end of transmission: 4 messages

Every message, whatever its role, is wrapped the same way:

• MHD (message header) gives the message number within the transmission and the message type and version, for example MHD=1+ORDHDR:9'.
• MTR (message trailer) gives the number of segments in the message, counting MHD and MTR.

The whole transmission sits inside STX (start of transmission) and END (end of transmission), and END gives the number of messages. Optional BAT and EOB segments can group files into batches. Some partners also ask for a reconciliation message, RSGRSG, at the end of the transmission; John Lewis's spec pairs it with the syntax identifier ANAA in STX.

The STX segment

File types

Product, price, stock, availability, payment and other files follow the same pattern. Our TRADACOMS file types reference lists every one, grouped by business flow.

Example 1: an order file with two orders

The fictional retailer Harbour Lane Stores sends one order file to the fictional supplier Kestrel Valley Homeware, with an order for its York store and one for its Leeds store. Identifiers are made-up GS1-style numbers with valid check digits.

The cost price in each OLD (OUCT) is 65000: £6.50 written with four implied decimals, the convention BIC's invoice spec uses for cost prices. Confirm the order file's number formats in your partner's spec before you rely on them.

Three counts to check on every order file: each MTR matches the segments from its MHD to the MTR itself, OTR matches the OLD lines in each order, and OFT matches the number of ORDERS messages. END must equal the number of MHD segments. See the TRADACOMS order file guide for every field.

Example 2: an invoice file with mixed VAT

Kestrel Valley invoices the York order. Two lines are standard-rated at 20%; the cookbook is zero-rated. The invoice file adds two things the order file does not have: VAT sub-totals inside each invoice (STL), and a VAT summary for the whole file (VATTLR).

The field positions follow the published BIC and John Lewis invoice specs: ILD runs line sequence, product codes, units per traded unit, quantity, unit cost (AUCT), extended cost (LEXC), VAT code (VATC), VAT rate (VATP), then description. STL and TLR leave discount and surcharge fields empty when there are none, which is why you see runs of +++++.

The arithmetic has to hold at every level. Each STL totals the ILD lines at its rate. TLR totals the STL segments. Each VRS totals the STL segments at its rate across every invoice in the file, and TOT totals the VRS segments. For the full field list, see the TRADACOMS invoice file guide, and for credits, the credit note file guide.

How TRADACOMS maps to EANCOM

The two standards carry the same business data in different shapes. The biggest shift is that file-level data in TRADACOMS (supplier, customer, VAT summary) has to appear inside every EANCOM message, because each EDIFACT message stands alone.

Our EDIFACT ORDERS guide and EDIFACT INVOIC guide show the EANCOM side of the same order and invoice.

TRADACOMS vs EDIFACT

Message equivalents

Watch the names. TRADACOMS and EDIFACT both have messages called ORDERS and INVOIC, but they are different formats. A TRADACOMS INVOIC inside an invoice file cannot be read by an EDIFACT INVOIC parser.

Moving from TRADACOMS to EANCOM

1. Map business data, not segments. A TRADACOMS order file and an EANCOM ORDERS carry the same order. Map both to your ERP's order model instead of converting one format into the other segment by segment.
2. Expect one EDIFACT message per document. Header data that TRADACOMS sends once per file is repeated in every EANCOM message, and the file-level VAT summary disappears.
3. Recheck every number. Implied decimals in TRADACOMS become explicit decimals in EANCOM. Quantity, price and VAT rate fields are where conversions go wrong.
4. Re-agree VAT codes. TRADACOMS uses S, Z, X and L. EANCOM's own list is S, E and A, with other codes set by national guidelines. Get the new codes from your customer.
5. Keep GS1 identifiers. Both standards use GLNs and GTINs, so your master data carries over.
6. Run both in parallel during cut-over and compare the orders and invoices that reach your ERP.

OrderSync supports EDIFACT, EANCOM and TRADACOMS alongside X12, PDF, CSV and email, so you can run both formats with the same customer during a migration.

Frequently Asked Questions

Is TRADACOMS still used?

Yes. GS1 UK stopped supporting it on 1 July 2017 and recommends EANCOM or GS1 XML for new users, but UK retailers and their suppliers still exchange orders, delivery notes and invoices in TRADACOMS, and the UK book trade has its own TRADACOMS-based messages.

What is the difference between TRADACOMS and EDIFACT?

TRADACOMS is a UK-only standard from 1982 that groups messages into files with header and trailer messages, uses = after the segment tag, sends numbers with implied decimals, and assumes sterling and UK VAT. EDIFACT is the international UN standard with self-contained messages, generic qualified segments, explicit decimals and any currency. EANCOM, the GS1 subset of EDIFACT, is the recommended replacement for TRADACOMS.

What do STX and END mean in TRADACOMS?

STX starts a transmission and identifies the syntax, sender, receiver, date and references. END closes it and states how many messages it contained. They do the job of UNB and UNZ in EDIFACT, or ISA and IEA in X12.

What is ORDHDR in TRADACOMS?

ORDHDR is the header message of a TRADACOMS order file. It carries data common to every order in the file, such as supplier and customer details and the file generation number. It is followed by one ORDERS message per order and an ORDTLR trailer.

How do implied decimals work in TRADACOMS?

Each numeric field has a fixed number of implied decimal places set by the specification. In the invoice file, BIC's spec gives unit and line costs four implied decimals (129900 is £12.99), VAT rates three (17500 is 17.5%) and VAT sub-totals two (4325 is £43.25). Always take the format from your partner's spec.

What is VATTLR?

VATTLR is the file VAT trailer in a TRADACOMS invoice or credit note file. It comes after the last invoice and holds one VRS segment per VAT rate used anywhere in the file, totalling the amounts before VAT, the VAT, and the amounts payable.

Can an EDI inspector read TRADACOMS?

TRADACOMS shares separators with EDIFACT but has a different envelope and file structure, so a parser needs to support it explicitly. The free EDIFACT inspector reads both and checks the MTR and END counts; for X12, use the EDI inspector.

Related guides

• EDIFACT explained: the international standard TRADACOMS is being replaced by
• TRADACOMS file types: every TRADACOMS file, grouped by business flow
• TRADACOMS order file, invoice file, credit note file and delivery confirmation: field-by-field guides
• EDIFACT ORDERS and EDIFACT INVOIC: the EANCOM equivalents
• EDIFACT message types: the EDIFACT catalogue for comparison

Sources

• Ending support for TRADACOMS, GS1 UK
• How can GS1 UK support me with TRADACOMS?, GS1 UK
• EDI guidance for new users, GS1 UK
• Trade Invoice TRADACOMS specification, BIC
• EDI TRADACOMS invoice specifications, John Lewis Partnership
• Purchase order components for TRADACOMS, IBM
• TRADACOMS, Wikipedia

Check a TRADACOMS or EDIFACT file in the free EDIFACT inspector before you send it to your customer.