SKU-to-EAN and GTIN mapping: a practical guide for FMCG teams

A retailer file reports weekly sales by its own product code. Your ERP joins by internal SKU. The GS1 registry identifies the unit by EAN. When these codes do not agree, every join fails and every difference looks like an error. This guide explains what each identifier records, shows a mapping model you can build, and covers how to keep it reliable across packs and markets.

You will see the fields that belong in a mapping, how pack and case codes relate, how effective dates protect history and which checks run before you trust the result.

What each identifier actually records

SKU, EAN, GTIN and retailer code are different keys with different lifetimes. Treating them as interchangeable is the most common cause of failed joins.

A SKU is your internal catalogue key. You create it, you retire it, and you can use it to describe a specific pack such as a 500 ml bottle or a four-pack. An EAN identifies the consumer unit in the trade; it is assigned by the brand through GS1 and should not be reissued while the product exists. A retailer code is the key the retailer uses to order, receive and report the product in its own files.

Identifier	What it identifies	Scope	Lifetime
SKU	Your catalogue item, including the pack variant	Internal to you	Until you retire it
EAN-13 / GTIN	The consumer unit at the point of sale	Global, assigned by the brand	For the product's existence
GTIN-14 / ITF-14	The case or carton used in logistics	Global, assigned by the brand	Matches the pack it describes
Retailer code	The product as the retailer orders and reports it	Within one retailer	Retailer's product lifecycle

The lifetimes differ. A SKU changes when you change systems, an EAN changes when the barcode changes and a retailer code changes when the retailer's master data changes. That is why a single code column is not enough: you need a mapping that records each identifier against a canonical product.

The mapping model: one canonical row, not a web of joins

Build one canonical row per product and market instead of rebuilding joins from file to file. The row holds the internal SKU as the anchor and lists every external identifier that points to it: the consumer EAN, the case GTIN when it exists, and each retailer or distributor code.

Canonical productSKU MX-2041Sparkling water · 500 ml

Consumer EAN8412345678901Unit scanned at the till

Case GTIN08412345678909Carton used in logistics

Retailer ES-042883221Key used in ordering files

Distributor MX4491Key used in distributor files

Every process then joins through the canonical row. A POS file joins by retailer code, a distributor file joins by its own code, and your ERP joins by SKU. They all resolve to the same product because each code points to the same canonical identity.

The alternative is a web of pairwise tables, one for EAN-to-SKU, another for SKU-to-retailer and another for EAN-to-retailer. They drift apart, contradict each other and produce different results depending on which table you happened to use.

Pack hierarchy: one product, several codes

One product usually has several trade codes. The consumer unit, the tray and the case are different pack levels, and each can carry its own EAN or GTIN. A sell-out file reports units, an invoice reports cases; the mapping must know how they relate.

EachEAN 84123456789011 unit · what the consumer buys

TrayEAN 841234567890512 units · how the store shelves it

CaseGTIN 084123456789096 trays · how logistics ships it

The mapping should record the pack relationship and a conversion factor, not assume one. When a POS file reports 120 units and an invoice shows 20 cases, the reconciliation only works if you know that a case holds 72 units.

Effective dates: when a mapping is true

A mapping is a statement about a period. A relaunch, a pack change or a retailer code migration ends one mapping and starts another. Without effective dates, history is overwritten and last month's result cannot be reproduced.

2019-03-01 → 2024-06-30EAN 8412345678890

Original consumer barcode, retired at the pack redesign.

Closed

2024-07-01 → openEAN 8412345678901

Current barcode for the redesigned pack.

Active

Store each version with a valid-from date, a status and, ideally, a reason and a change reference. Then a report can join a sale to the EAN that was correct on the sale date, not the one that is correct today.

Many-to-one cases: when one code points to several products

Not every mapping is one-to-one. The same physical product can have a different EAN in each market, which is legitimate. A single retailer code can also cover several of your SKUs, which forces a decision about granularity.

Resolve many-to-one cases explicitly. Leave them ambiguous and each downstream team picks a different side of the relationship, which recreates the exact mismatches you built the mapping to remove.

Validation: check the mapping before you trust it

A mapping that is not validated will fail at the moment you depend on it. Run these checks before each cycle and surface every exception as a controlled queue rather than a silent default.

1. Check the digits. Validate the EAN or GTIN check digit and the correct number of digits for the format.
2. Check uniqueness. No active SKU maps to two EANs in the same market, and no EAN maps to two canonical rows.
3. Check coverage. Every active SKU has a mapping, and every code seen in partner files resolves to one.
4. Check the round trip. Code to SKU and back to code returns the same code, and SKU to EAN and back returns the same SKU.
5. Check effective dates. No overlapping active versions and no gaps on dates that appear in the files.
6. Check the queue. Unmapped codes and failed validations go to a named queue with an owner and a target close date.

Validation turns a mapping from a hopeful assumption into an input you can defend. It is the difference between a reconciliation that passes because the join matched and one that is correct because the identity was proven.

Ownership: who keeps the mapping correct

A mapping needs a single owner, not a committee. The owner approves changes, publishes versions and answers when a downstream team disagrees with a row. Approval keeps the mapping from drifting when a commercial or logistics team changes a code informally.

Without ownership, a mapping decays silently. Codes get added by one team, corrected by another and retired by nobody, until the next reconciliation surfaces the contradiction.

Worked example: a full mapping record

Here is the canonical row for the sparkling water product used in the figures, as it would sit in a mapping table.

Mapping dossierOwner · Master data team

Canonical productMX-2041Sparkling water · 500 ml

MarketESEffective from 2024-07-01

SKU MX-2041 → EAN 8412345678901

Consumer EAN8412345678901Active

Case GTIN08412345678909Active

Retailer ES-042883221Active

Conversion72 units per caseActive

Previous EAN8412345678890Closed · 2024-06-30

Every downstream file joins through this row. A POS file reports 883221, an invoice shows GTIN 08412345678909, and the ERP knows MX-2041. One row answers all three, and the check digit, uniqueness and round-trip checks passed before the row was published.

Copyable mapping record

This compact template exposes the fields behind the worked record. Keep source codes beside the canonical identity, and make the status and validation fields part of the row rather than comments in a separate workbook.

Practical takeaway

Build one canonical mapping row per product and market, anchor it on the internal SKU, record pack conversions and effective dates, validate before each cycle and give it a single owner. That turns failed joins and ambiguous product identities into a controlled, repeatable input.

If your team reconciles retailer and distributor data every month, Marksyte's data mapping and integration service can build and maintain the mapping. Related work may include standardizing partner files and data-quality rules or reconciling the numbers once identifiers agree.

Frequently asked questions