Your product data already exists. So why is creating a DPP still difficult?

The hard part of a Digital Product Passport is almost never the passport. It is the product information behind it — scattered across ERP, PLM, PIM, supplier spreadsheets and PDFs, owned by different people, and changing all the time. This guide walks the eight steps from fragmented source data to a passport that can actually be maintained.

Ask a company where its product data lives and you may get a simple answer: “in our ERP.” Ask where all its product data lives and the answer usually becomes more complicated.

The product name and SKU may be in the ERP. Technical specifications may be in a PLM or PIM system. Material composition may arrive from a supplier in Excel. Certificates may exist as PDFs. Test reports may sit in SharePoint or a document management system. Images may live somewhere else. Production information may still be held by the manufacturer. And some information may only exist in emails, spreadsheets or supplier portals.

Then someone asks: “can we create a Digital Product Passport from this?” Usually, the answer is yes. But the real work is not creating the webpage behind a QR code. It is turning fragmented product information into structured, trustworthy and maintainable product data.

The product data problem

A Digital Product Passport brings information about a product together around a persistent product identity. But companies were not originally designed around DPPs. Their systems were built for different purposes.

An ERP manages transactions, inventory, purchasing and operations. A PLM manages product development. A PIM distributes product information. A supplier portal collects supplier data. A document management system stores evidence. Excel solves almost everything that falls between those systems.

None of this is necessarily wrong. The problem appears when information from those different sources needs to become one coherent product record. A typical landscape might look like this:

The Digital Product Passport has to make sense of that landscape.

The DPP should not become another data silo

One possible response is to create yet another database and manually copy everything into it. That may work for a small pilot. It becomes much harder to maintain at scale.

Imagine that a material composition changes in the PLM. Someone now needs to remember that the same information also exists in the DPP system. A certificate expires. A supplier changes. A product specification is corrected. A new production batch is created.

If every system contains its own independent copy of the truth, inconsistencies become almost inevitable.

The better question is therefore not “where should we enter all our DPP data?” but “where does each piece of product information come from, and how should the DPP use it?”

Start with the source, not the passport

Before designing the DPP page, map the information behind it. For every relevant data point, ask:

• What is the information?
• Where does it currently come from?
• Who owns it?
• At what level does it exist — model, batch or item?
• Is it structured or unstructured?
• Can it be trusted?
• Is supporting evidence available?
• How often can it change?
• How should updates reach the DPP?

That exercise often reveals that the biggest DPP challenges have little to do with QR codes. They are data-governance challenges.

A practical DPP data flow

A robust DPP implementation can be understood as a sequence. Each step solves a different problem.

1. Discover — where does the data live?

The first step is inventory. Which systems, documents and organisations contain relevant product information? Typical sources include ERP; PLM; PIM; MES; supplier portals; Excel; CSV; XML or JSON; PDFs; certificates; technical files; images; APIs; databases; external data providers.

Some information may not be inside the company at all. It may sit with manufacturers, material suppliers, testing laboratories, certification bodies, logistics partners or repair providers.

This is why DPP implementation often becomes a supply-chain data project, not merely an IT project.

2. Extract — make the information usable

Structured data is relatively easy to process. An ERP export may contain clearly defined columns — SKU, product name, supplier, composition. But product information often arrives in less convenient formats: a PDF certificate; a supplier specification sheet; a Word document; an image of a label; an Excel file using another column structure; a document containing several products.

Before that information can become useful DPP data, it needs to be extracted and interpreted. This is one area where automation and AI can reduce manual work significantly. But extraction is only the beginning.

Extraction is not the same as understanding

Suppose a supplier file contains “CO 80 / PES 20”. Another supplier writes “80% Cotton / 20% Polyester”. A third system expects Cotton: 80, Polyester: 20.

The information is semantically equivalent. The formats are not. The DPP infrastructure therefore needs to understand how information from different sources maps to a consistent product-data structure. That is the mapping problem.

3. Map — translate different data structures into one model

Every company has its own product-data vocabulary. Even companies selling similar products may use completely different column names, attribute names, units, codes, abbreviations, category structures and supplier templates.

One system may use MaterialComposition. Another Fibre_Content. Another MAT-COMP. And an Excel file may simply say Fabric.

The purpose of mapping is to connect those source fields to the appropriate data concept: source field Fibre_Content → mapped concept material composition → structured value 80% cotton / 20% polyester.

This mapping layer becomes particularly important when a company works with many suppliers. The objective should not necessarily be to force every supplier to use exactly the same internal system. The objective is to make their information interoperable.

Where AI helps — and where it should stop

AI can be extremely useful in DPP data preparation. It can help recognise fields; classify information; extract data from documents; suggest mappings; interpret supplier terminology; transform formats; identify likely duplicates; flag inconsistencies; and accelerate onboarding of new data sources.

