EDI between retailers and suppliers: the file is the easy part

Two cases of orange juice

A buyer orders two cases of orange juice. In the buyer's system, a case holds twelve bottles, so twenty-four are expected. At the supplier, the same case holds six. The warehouse picks two cases, the truck leaves with twelve bottles, and nobody made a mistake. Each side followed its own product record.

Then the invoice arrives. It matches neither the order nor what the store thinks it received, and someone spends a while on the phone working out why. Repeat that across a few hundred items and a few dozen suppliers, and you have the daily life of a purchasing team that works without shared master data.

EDI does not fix this. It makes it visible, and fast. That is its main strength, provided you are ready for it.

EDI in plain words

EDI stands for electronic data interchange. Instead of sending a purchase order by fax, email or PDF, the retailer's system sends a structured file that the supplier's system reads directly. Nobody keys the order in again. Every piece of information has a fixed place and a fixed code, so both systems understand it the same way.

These rules have a name. The grammar is called UN/EDIFACT and it is maintained under a United Nations commission. For retail and distribution, GS1, the organisation behind barcodes, derived a subset called EANCOM. GS1's current edition is EANCOM 2002, but many exchanges still run on the previous one, built on version D.96A of the EDIFACT directory, which dates from 1996. These messages are old and plain, and they work. That is why they are still in use.

Four terms are enough for the rest of this article:

GTIN

The number under the barcode, still often called the "EAN code". There is one per packaging level: the bottle has its own, and so does the case of six.

Case pack

The number of consumer units in a case. Some buyers call it the PCB, from "par combien", "by how many".

GLN

A thirteen-digit GS1 number that identifies a place or a function: the buyer's head office, the receiving warehouse, the department that pays invoices.

SSCC

The eighteen-digit number printed on a pallet label.

Three messages do most of the work

Several types of messages can travel between a retailer and a supplier. Three carry most of the load: the order, the despatch advice and the invoice. According to GS1, some 126,000 companies were using EANCOM in 2020, and these three were the messages they exchanged most.

The order (ORDERS)

The order comes from the retailer. It says who is ordering, where to deliver and when, and for each line which item, how many and at what price. At the supplier, it goes straight into the business system. No data entry means no typos, and an order sent at six can be out for picking by seven.

This is what an EANCOM order looks like, slightly simplified. All the numbers are fictitious: they start with 952, a prefix that GS1 reserves for examples.

UNB+UNOC:3+9520000000011:14+9520000000028:14+260406:0600+CDE0001'
UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+CDE0001+9'
DTM+137:202604060600:203'
DTM+2:20260408:102'
NAD+BY+9520000000011::9'
NAD+DP+9520000000035::9'
NAD+SU+9520000000028::9'
LIN+1++9520000000103:EN'
PIA+1+JO1L:SA'
QTY+21:24:PCE'
QTY+59:6'
PRI+AAA:1.15:::1:PCE'
LIN+2++9520000000110:EN'
PIA+1+BIS200:SA'
QTY+21:48:PCE'
QTY+59:12'
PRI+AAA:0.82:::1:PCE'
UNS+S'
UNT+19+1'
UNZ+1+CDE0001'

The file looks unreadable, but it is very regular. Look at the line QTY+59:6: the case pack travels with the order. GS1 says it is there to confirm a value agreed beforehand, not to change it. If the retailer and the supplier do not have the same number, the problem is already in the file, before the truck even leaves.

The despatch advice (DESADV)

When the truck leaves, the supplier sends a despatch advice. It repeats the order number and describes the load like a set of nesting dolls: the shipment contains pallets, each pallet carries an SSCC, each pallet contains cases, each case contains bottles. It can also give batch numbers and expiry dates.

On arrival, the warehouse scans the pallet label. Its system already knows what the pallet contains: quantities are filled in, and the receiving team only has to confirm or correct them. Counting against a paper delivery note goes away.

UNH+1+DESADV:D:96A:UN:EAN005'
BGM+351+EXP0001+9'
DTM+137:202604071600:203'
DTM+2:20260408:102'
RFF+ON:CDE0001'
NAD+SU+9520000000028::9'
NAD+BY+9520000000011::9'
NAD+DP+9520000000035::9'
CPS+1'
CPS+2+1'
PAC+1++201'
PCI+33E'
GIN+BJ+095200000000000011'
LIN+1++9520000000103:EN'
QTY+12:24:PCE'
LIN+2++9520000000110:EN'
QTY+12:48:PCE'
UNT+18+1'

