From ERP to Digital Product Passport: How to Connect Your Data

The product passport starts in existing systems

Article numbers in the ERP, material information in the PLM, descriptions in the PIM and evidence in document folders: a Digital Product Passport brings together information that previously served different purposes. An additional export is often enough for an initial demonstration. Reliable operation requires a repeatable data flow.

The good news is that businesses do not need to replace their entire system landscape. What matters is which source is authoritative for each data field and how changes reach the passport through a controlled process. This article describes a practical integration approach. The details depend on the product group, business role and applicable requirements.

1. Assign an authoritative source to every field

One system may be authoritative for article master data, another for technical properties. Do not simply assign “the ERP” as the source for the entire passport. Map sources at field level or for groups of fields that belong together.

For a material property, for example, the engineering system might be the source, product development the responsible department, and an approved revision the prerequisite for transfer. A product description might instead come from the PIM. The actual allocation depends on the business.

Document at least:

• the target passport field and its business definition,
• the authoritative source system and specific source field,
• the product level: model, batch or individual item,
• the unit, language and permitted format,
• the responsible owner and approval rule.

If two sources conflict, a business decision is needed. “The last imported value wins” is not a reliable rule for resolving that conflict.

2. Clarify product identities before building the interface

An article number is not automatically the identifier of an individual product. Variants, batches and serial numbers may need their own mappings. Define how internal keys connect to the identity used by the product passport.

Consider a fictional example: the ERP uses article number A-100, the PIM uses variant A-100-BLUE, and production uses a serial number. Without an unambiguous mapping, a passport could receive information for the wrong variant. A documented mapping table helps prevent this.

Within the ESPR framework, Article 10 provides for a connection between the passport and a persistent unique product identifier through a data carrier. The level represented by the passport is determined for the product group concerned. This does not create a general requirement to replace every internal article number. Source: Regulation (EU) 2024/1781, Articles 9 and 10.

3. Translate data rather than merely copying it

Matching column names do not guarantee matching meanings. “Weight”, for example, may mean net or gross weight. A value expressed in grams must not be transferred into a kilogram field without conversion.

An interface therefore needs business transformation rules. These include unit conversions, date formats, language codes, controlled value lists and handling of missing information. A missing measurement should not automatically become zero: zero is a value with a meaning of its own.

The ESPR requires structured and interoperable data and open standards, among other things. The specific data structure must fit the applicable rules. An export format that is convenient internally does not by itself demonstrate compliance. Source: Regulation (EU) 2024/1781, Articles 10 and 11.

4. Choose a transfer method that fits the process

A controlled file upload can be useful for a limited pilot. Regular batch transfers suit predictable changes. An API connection can help when many products or frequent updates need to be processed.

Base the decision on data volume, frequency of changes, consequences of errors and existing operating processes. Automation is useful only if it makes errors visible.

For each transfer method, define:

• when a record is allowed to be transferred,
• which checks take place before acceptance,
• how rejected records are reported,
• who is responsible for corrections,
• and how a failed transfer is run again.

Repeating a transfer must neither create duplicate passports nor overwrite a more recent version without anyone noticing.

5. Separate approval from publication

Not every source-system change should immediately appear in a visible product passport. Drafts, provisional measurements and unconfirmed supplier statements may first need a technical review.

A practical workflow is to import, validate, approve and then make the information available. Record the source, version and transfer time along the way. This makes it possible to explain later why a particular value appears in the passport.

Our article on DPP data quality explains the associated checks.

6. Test realistic failure scenarios

Testing a perfectly maintained sample product shows only the easiest case. Add products with missing evidence, different units, multiple variants or a subsequent correction.

Also check what happens when the connection is interrupted. Does the last approved version remain available? Is the failure reported? Can the responsible team identify the affected products?

Only when these cases work does a data transfer become an operational process.

The next practical step

Choose a manageable product family and first map the fields between source and passport. Then test a complete change cycle, from a corrected source value to its controlled availability.

This approach creates a foundation for additional products and future requirements. Our overview of affected companies, products and timelines helps put the product groups into context.

Would you like to include your existing systems in your DPP preparations? Talk to SimpleDPP about your starting point.