That can turn what would otherwise be weeks of manual mapping into a much faster workflow. But there is an important boundary.

If a supplier document does not state the country of origin, an AI system should not simply infer one and present it as fact. If a certificate is missing, AI should not create evidence. If two sources disagree, the system should not silently choose whichever value seems most plausible. Those situations need to be flagged.

This distinction becomes critical when product data is used for regulatory compliance.

A missing value is better than a fabricated value

Generative AI systems are designed to produce plausible outputs. Compliance systems need something different: traceable facts.

Suppose the required field is recycled content, and the source documents contain no reliable answer. The correct DPP workflow is missing information → flag → request → validate → publish, not missing information → AI estimate → publish.

That principle sounds obvious. In practice, it is one of the most important controls in an AI-assisted DPP system.

4. Validate — can the data be trusted?

Once information has been extracted and mapped, it still needs validation. Validation can happen at several levels.

Format validation. Is the data technically valid? A percentage between 0 and 100; a date in the expected format; an identifier in the correct structure; a required field that is not empty.

Logical validation. Does the information make sense? 60% cotton plus 50% polyester equals 110%. The individual values may be valid numbers. Together, they are not.

Cross-source validation. Do different sources agree? The ERP may say supplier A while the latest supplier file says supplier B. That requires investigation.

Evidence validation. Is there documentation supporting the claim? “Certification: yes” should ideally connect to the relevant certificate rather than exist as an unsupported statement.

Claims and evidence are not the same thing

This distinction becomes increasingly important as product information becomes more detailed. Consider the statement “this product contains 70% recycled material.” That is a claim.

The supporting documentation might include a supplier declaration; a certificate; a test report; a chain-of-custody document.

The DPP architecture should be capable of maintaining the relationship claim → evidence → source → validity and version. That creates a much stronger information structure than simply displaying the claim on a webpage. It also makes future audits, updates and verification easier.

5. Link evidence — preserve provenance

Product information becomes more trustworthy when its provenance is known. For important data points, it should be possible to understand where the information came from; who supplied it; when it was received; which evidence supports it; which version is current; and whether it has been validated.

Not all of this information needs to be public. A consumer may only see “material: 70% recycled polyester”, while an authorised user may need access to the underlying evidence. That is one reason why a DPP is more than a public product page. Different users can require different levels of information and access.

Product data also has a level

Another common mistake is to assume that every piece of information belongs to the same level. It does not. Some data belongs to the model, some to the batch, and some to the individual item.

A robust data architecture needs to preserve those relationships.

Read: model, batch or item-level DPP? →

The system of record still matters

A DPP platform should not automatically become the master database for every piece of product information. If the PLM is the authoritative source for product composition, it may make sense for the PLM to remain the system of record. If the ERP owns the SKU, the ERP should continue to own it. If a certification platform owns a certificate, that source may remain authoritative.

The DPP infrastructure can then connect those sources around the product identity: ERP, PLM, PIM, supplier data, certificates and external sources feed a product data layer, which feeds a persistent product identity, which supports the Digital Product Passport and the compliance, transparency, repair, returns, resale and circular services built on it.

The objective is not to replace every existing system. It is to make the relevant information work together.

Don't replace your ERP just to create a DPP

For many companies, the prospect of a Digital Product Passport raises an uncomfortable question: “do we need a new ERP or PLM before we can do this?” Usually, that should not be the starting assumption.

A company may already have perfectly functional operational systems. Replacing them can mean long implementation projects; migrations; training; process redesign; integration work; cost; and operational risk.

A DPP project should first determine whether the required information can be connected from the existing environment. That could involve APIs; connectors; file imports; structured exports; supplier uploads; document extraction; scheduled synchronisation; or manual workflows where appropriate.

Sometimes a source system genuinely needs improvement. But DPP implementation should not automatically become an ERP replacement project.

What about Excel?

Excel deserves special attention because it is often treated as a problem. In reality, Excel is simply part of how many companies operate. Suppliers use it. Product teams use it. SMEs use it. Even companies with sophisticated enterprise software frequently exchange information through spreadsheets.

For DPP implementation, the important question is not “how do we eliminate Excel?” It is “how do we reliably turn the information in Excel into structured product data?”

If a supplier can provide a consistent spreadsheet containing reliable information, that can be a perfectly useful data source. The challenge is mapping, validation and governance.

Supplier onboarding may be the real bottleneck

A brand may have excellent internal systems and still lack essential DPP information. Why? Because much of the relevant information originates upstream.

The brand knows the product and commercial information. The manufacturer knows production details. The material supplier knows material composition and provenance. The certification body or laboratory provides evidence.