The invoice (INVOIC)

The EDI invoice repeats the order number and the despatch advice number. That is what lets the retailer's system do on its own what an accountant used to do by hand: compare what was ordered, what was received and what is invoiced. This is called matching. When all three agree, the invoice goes to payment without anyone touching it. When they differ beyond a tolerance set in advance, the invoice is blocked and someone has to look at it.

This is where the money is. An invoice that matches by itself costs almost nothing to process. A blocked invoice costs a call, an email, sometimes a credit note, and a late payment. Public administrations in five member states that measured the move to electronic invoicing saw their processing cost fall by more than half.

UNH+1+INVOIC:D:96A:UN:EAN008'
BGM+380+FAC0001+9'
DTM+137:20260408:102'
RFF+ON:CDE0001'
RFF+AAK:EXP0001'
NAD+SE+9520000000028::9'
NAD+BY+9520000000011::9'
NAD+DP+9520000000035::9'
NAD+IV+9520000000011::9'
CUX+2:EUR:4'
LIN+1++9520000000103:EN'
IMD+F++:::ORANGE JUICE 1L'
QTY+47:24:PCE'
MOA+203:27.60'
PRI+AAA:1.15:::1:PCE'
TAX+7+VAT+++:::10'
LIN+2++9520000000110:EN'
IMD+F++:::BISCUITS 200G'
QTY+47:48:PCE'
MOA+203:39.36'
PRI+AAA:0.82:::1:PCE'
TAX+7+VAT+++:::10'
UNS+S'
MOA+125:66.96'
MOA+124:6.70'
MOA+128:73.66'
UNT+27+1'

What about the 2026 e-invoicing reform?

The EDI formats used in distribution are older than the e-invoicing reforms. Those reforms rely on a European standard, EN 16931, which does not describe a file but a list of information: what an invoice must be able to carry, and what each item means. Two XML syntaxes, two ways of writing the same content into a file, give it a concrete form. UBL is published by the standards body OASIS. CII comes from UN/CEFACT, the same family as EDIFACT.

Factur-X is a hybrid format: a PDF that reads like an ordinary invoice, with a CII XML file inside it that software reads. It comes in several levels of detail called profiles, from the leanest (MINIMUM) to the richest (EXTENDED). MINIMUM and BASIC WL have no invoice lines and do not meet the standard; BASIC is the first profile that carries lines and meets it, EN 16931 covers the whole of it, and EXTENDED adds information that goes beyond it.

Here is the same invoice as above, in UBL. The information is the same, arranged differently: the GTIN has become StandardItemIdentification, and the warehouse GLN sits under Delivery.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" …>
  <cbc:CustomizationID>urn:cen.eu:en16931:2017</cbc:CustomizationID>
  <cbc:ID>FAC0001</cbc:ID>
  <cbc:IssueDate>2026-04-08</cbc:IssueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cac:OrderReference><cbc:ID>CDE0001</cbc:ID></cac:OrderReference>
  <cac:DespatchDocumentReference><cbc:ID>EXP0001</cbc:ID></cac:DespatchDocumentReference>
  <!-- seller and buyer: name, address, legal identifiers -->
  <cac:Delivery>
    <cac:DeliveryLocation><cbc:ID schemeID="0088">9520000000035</cbc:ID></cac:DeliveryLocation>
  </cac:Delivery>
  <!-- VAT and totals: 66.96 before tax, 6.70 VAT, 73.66 payable -->
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62">24</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">27.60</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Orange juice 1 L</cbc:Name>
      <cac:StandardItemIdentification>
        <cbc:ID schemeID="0160">9520000000103</cbc:ID>
      </cac:StandardItemIdentification>
      <!-- line VAT category and rate -->
    </cac:Item>
    <cac:Price><cbc:PriceAmount currencyID="EUR">1.15</cbc:PriceAmount></cac:Price>
  </cac:InvoiceLine>
  <!-- second line: the biscuits -->
</Invoice>

The movement is European. Since April 2025, the ViDA package lets each member state require e-invoicing on its territory, and e-invoicing becomes the rule for trade between member states in 2030. What the 2026 reform changes for a retailer and its suppliers depends on how they are organised. An EANCOM invoice can keep flowing between partners, and many invoicing platforms can convert it, but the reference formats of the reform are UBL, CII and Factur-X. One thing does not change: an invoicing platform checks that the invoice is complete and compliant, not that the supplier invoiced the right item at the right price. That check stays between the two companies, and it depends on master data.

