An international company may receive the same product as an ERP SKU in one file, a retailer item code in another, an EAN or GTIN on a third feed and a local-language description somewhere else. When those records do not join, the problem is usually described as a “SKU mismatch”. That label is too broad to be useful. The failed join may be an unmapped code, a false match, a pack conversion error or a historical mapping that was overwritten.
SKU mapping is reliable only when product identity is separated from the code used by each source. A retailer code can identify an item in one market and still say nothing about its equivalent in another market, another pack level or another period.
What a failed SKU mapping actually means
A mapping failure occurs when a source product record cannot be connected to the canonical product record with enough evidence for the intended analysis. That definition includes more than a blank lookup result.
- Unmapped code. The source value has no approved relationship to a canonical SKU.
- False match. A record was connected to a plausible product, but the evidence does not support that product.
- Duplicate match. One source code points to several canonical SKUs without a valid market, pack or date condition.
- Pack mismatch. A consumer unit was joined to a case, multipack or display without a conversion rule.
- Historical drift. A current relationship replaced an older relationship, so prior periods can no longer be reproduced.
- Coverage gap. The product exists in the master but is not covered for the retailer, country, feed or period being processed.
This distinction matters because each failure needs a different correction. Adding a new alias may solve an unmapped code. It cannot solve a case-to-unit mismatch or recover a mapping that was overwritten last year.
Why international SKU mappings fail
Local codes are mistaken for global identity
Retailers, distributors and internal systems commonly assign their own item numbers. A code such as 883221 is meaningful inside its source context, but the digits do not establish that it represents the same product as ERP code MX-2041. The source system, market and account are part of the meaning.
Pack level and unit of measure are mixed
A product can appear as one bottle, a case of twelve, a promotional bundle or a pallet. If one feed reports cases and another reports individual units, the join may look correct while sales are twelve times too low or too high. A product description rarely makes the unit relationship explicit enough for a safe match.
Market-specific identifiers and assortments are ignored
The same brand may use different GTINs, labels, pack sizes or regulatory versions across countries. A product sold in Spain may have a different identifier and local assortment status in France. Similar names support investigation; they do not prove that the records are interchangeable.
Code lifecycle is not versioned
Retailer codes can be created, retired, reused or replaced. EAN or GTIN assignments can also change when a product is materially altered or its packaging changes. A single current mapping applied to every historical file can move old sales into the wrong product or make a discontinued item appear active.
Descriptions and languages create false confidence
Text matching is useful for finding candidates, especially when descriptions arrive in German, French, Spanish or a local retailer vocabulary. It is weak evidence when product names omit pack size, use abbreviations or describe a range rather than a specific item. A similar description with a conflicting barcode should be an exception, not an automatic match.
One-to-many relationships are flattened
One retailer code may represent a range, bundle or variable-weight item. One canonical product may also have several source codes by country, channel or pack. A flat two-column table of “source SKU” and “master SKU” loses the conditions that make a relationship valid.
Manual overrides become invisible mapping logic
Teams often fix a file by adding a spreadsheet override. If that decision is not written back to a controlled mapping table with an owner, reason and effective date, the same exception returns in the next feed. The result looks like unstable automation even though the underlying issue is missing change control.
Diagnosing the symptom
The first useful question is not “which SKU should this be?” It is “what changed in the records, the source or the definition?” This simple shift prevents a description match from hiding a structural problem.
| Observed symptom | Likely explanation | First check |
|---|---|---|
| Unmapped codes rise after a market launch | New local item master or retailer assortment is not onboarded | Country, retailer and first-seen date |
| One source code maps to several SKUs | Bundle, range, variable-weight item or missing condition | Pack level and source-code reuse |
| The same SKU changes historical totals | Current mapping overwrote a previous relationship | Effective dates and version history |
| Units are 12x or 24x apart | Case, multipack and consumer unit were mixed | Unit of measure and conversion factor |
| Description matches but barcode conflicts | Semantic similarity created a false candidate | GTIN or EAN status in the same market |
| Sales disappear after the join | Unmapped rows were dropped by an inner join | Pre-join and post-join row counts |
Keep the source rows that fail the join. A report that only shows matched products can make coverage look complete because it has already removed the evidence of failure.
How to model a cross-border SKU map
A practical international product mapping should retain the context needed to reproduce a decision. GS1 describes GTINs as identifiers for trade items, while its broader identification system also distinguishes other entities and locations. That is consistent with a basic operational rule: do not make one identifier carry information that belongs in another field.
| Field | Example | Why it is needed |
|---|---|---|
| Market and language | ES / Spanish | Codes, labels and assortments can be country-specific |
| Source and account | Retailer feed / ES-042 | Identifies who assigned the source code |
| Source code | 883221 | Preserves the value present in the file |
| Canonical SKU | MX-2041 | Provides the internal analytical identity |
| GTIN or EAN | 08412345678901 | Stores the available trade-item identifier separately |
| Pack level and factor | Case / 12 | Prevents unit totals from being silently distorted |
| Valid from and to | 2025-01-01 to 2025-12-31 | Allows historical mappings to be reproduced |
| Status and confidence | Active / reviewed | Separates approved matches from candidates and exceptions |
| Owner and change reference | Master data / CHG-104 | Makes later corrections traceable |
How to map SKUs across retailers is therefore a data-model question before it is a matching-algorithm question. Automated matching can propose candidates from codes, identifiers, descriptions and pack attributes. A controlled record must still show why the relationship applies to that market, source and period.
When not to force a match
An unmatched SKU is sometimes the most accurate result available. Keep it in an exception queue when:
- the pack size or unit of measure conflicts and no approved conversion exists
- the market or regulatory version is different and the product relationship has not been confirmed
- one source code is reused for several products or dates
- a bundle, range, display or variable-weight item cannot be represented by one canonical SKU
- the description is similar but the EAN or GTIN points to another trade item
- the product is discontinued, replaced or missing an effective date
- the only evidence is a manual assumption that nobody owns or can reproduce
Forcing these rows into the master creates a clean-looking output with an unknown error rate. Leaving them visible preserves the information needed to improve the map and keeps downstream sales and inventory figures explainable.
Controls before publishing mapped data
- Uniqueness. Check that a source code has only one valid target for the same source, market, pack and period.
- Coverage. Compare source rows before and after mapping, including the value and volume held in exceptions.
- Pack conversion. Reconcile unit, case and multipack quantities with explicit factors.
- Identifier consistency. Investigate conflicting EAN or GTIN values instead of allowing text similarity to override them.
- Date integrity. Check that effective periods do not overlap when they should be mutually exclusive.
- Historical reproducibility. Re-run a prior period with the mapping version that was valid at that time.
- Exception ownership. Give every unresolved code a status, owner, next action and review date.
These controls also explain why a mapping table should be treated as a maintained data asset rather than a one-time spreadsheet. The table changes when retailers change their codes, when packs change and when new countries or channels are added.
Practical takeaway
Most international SKU mapping failures are not caused by a single bad lookup. They come from compressing a conditional relationship into one global code. Keep market, source, pack, identifier, lifecycle and confidence alongside the mapping, and measure both matched coverage and unresolved exceptions.
Marksyte’s data mapping and integration service can support this process by connecting source records, standardizing product fields and preserving the rules used to resolve exceptions. For the identifier-level distinction between SKU, EAN and GTIN, see the guide to SKU, EAN and GTIN mapping. For the adjacent question of how product, location and period definitions affect sell-out analysis, see the guide to mapping sell-out data.
Frequently asked questions
Why does SKU mapping fail?
It fails when a local or transactional code is treated as a complete product identity even though the relationship depends on market, source, pack level, lifecycle or effective date.
How do you map SKUs across countries?
Connect each source code to a canonical product while retaining country, retailer, pack level, GTIN or EAN, conversion factor, validity dates, status and match confidence. Do not assume that a description or code has the same meaning in every market.
Why does a retailer SKU not match an ERP SKU?
Retailers and companies usually assign different internal codes. The records may also represent different pack levels, local assortments, languages, product versions or periods of validity.
Can one EAN map to several SKUs?
Investigate before accepting that relationship. It may reflect different internal pack records or a data error, but a single trade-item identifier should not be used to hide an unresolved product distinction.
How should discontinued SKUs be handled?
Keep the historical relationship with its valid dates and discontinued status. Do not replace it with the successor product unless the business rule explicitly defines that aggregation.
What should happen to an unmapped SKU?
Keep the source row in an exception queue, quantify its impact, assign an owner and record the evidence required for approval. Do not silently drop it from the sales or inventory dataset.
Sources and methodology
- GS1, GTIN Management Standard and best practices
- GS1, System Architecture
- GS1, Global Location Number
- Google Merchant Center, Product data specification and identifiers
The sources support the distinction between trade-item identifiers, other business entities and source-specific product records. The diagnosis, data fields and control process are Marksyte’s practical interpretation for international retail, distributor and ERP data.