A DPP can therefore expose weaknesses in supplier-data collection that already existed but were previously less visible. Companies should ask:

• What data do we already request from suppliers?
• In what format?
• How consistent is it?
• Who validates it?
• How often is it updated?
• Can suppliers provide evidence?
• Can the information be linked to the correct model or batch?

In many organisations, improving these workflows will be one of the biggest DPP preparation tasks.

Publishing is not the end

Suppose the company successfully creates its first DPP. The project is not finished. Products change. Suppliers change. Certificates expire. New batches are manufactured. Regulatory requirements evolve. Products are repaired. Items are returned. Some are resold.

A DPP therefore needs a lifecycle. The real process is not data → DPP → done. It is data → DPP → update → event → update → maintain.

This is why a persistent product identity matters. The identity remains the reference point while information around the product can evolve.

Explore digital product identity →

A beautiful DPP can still be a bad DPP

It is easy to focus on what the consumer sees. The webpage. The product image. The QR code. The sustainability story. The design. Those things matter. But they do not determine whether the underlying product information is reliable.

A beautifully designed DPP with outdated information, incorrect mappings, unsupported claims, missing evidence or inconsistent supplier data is still a poor Digital Product Passport.

What a scalable DPP architecture needs to solve

A scalable implementation should be able to address several distinct problems.

These are infrastructure problems. The QR code is only the visible entry point.

A practical readiness exercise

Before selecting technology, take one real product. Not your easiest product — choose a reasonably representative one. Then try to answer the following questions.

Product identity

• What is the product identifier?
• Is there a model identifier?
• Do batches exist?
• Are individual items serialised?

Product data

• Where does composition or material information live?
• Where are technical specifications stored?
• Which information comes from suppliers?
• Which information changes by batch?

Evidence

• Where are certificates?
• Where are test reports?
• Can claims be linked to evidence?
• Are validity dates known?

Ownership

• Who owns each data point?
• Who can correct it?
• Who validates supplier information?

Technology

• Can the source system export the information?
• Is an API available?
• Is a spreadsheet import more practical?
• How often should information synchronise?

Lifecycle

• Will anything happen to this product after sale?
• Repair?
• Maintenance?
• Return?
• Take-back?
• Resale?

If answering these questions is difficult, the problem is probably not yet the DPP itself. It is the underlying product-data landscape. And that is useful to discover early.

Where AI can change the economics

Historically, integrating fragmented product data could require substantial custom integration work. AI changes part of that equation. It can make it much faster to interpret unfamiliar spreadsheets; supplier templates; PDFs; technical documents; inconsistent naming conventions; and semi-structured information.

Instead of manually configuring every field from every supplier, an AI-assisted mapping layer can propose how incoming information relates to the target data structure. Humans or validation rules can then confirm the result where necessary.

The potential workflow becomes: upload or connect → extract → AI-assisted mapping → validate → human review where required → publish. This can make DPP implementation significantly more accessible, particularly for SMEs and complex supply chains. But the principle remains:

What should companies do now?

You do not need to wait for every delegated act to start preparing your product data. A useful first programme is:

• Choose representative products — avoid trying to map the entire catalogue immediately.
• Identify the relevant data — understand what already exists and what may be needed.
• Map the sources — ERP, PLM, PIM, supplier, Excel, PDF, certificate, external source.
• Identify gaps — what information is missing?
• Assign ownership — who is responsible for each important data point?
• Test extraction and mapping — use real data rather than a perfect demo dataset.
• Validate the result — check source, evidence and consistency.
• Create the product identity — at the appropriate model, batch or item level.
• Publish a real DPP — see what happens outside the spreadsheet.
• Test an update — change something. Can the DPP remain correct?

That last step is frequently overlooked. A DPP that can be created but cannot be maintained is not a scalable solution.

Where Quifactum fits

Quifactum is designed to sit between existing product-data sources and the persistent digital identity of the product. Rather than requiring companies to rebuild their product stack, Quifactum can ingest and structure information from sources such as existing business systems, spreadsheets, supplier files and documents.

The workflow is built around connect → extract → map → validate → structure → create product identity → publish → maintain and activate.

The resulting product identity can support regulatory Digital Product Passports as well as applications beyond compliance: transparency; customer engagement; repair; returns; take-back; resale; circular services.

The objective is not another isolated database. It is an operational layer that makes existing product information usable around the product itself.

Explore product data & integrations →  ·  Explore the Quifactum platform →  ·  Book a demo →

Implementation note. The examples in this article describe common product-data architectures and implementation practices. The exact information, evidence, access and technical requirements for a regulatory Digital Product Passport depend on the applicable legislation and product-specific requirements.

Published by Quifactum. Last updated 21 September 2026. Regulatory content is reviewed against primary EU sources before publication.