How to Map Product IDs Across ERP, PIM, Ecommerce and a DPP

A GTIN, retailer SKU, ERP material number and PIM record ID can all point towards "the same product" while describing different scopes. Mapping fails when an integration treats those identifiers as interchangeable strings instead of typed references with ownership, entity level and cardinality. The goal is not to find one ID and replace the rest. It is to create a crosswalk that can explain what each identifier identifies, who owns it, how records were matched and when that match stops being valid.

Why identifier strings are not synonyms

Enterprise systems use identifiers for different jobs.

A GTIN is allocated within the GS1 identification system. An ERP material ID is typically native to an enterprise system. A PIM record ID identifies an object inside the PIM. An ecommerce SKU may be merchant- or channel-specific. Lot and serial identifiers can push identity to a finer operational level.

The accepted evidence shows these identifiers can coexist in ordinary product architectures. SAP product master APIs expose product entities that can include GTINs alongside system-native product records. GS1 Digital Link can represent GS1 identifiers as resolvable Web identifiers. Neither source says those identifiers are synonyms. (SAP Product Master APIs, GS1 Digital Link URI Syntax 1.7.0)

For the underlying identifier vocabulary and allocation rules, use the canonical identifier page. This article owns the mapping problem after those identifiers exist.

The dangerous shortcut is:

GTIN = SKU = ERP ID = PIM ID

That may appear to work in a small catalogue where records happen to align one-to-one. It fails as soon as the systems represent different product levels, market scopes, packs, lots, items or channel constructs.

Start with namespace and entity level

Every identifier in a crosswalk should answer two questions before any match is accepted:

1. What namespace does this value belong to?
2. What entity level does it identify?

The string 12345 is meaningless without its namespace. It could be an ERP material number, a PIM row ID, a merchant SKU or part of another identifier scheme.

Entity level matters just as much. A model-level record is not automatically interchangeable with a sellable variant, a SKU, a lot or an individual serialised item.

The exact rules for which facts belong at model, variant and SKU level are owned elsewhere in the Knowledge estate. Likewise, the decision about lot, serial or item operational identity belongs to the granularity guide. The mapping layer should carry those distinctions rather than redefine them.

A minimal typed identifier record might look conceptually like this:

That is the beginning of the crosswalk, not the whole thing.

Cardinality: one-to-one is not the default

One of the most common mapping errors is assuming every system has exactly one record for exactly one record in every other system.

Real product systems can produce:

• one-to-one mappings, where one source record corresponds to one target record;
• one-to-many mappings, where one upstream product maps to multiple channel SKUs or regional records;
• many-to-one mappings, where several system records intentionally roll up to one broader product representation;
• time-bounded mappings, where the relationship changes after a reclassification, migration or correction;
• no safe mapping, where evidence is insufficient and the record must remain unresolved.

GS1's EPCIS model reinforces why granularity matters. Event data can refer to identified objects while remaining distinct from product master data. In the GS1 US Culinary Collaborations case, GTIN/product master data and EPCIS traceability events coexist across processors, logistics providers and downstream customers. The join between event identity and product identity is therefore part of the architecture, not a reason to flatten everything into one record. (GS1 EPCIS 2.0, GS1 US Culinary Collaborations case study)

For the deeper event context, use what EPCIS events add to product master data.

The Typed Identity Crosswalk

We use a ten-part Typed Identity Crosswalk as an ActivateDigital synthesis:

namespace + value + entity level + owner + scope + cardinality + match method + confidence + effective time + reconciliation state

This is not a formal industry standard. It is a practical control model for making cross-system joins explicit and reviewable.

The value of the model is not the number of columns. It is the ability to answer a simple operational question later: why did we decide these two records represented the same thing?

Matching, confidence, conflict and review

A production mapping process needs more than "matched" and "not matched".

At minimum, preserve four useful states:

• confirmed: the relationship is supported by an accepted deterministic or authoritative mapping;
• conflict: two credible mappings disagree;
• unknown: there is not enough evidence to establish a mapping;
• review: a person or controlled process must decide before the join is published.

ServiceNow's Identification and Reconciliation Engine provides a useful enterprise analogy. IntegrationHub ETL imports and transforms third-party data, then uses identification and reconciliation processing to avoid duplicate and inconsistent configuration items. This is a CMDB pattern, not a product-ID standard, but it illustrates the value of treating reconciliation as a first-class process. (ServiceNow IntegrationHub ETL)

The critical rule is do not auto-merge ambiguity away.

Retries and replay are another reason not to rely on arrival order. Debezium's outbox pattern and Apache Kafka's idempotence work both show that duplicate-safe processing is a deliberate reliability concern. A mapping engine should therefore distinguish "we saw this assertion again" from "a genuinely new relationship exists". (Debezium Outbox Event Router, Apache Kafka idempotent producer rationale)

How mapping changes across model, variant, SKU, lot and item

The mapping problem changes as identity becomes more granular.

The mapping layer should therefore retain entity level on both sides of the relationship. If two identifiers refer to different levels, the crosswalk may still be valid, but the cardinality and intended use must be explicit.