The real work: master data

You might think an EDI project is an IT project: pick a provider, open a connection, test some files. That part exists, but it is the shortest, and there are good tools for it. In most projects, the time goes elsewhere: into checking item by item that both companies are talking about the same thing.

Master data is the set of records each company keeps in its system: items, customers, suppliers, delivery points, prices. An EDI message creates no data, it carries what those records contain. A wrong record produces a wrong order that is fully compliant with the standard.

This is not a fringe problem. An industry study from 2009, carried out with GS1 and a business school, found product data inconsistent between retailers and suppliers in more than 80% of the cases examined.

Here is what has to be identical on both sides before the first message.

The GTIN of each packaging level

The bottle and the case each have their own GTIN. If the retailer orders with the bottle's GTIN while the supplier expects the case's, the item is "unknown". Systems often keep several GTINs per item, with validity dates: give a new barcode the wrong start date, and the old one keeps going out. Another common trap is an internal code entered where a GTIN should be. It sometimes has the right number of digits but not the right check digit, and no partner can find it. The last digit of a GTIN is computed from the others; GS1 offers an online calculator, and an automatic check in the data entry file saves a lot of trouble.

Case pack and units

This is one of the most common sources of mismatches. The rules vary from one supplier to the next. A supplier may, for example, ship an adjusted quantity when the order's case pack is larger than its own, and not ship the line at all when it is smaller.

Products sold by weight make it worse. A retailer may have set its case pack to the weight of the case, 14 kilos, while the supplier counts pieces, two per case. An order for 42 kilos then becomes, depending on who reads it, three cases, six pieces, or an order nobody can read, which an operator fixes line by line. Even the standard muddies the waters: in the order, the case pack is written QTY+59; in the invoice, QTY+52.

The two companies have to decide together, per item and per packaging level, what the ordering unit, the shipping unit and the invoicing unit are, and write it into the record. When a supplier changes the contents of a case, GS1's rules require a new GTIN for that case, which is the signal to update the record on both sides.

Item references

Each line usually carries two identifiers, the GTIN and the supplier's reference, and the retailer has its own code as well. These three numbers form a cross-reference table that keeps moving: an item changes size, a supplier renumbers its catalogue, a reference stays at zero because nobody filled it in. Before connecting anything, look for empty or zero references and fix them in bulk.

Places and departments (GLN)

An order often carries three different GLNs: the buyer, the delivery point, the invoicee. If just one of them is unknown to the partner, the order or the invoice is rejected when it is loaded. Exchanging the list of GLNs is the first step of any connection, before anyone talks about items.

Prices

A price mismatch between order and invoice blocks matching and sends the invoice back to purchasing. The cause is rarely a calculation error. Most often, a price list was updated on one side and not the other, or a promotion lives in a separate tool and never reaches the record. If prices have two sources, they will end up drifting apart.

Calculation rules

Rounding or truncating, computing VAT per line or on the total, giving a credit note a positive or negative sign, tolerating a few cents before blocking an invoice: these choices look minor. An invoice profile published by GS1 gives the example of a price of 0.595, which becomes 0.60 when rounded and 0.59 when truncated. Over thousands of lines, those cents make invoices that never match. These rules belong in the interchange agreement, the document both companies sign to set the rules of their exchanges. Without it, each one is right in its own system.

How to go about it

None of this needs sophisticated tools. What works, in this order:

1. Exchange the GLNs of both companies and of every location involved.
2. Build the item table: GTIN of each level, supplier reference, retailer code, case pack, ordering and invoicing units, prices and validity dates. A spreadsheet that checks GTIN check digits is enough to start with; many EDI platforms provide a data entry file that does this.
3. Have the table approved by both companies, and by each department involved.
4. Write the interchange agreement: which messages, which fields, which rounding and tolerance rules.
5. Test with real items, including the awkward cases: variable weight, free goods, promotions, batches, replaced items.
6. Start with a single site, keep the old process running in parallel for a few weeks, then roll out.

For companies that exchange a lot of product records, GS1 even runs a network dedicated to keeping them in sync, the GDSN.

A successful project goes unnoticed

When EDI works, nothing remarkable happens. Deliveries are checked in within minutes and invoices get paid on their own. That calm does not come from the file, which is the easy part. It comes from the weeks spent aligning, line by line, what two companies call a case of orange juice.