Can I link the digital product passport to my ERP or inventory system?

What you concretely have to do

What is expected of you

A link between your ERP or inventory system and the digital product passport is often technically possible and can save considerable manual work. The ESPR does not prescribe how you obtain your data or how you manage it internally; the regulation sets requirements for the passport itself, for what must be contained in it and how it must be accessible. This means that a link with an in-house system is not an end in itself, but a means to meet those requirements.

The passport must meet the technical requirements, regardless of the data source.

Article 10 of the ESPR (Regulation (EU) 2024/1781) describes what data a digital product passport must contain and what conditions it must meet, such as accuracy and completeness. For a company with 10 to 100 employees, this means that the source of the data — whether it is entered manually or obtained automatically from an ERP system — does not reduce what is expected of the content. A link therefore changes nothing about the obligation; it only changes how you practically fulfil that obligation.

The passport must align with the technical design required by Article 11.

Article 11 of the ESPR (Regulation (EU) 2024/1781) addresses the technical design and functioning of the digital product passport, including the way data is stored, exchanged and made accessible via the data carrier. For a link with an in-house system, this means that the output of that link — the data that ultimately ends up in the passport — must fit within the technical framework applicable to the passport, such as the data model used and the way it is made accessible via the QR code on the furniture. An export file from an ERP package is therefore rarely a passport directly; it is usually a source that must first be translated into the correct format.

Every link delivers data that must be linked to a unique identification code.

An ERP or inventory system usually works with internal article numbers or SKUs. These do not automatically match the identification code required by the product passport. When setting up a link, it is therefore important to determine how each product receives a unique identification code and how that code relates to the existing article coding in your own system. Without that translation step, there is a risk that internal numbers accidentally end up in the passport, or that a single product passport cannot be properly traced back to the correct inventory line.

Where things go wrong in practice

Automatic synchronisation without a control point. A link that transfers data directly and without an intermediate step from the ERP system to the passport may seem efficient, but it also means that an error in the source system — an incorrectly entered material percentage, an expired certificate — automatically carries through into a published passport.

Confusion between internal SKU and public identification code. Companies sometimes use the same internal article number as an external identification code, without checking whether that number is already in use elsewhere or meets the requirements. This is particularly relevant for companies working with GS1 Digital Link and need to align the link accordingly.

No link between inventory movement and passport status. If a product is taken out of production or replaced by a new variant, this is often recorded in the ERP system, but does not automatically lead to an update of the passport. The question of whether and how data can be adjusted after publication is then only raised late, usually after a customer or regulatory authority points out a discrepancy.

Insufficient attention to composite products. An ERP system often records components and variants separately, while the question of whether the furniture as a whole or each component separately requires a passport must be answered separately. A link based on the structure in the inventory system then risks taking the wrong unit as its starting point.

Connection stops when switching systems or suppliers. When a company switches ERP packages, changes hosting providers, or stops working with a particular IT supplier, it is not always considered that the connection to the product passport must then be set up again. This also raises the question of what happens to the product passport if a company closes down or changes its legal form.

What you can put in order now

• An overview of which fields from the ERP or inventory system are automatically imported into the product passport, and which fields are always manually verified before publication.
• A documented translation table between internal article numbers and the identification codes used externally, including an agreement on who keeps this table up to date.
• A procedure for the moment when a change in the source system — new material, new supplier, modified composition — gives reason to review or update the product passport.
• Agreements with the IT supplier or hosting provider about what happens during a system switch, including who is responsible for transferring the connection.
• An internal control point (for example quarterly) in which spot checks are carried out to verify whether the data in the published product passport still matches the current state in the ERP system.
• Documentation on the language or languages in which data from the ERP system are provided, in relation to the question in which language the product passport must be offered.

We provide templates for a number of these agreements, so that documentation does not have to start from scratch for each product.