That is why a model-level record should not automatically absorb lot or serial state. The relationship is a join, not a licence to collapse the levels.

Where mappings live and how they version

There is no requirement that every mapping live inside the DPP database.

A crosswalk may live in a dedicated identity service, MDM capability, integration layer, PIM extension, DPP publication layer or another governed store. Some data can also remain virtualised. Microsoft Dataverse virtual tables, for example, can expose externally stored data without replication, subject to product constraints. (Microsoft Power Platform virtual tables)

What matters is that the mapping is:

• addressable by namespace and entity level;
• versioned or time-bounded when relationships change;
• available to the systems that need to reconcile records;
• auditable enough to explain the match method and state;
• removable or supersedable without destroying history.

A stable global identifier can be a powerful join key without carrying the full product record. GS1 Resolver allows an identified entity to link to multiple resources, and GS1 Digital Link makes GS1 identifiers usable in resolvable Web identifiers. That is routing and linking capability, not a requirement to aggregate all product data into the identifier itself. (GS1-Conformant Resolver 1.2.1, GS1 Digital Link URI Syntax 1.7.0)

Examples across ERP, PIM, ecommerce, EPCIS and DPP

A simplified cross-system example might look like this:

The example is intentionally generic. It demonstrates the mapping structure, not a universal identifier allocation rule.

Reference architectures also show multiple identifiers coexisting in distributed systems. Eclipse Tractus-X EcoPass uses a Digital Twin Registry for discovery, submodel servers for data and connectors for controlled access. That demonstrates coexistence of registry, asset and data-service identities, but it is not evidence of universal Catena-X adoption. (Eclipse Tractus-X EcoPass operation view)

Vendor cases from Akeneo similarly show real ERP-PIM-commerce mapping work. GSM55 connected Akeneo PIM to ERP and Magento, while the DELFINGEN case describes API movement between ERP, PIM and downstream channels across more than 95,000 products. The vendor-reported productivity outcomes in those cases are not independent evidence and should not be treated as general ROI. (Akeneo GSM55, Akeneo DELFINGEN)

Identity mapping is not the same as runtime integration

These two problems are tightly connected, but they are not the same.

Identity mapping asks: which records refer to the same real entity, at what level and with what confidence?

Runtime integration asks: how should changes move between the systems, with what replay, validation, failure and publication controls?

Once the crosswalk is trustworthy, hand the transport question to how to connect a DPP to ERP, PIM and PLM without creating a second product master.

Keeping the two problems separate prevents a common architectural mistake: treating a successful API call as proof that the correct records were joined.

Implementation checklist

Before putting a cross-system product mapping into production, check that you can answer all of these:

• [ ] Is every identifier stored with its namespace rather than as a bare string?
• [ ] Is entity level explicit on both sides of the mapping?
• [ ] Is the namespace owner or allocator clear?
• [ ] Is scope clear: global, enterprise, retailer, marketplace, market or another bounded context?
• [ ] Is cardinality explicit rather than assumed to be one-to-one?
• [ ] Is the match method recorded?
• [ ] Can ambiguous joins remain unknown, conflict or review instead of being auto-merged?
• [ ] Is the mapping time-bounded or versioned when relationships change?
• [ ] Can event identities join to the correct product and operational level without flattening event history into master data?
• [ ] Can a person or machine explain why two records were joined?
• [ ] Is the runtime movement of updates delegated to the enterprise DPP integration architecture rather than hidden inside the crosswalk?

What to do now

Create the crosswalk before you automate synchronisation. Start with namespace and entity level, then add cardinality, match method, confidence, effective time and reconciliation state.

The strongest rule is also the simplest: do not make an ambiguous match irreversible. A good crosswalk can explain why two records were joined and what evidence would invalidate that join.

Sources and evidence boundary

The core evidence for this article comes from GS1 EPCIS, GS1 Resolver and GS1 Digital Link; SAP product master documentation; ServiceNow identification/reconciliation patterns; Microsoft virtualisation; Debezium and Kafka reliability patterns; and Eclipse Tractus-X EcoPass architecture. Together they establish that multiple identifier types, event identities and distributed data sources can coexist without being treated as synonyms.

Akeneo customer cases show ERP-PIM-commerce mapping in real deployments. They are useful implementation examples, but their vendor-reported productivity claims are not independent ROI evidence and are not used here as such.

• GS1 EPCIS Standard 2.0
• GS1-Conformant Resolver Standard 1.2.1
  Standards body
• GS1 Digital Link URI Syntax 1.7.0
  Standards body
• APIs for Product Master, S/4HANA Cloud 2608 docs, SAP
• Power Platform developer introduction: virtual tables, Microsoft
• IntegrationHub ETL, ServiceNow
• Debezium Outbox Event Router
• Apache Kafka idempotent producer rationale, Apache Software Foundation
• Culinary Collaborations LLC traceability case study, GS1 US
• Tractus-X EcoPass Operation View, Eclipse Tractus-X
• Akeneo GSM55 customer story
• Akeneo DELFINGEN customer case