14-digit GTIN from ICA: same product, new code – and why an EDI order can fail

Recently one of our customers – an organic food producer supplying ICA – received a notice: ICA will start ordering at case level (DFP) using 14-digit GTINs for articles that are ordered with 13 digits today. In practice, a case code such as 7350012345679 becomes 07350012345679. Master data was updated in Validoo – but would the EDI orders still land correctly in the ERP?

A fair question. For CloudOffice the answer was “yes, done the same afternoon” – but the question itself deserves a closer look. This is exactly the kind of small change that quietly stops order flows in many systems.

What ICA is changing – and why

The GS1 packaging hierarchy has three levels in Swedish grocery retail: the consumer unit (KFP), the case (DFP) – the unit a store orders – and the pallet. Each level can carry its own GTIN. Historically, many suppliers have identified the case with a GTIN-13 of its own, or simply reused the consumer-unit code. Ordering at DFP level with GTIN-14 makes the packaging level explicit in the code itself, and it is how GS1 recommends identifying trade units. For the retailer it means cleaner master data and fewer misunderstandings about how many units were actually ordered.

The anatomy of the code: 13 or 14 digits

A GTIN-14 consists of an indicator digit, the twelve digits of the GTIN-13 without its check digit, and a new check digit. The indicator digit tells you what kind of code it is:

Two things follow. A leading zero does not change the check digit – the zero adds nothing to the mod-10 calculation – so “0” + GTIN-13 is a valid GTIN-14 identifying the same item. But a GTIN-14 with indicator 1–8 is a different identifier: it cannot be “normalised” back to 13 digits by dropping the first digit. That is why GS1 recommends storing every GTIN in a 14-digit field, right-aligned and zero-padded, and treating the 14-digit form as canonical.

Where systems break

In the EDIFACT order the line item looks roughly like this: LIN+1++07350012345679:SRV' (older profiles use the qualifier EN). The ERP or the EDI converter takes the code and looks up the article. Four typical failure modes:

• Exact string matching. The article card says 7350012345679, the order says 07350012345679. Same item, different string – no match. The order line ends up as “unknown article”, or worse, the whole order is rejected with an error in the ORDRSP.

• A single GTIN field per article. Many systems have one lonely “EAN” field on the article card. When ICA wants 14 digits and another chain still sends 13, there is nowhere to put the second code – you are forced to choose who gets it wrong.

• The reply goes back with the wrong code. Even when the order is read correctly, the system may “normalise” the code to its own format and send 13 digits in the order response (ORDRSP), despatch advice (DESADV) and invoice (INVOIC) – while the retailer now expects 14. The flow then stalls one step later, at the retailer, and the error is harder to find.

• Hard-coded mapping in the EDI converter. Sometimes the matching lives outside the ERP, in a converter or a mapping table at the VAN operator, maintained by someone else. Then the change means a support ticket, a lead time and an invoice – for a zero.

Note that none of this is visible until the first 14-digit order arrives. The master data in Validoo can be perfectly correct while the order still fails.

Five questions to ask about your own system

1. Can the same article carry several GTINs at the same time – for example both the 13- and the 14-digit form of the case code?

2. Does the lookup treat 7350012345679 and 07350012345679 as the same code?

3. What happens to an order line whose GTIN is unknown: is the order rejected, parked for review, or silently created with an empty line?

4. Does the system reply – in ORDRSP, DESADV and INVOIC – with exactly the code form that was in the order, or does it normalise everything to its own format?

5. Who maintains the mapping, how long does the change take, and what does it cost?

If the honest answer to question five is “a ticket with the EDI provider and a few days”, the retailer’s deadline sets your schedule – not you.

How it works in CloudOffice

In CloudOffice an article can carry several GTINs at the same time – for example both the 13- and the 14-digit form of the same case code – and incoming EDI orders are matched against all of them. (Different packaging levels, on the other hand, are different articles: a case and a pallet with the same contents each have their own article card and their own GTIN, just as in the GS1 hierarchy.)

The important part happens in the next step: CloudOffice always replies with the code form the retailer itself used in the order. If the order arrived with 14 digits, the retailer gets 14 digits back in the order response, despatch advice and invoice; if it arrived with 13, it gets 13. If you supply several retailers and one of them switches to 14-digit GTINs while the others stay on 13, nobody needs to coordinate anything – each gets its own code back, and you do nothing at all.

For the customer above, the 14-digit codes were added to the ICA articles the same afternoon. Nothing changed in the order flow, the price lists or the documents that follow the order. ICA can start sending the new codes whenever they are ready; orders with the old codes keep working in the meantime.

It is the same principle as in our entire EDI solution: the retailer’s requirements change, the supplier’s everyday work should not.

Unsure how your system handles 14-digit GTINs?

Send us a sample order from your retailer – we will show live how it is read into CloudOffice, from order to invoice.

Book a demo

Company details and references available on request.