When a European retailer or distributor sends you its EDI specification, it lists the messages it expects by code: ORDERS, ORDRSP, DESADV, INVOIC, perhaps PRICAT and APERAK. The UN/EDIFACT directories define around 200 message types across every sector, from customs to healthcare, which is why a raw list of codes is so hard to use.
This page narrows it to what a consumer goods or retail supplier actually meets: every message in GS1 EANCOM 2002, the retail subset of EDIFACT, plus the one non-EANCOM message suppliers to manufacturers sometimes see. Each one has a plain-English summary and its TRADACOMS and X12 equivalents. If EDIFACT syntax is new to you, start with EDIFACT explained.
How EDIFACT message types are named
An EDIFACT message type is a six-letter code that identifies a business document, such as ORDERS for a purchase order or INVOIC for an invoice. It appears in the UNH segment at the start of every message, together with the directory it comes from:
UNH+1+INVOIC:D:01B:UN:EAN011'
Read that from left to right:
| Part | Meaning |
|---|---|
1 | Message reference, unique within the interchange |
INVOIC | Message type: invoice |
D:01B | Directory D.01B. Directories are released by UN/CEFACT and named by year and release, so D.96A is 1996's first release |
UN | Controlling agency: the United Nations |
EAN011 | Association code: GS1 EANCOM, version 011 of the INVOIC message |
The same message type exists in many directories, and the segments allowed in it change slightly between them. That is why a partner's spec says "INVOIC D.96A" or "ORDERS D.01B EAN010" rather than just the code. D.96A is still common in older European implementations; EANCOM 2002 is based on D.01B.
EANCOM is GS1's subset of EDIFACT for retail and consumer goods. It takes the full UN messages, removes the segments and codes retail does not need, and adds GS1 identifiers: GTINs for products, GLNs for parties and SSCCs for pallets and cartons. Most European retailers that ask for "EDIFACT" mean EANCOM, which is why this catalogue follows the GS1 EANCOM 2002 message list.
The six you will actually meet
Most retail suppliers never touch more than a handful of these messages. These six cover the order-to-cash cycle with almost any European retail customer.
| Message | What it is | Direction | X12 |
|---|---|---|---|
ORDERS | Purchase order | Buyer to you | 850 |
ORDRSP | Order response: accept, change or reject | You to buyer | 855 |
DESADV | Despatch advice (ASN), with SSCCs | You to buyer | 856 |
RECADV | Receiving advice: what actually arrived | Buyer to you | 861 |
INVOIC | Invoice, and credit notes with code 381 | You to buyer | 810 |
CONTRL | Syntax acknowledgement | Both ways | 997 |
The next tier depends on the partner: ORDCHG for order changes, APERAK for business-level errors, PRICAT for product and price data, and SLSRPT and INVRPT for sales and stock data. UK retailers that use EDIFACT, such as Tesco, Sainsbury's, Morrisons and Marks & Spencer, each publish their own list.
Every EANCOM message type
All 46 EANCOM 2002 messages, plus DELJIT, grouped by business flow. "Specialist" covers messages that are real and in use, but mostly between parties other than a supplier and its retail customer, such as banks, carriers and third-party warehouses.
Ordering
The buyer tells you what it wants, and you confirm what you can supply.
The buyer's order: products by GTIN, quantities, prices, delivery dates and delivery locations by GLN. It is the first message you have to read correctly, because everything you send back quotes it.
Your reply to an order: accept it, accept it with changes to quantity, price or date, or reject lines. Some partners want one for every order; others only when something changes.
The buyer changes or cancels an order it already sent: new quantities, new dates, lines added or removed. You normally answer it with an ORDRSP.
The buyer asks for your prices and terms for stated quantities, dates and delivery points before placing an order.
Your answer to a REQOTE, covering everything the buyer asked about. A quotation can lead straight to an ORDERS that references it.
Sends the terms of a contract already agreed, so that orders placed against it and invoices raised under it can be checked automatically.
The buyer asks where one or more previously sent orders have got to.
The supplier reports the status of an order, either in reply to an OSTENQ or on a schedule the two sides agree.
Delivery
What is on the lorry, and what actually arrived at the depot.
Tells the customer what is on its way: which orders, which products, how many, packed on which pallets and cartons identified by SSCC. The receiving depot uses it to plan the delivery and check it against the order.
What the customer actually received and accepted against your despatch. GS1 positions it as the basis for your invoice, so read it before you bill if your partner pays on received quantities.
The buyer or supplier tells a third-party warehouse holding the goods to despatch or collect a consignment, passing on the order details it needs to do so.
Instructs a warehouse or logistics provider to handle stock it holds but does not own: picking, packing, labelling, or moving goods between its warehouses.
Invoicing
Invoices, credit notes, and the VAT detail that goes with them.
The invoice. With a different document code the same message also carries credit notes (381), debit notes and pro forma invoices, so one map often handles all of them.
A summary of the tax on an invoice or batch of invoices, sent alongside them, or to auditors and tax authorities over a period.
Payment and remittance
What the customer is paying, and which invoices the payment covers.
Which invoices and credit notes a payment covers, for one currency and one settlement date. It is what lets your accounts team match cash to invoices without chasing the customer.
The buyer instructs its bank to pay several suppliers in settlement of invoices and credit notes. As a supplier you rarely see it; you see the money and, ideally, a REMADV.
A bank tells its customer, normally the supplier, which amounts have been or will be credited to its account and which transactions they settle.
A bank tells its customer, normally the buyer, which amounts have been or will be debited from its account to settle invoices.
The creditor instructs its own bank to claim amounts from one or more debtors and credit them to its account.
A bank reports the status of a financial message its customer sent, including errors found at application level.
The ordering customer asks its bank to cancel a payment message, or some of the orders in it. The bank answers with BANSTA.
A bank statement of booked items on the customer's account.
Payments made and items still outstanding on an account over a period, exchanged between trading partners or sent to an agent such as an accountant.
Product, price, and party data
Master data shared before anything is ordered: products, prices, and the locations you trade with.
Your product list with GTINs, descriptions, logistics data and prices, sent in full or as changes when lines are added, altered or removed. Customer-specific pricing can go in its own PRICAT.
Names, addresses, GLNs, contacts and bank details for the locations you trade with. GS1 describes it as the first message exchanged in a new trading relationship, re-sent whenever details change.
The buyer asks for information on selected products or product groups rather than the whole catalogue. The reply is a PRICAT or PRODAT.
Technical and functional product data with no commercial terms. GS1 advises using PRICAT instead, which can carry the same data.
Planning, stock, and sales
Forecasts, stock positions, and sell-through data that drive replenishment.
Stock levels at a location: held stock, minimum and maximum levels, reorder points. Used for vendor-managed inventory and replenishment in either direction.
What sold, by location and product, with prices and promotions. Retailers send it to suppliers for planning; GS1 is clear it does not replace an order.
Forecast sales by location and product, including planned promotions, for production planning.
Short-term delivery instructions and longer-term forecasts, by location or by product. It can authorise you to commit labour and materials.
Exact delivery times and quantities to feed a production line. It is a UN/EDIFACT message but not part of EANCOM, so retail suppliers rarely meet it; automotive suppliers using Odette guidelines do.
Acknowledgements and errors
Confirmation that a file arrived and could be read, or why it could not.
Confirms an interchange arrived and could be parsed, or lists the syntax errors. It says nothing about whether the business content was accepted, and a network provider can send it on a partner's behalf.
Generated by the receiving business system to confirm a message was processed or to report content errors, such as an unknown GTIN or GLN. Where CONTRL checks syntax, APERAK checks content.
Returns and claims
Goods coming back, and disputes over what was delivered or charged.
Announces goods to be returned and why (damaged, not ordered, past expiry), to ask for credit or replacement after the delivery has been received.
Tells the other party whether and how to return goods, usually in reply to a RETANN. It can also refuse the return or say to dispose of the goods instead.
The buyer disputes an invoice or credit note: wrong price, wrong product, no proof of delivery. It says whether the document is rejected or accepted with corrections.
Transport
Instructions and status messages between shippers and carriers.
A shipper instructs a carrier to move one consignment to one or more delivery points, with packages identified by SSCC.
Where a consignment is in the transport chain: sent on request, on a schedule, or when an agreed event or exception happens.
The consignor books transport or forwarding services for a consignment and commits to using them.
The carrier or forwarder answers a firm booking: accepted, pending, conditionally accepted or rejected.
The equivalent of several transport instructions in one message, giving the final details of multiple consignments to a carrier or forwarder.
The carrier gives notice that a consignment has arrived. It can also carry proof of delivery.
Other
Specialist and general-purpose messages.
Free text for anything no standard message covers. GS1 designed it mainly for early test transmissions between new partners.
Meter readings and consumption at one or more locations, which can feed invoicing or process control.
Results of tests against a product requirement: measurements, statistics and the test methods used.
Describes an external file sent separately, such as a photo, video or CAD drawing, and links it to the message and line it belongs to.
EDIFACT, TRADACOMS and X12 side by side
The same business documents exist in all three standards. This table maps the common flows by purpose; the fields inside differ, so converting between standards is a remap rather than a rename.
| Business document | EANCOM (EDIFACT) | TRADACOMS | X12 |
|---|---|---|---|
| Purchase order | ORDERS | ORDHDR | 850 |
| Order response | ORDRSP | ACKHDR | 855 |
| Order change | ORDCHG | Amendments sent within ORDHDR | 860 |
| Ship notice (ASN) | DESADV | DELHDR | 856 |
| Receiving advice | RECADV | DLCHDR | 861 |
| Invoice | INVOIC | INVFIL | 810 |
| Credit note | INVOIC with code 381 | CREHDR | 810 or 812, depending on the partner |
| Remittance advice | REMADV | SRMHDR | 820 |
| Price catalogue | PRICAT | PRIHDR | 832 |
| Inventory report | INVRPT | SNPSTS | 846 |
| Sales report | SLSRPT | No equivalent file | 852 |
| Syntax acknowledgement | CONTRL | No equivalent file | 997 |
| Application error | APERAK | No equivalent file | 824 |
For the full TRADACOMS list, including the book trade and other industry files, see TRADACOMS file types.
Order to cash in EDIFACT
Here is how the core messages fit together for one order from a European retailer:
- The retailer sends ORDERS. Products are identified by GTIN and the delivery point by GLN. Your translator or network may return a CONTRL to confirm the interchange was readable.
- You reply with ORDRSP. Confirm the order, or flag lines you cannot supply in full or on time. If the retailer changes its mind, it sends ORDCHG and you answer with another ORDRSP.
- You ship and send DESADV. It lists every pallet or carton by SSCC and what is in it, and it has to match the labels on the goods.
- The retailer sends RECADV. This is what the depot booked in. If it differs from your DESADV, that is your early warning of an invoice query.
- You invoice with INVOIC. Quote the order number and, where the partner asks for it, the despatch advice number. Credits for shortages or returns use INVOIC with document code 381.
- The retailer pays and sends REMADV. It lists which invoices and credits the payment settles, and any deductions.
At any step the retailer's system may return an APERAK if a message is readable but its content is wrong, such as an unknown GTIN or a price that does not match. Fix the data and resend.
Frequently Asked Questions
How many EDIFACT message types are there?
The UN/EDIFACT directories define around 200 message types across all sectors. GS1 EANCOM 2002, the subset used in retail and consumer goods, has 46. A typical supplier exchanges between four and eight of them with any one customer.
What is the difference between EDIFACT and EANCOM?
EDIFACT is the UN standard: the syntax, the directories and the full message definitions. EANCOM is GS1's subset of it for retail, with fewer optional segments, GS1 code lists, and GTIN, GLN and SSCC identifiers. An EANCOM message is a valid EDIFACT message; it carries EAN plus a version number in the UNH segment.
What does D.96A or D.01B mean?
They are UN/EDIFACT directory releases, named by year and release letter, so D.96A is the first release of 1996. Each directory fixes the segments and codes allowed in each message. Your partner's spec will name one, and your messages must follow that directory.
What is the EDIFACT equivalent of the X12 850?
ORDERS. The other common pairs are ORDRSP for the 855, DESADV for the 856, RECADV for the 861, INVOIC for the 810, REMADV for the 820 and CONTRL for the 997. The table above lists the rest.
What is the difference between CONTRL and APERAK?
CONTRL reports on syntax: whether the interchange could be read. APERAK reports on content: whether the receiving business system could process it, for example because a GTIN or GLN is unknown. GS1 specifies that APERAK comes from the application, never from the EDI translator.
Do UK retailers use EDIFACT or TRADACOMS?
Both. Many UK retailers built their EDI on TRADACOMS and still run it, while newer links and international retailers use EANCOM. Some accept either. Check each retailer's specification; our UK retailer pages, such as Ocado, Waitrose and Boots, summarise what each one asks for.
Which EDIFACT messages are used in automotive?
Automotive suppliers mostly use DELFOR delivery forecasts and DELJIT just-in-time call-offs, under guidelines published by Odette and its sister organisations, together with DESADV and INVOIC. DELJIT is not part of EANCOM, so retail suppliers rarely see it.
Related guides
- EDIFACT explained: syntax, envelopes and separators
- TRADACOMS file types: every UK TRADACOMS file in plain English
- TRADACOMS explained: the UK standard EANCOM is replacing
- EDI order lifecycle: the order-to-cash cycle in X12 terms
Sources
- EANCOM 2002 S3, Part II: the messages, GS1: the message list and version numbers
- EANCOM 2002 S3, Part I: EANCOM messages, GS1: the purpose of each message
- EANCOM 2002 Syntax 3, GS1
- Ordering message guidelines, Odette: DELFOR and DELJIT in automotive
- UN/EDIFACT D.16B: DELJIT, UNECE
Check any EDIFACT or TRADACOMS file in the free EDIFACT inspector. If a European or UK retailer has sent you an EDIFACT spec and you want those orders flowing into your ERP, book an intro call.