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

What you must do concretely

What is expected of you

The passport must be able to receive data from source systems

Article 10 of the ESPR (Regulation (EU) 2024/1781) sets out requirements for which data must be included in a digital product passport and how that data is accessible. This data does not come from nowhere: it already exists in existing systems such as an ERP package, a PLM system or an inventory management package — material composition, supplier data, batch numbers, care instructions. For a company with 10 to 100 employees, this practically means there must be a connection between the system where this data already exists and the system that compiles and publishes the passport. This can be an automated link, but also a periodic export that is manually uploaded. Both are essentially possible; which form is practical depends on how many products and variants there are and how often data changes.

The technical operation must comply with established standards

Article 11 of the ESPR (Regulation (EU) 2024/1781) describes the technical design and operation of the passport, including the manner in which data exchange takes place. This directly addresses the question of how a link is technically set up: not every export format from any ERP system will fit without modification into what a passport system expects. For a mid-sized company, this means that a translation is needed between its own data structure and the format required for the passport. This is a technical matter, not a legal one — but it does bear on the question what GS1 Digital Link is and whether it is necessary for the product passport, because part of the standardisation expected to take place runs through systems of this kind.

Each product must be traceable to the correct passport data

A link with an ERP or inventory system only works if there is a conclusive way to match a physical product to the correct passport. This requires a consistent key between the systems: the same article number, the same batch code or the same variant identification in the ERP system as in the passport. Without this alignment, there is a risk that a linked system transmits data but to the wrong passport, or that a change in one system does not carry through to the other. This is closely related to the way each product receives a unique identification code; without a clear identification logic, a link between systems is of little value.

Where things go wrong in practice

A first situation that often arises: a company has an ERP system in which articles are recorded per style, but not per colour or size. The passport must be correct at variant level, and it then turns out that the link transmits data that is correct for one size but not for another.

A second situation: data is transferred once when a collection is launched, but a later change in the ERP system — for example a different supplier for a partial batch — is not automatically transferred to the published passport. The passport thus becomes disconnected from reality without anyone noticing, until someone discovers an error and wonders whether a published product passport can still be amended.

A third situation: a link is technically set up by an external IT party, but no one within the company subsequently checks whether the data that ends up in the passport actually matches what is on the label or packaging. A technical link that works is not automatically a link that is correct.

A fourth situation: the inventory system is used to automatically expire passports once a product is sold out, without taking into account the question of how long a passport must remain available. This can lead to a mismatch between what is operationally convenient for inventory management and what is expected with regard to how long a product passport must remain available.

A fifth situation: when a merger, acquisition or cessation of a business unit occurs, the link is disconnected without consideration of who will manage the data afterwards, which again connects to the question what happens to the product passport when a company stops operating.

What you can record

• An overview of which systems provide which passport data: ERP for material and origin, inventory system for availability, PLM for design and composition data.
• A documented agreement on the frequency of synchronisation: real-time link, daily export, or manual update per collection.
• A document describing the identification key used to match a product in the ERP system with the correct passport — including how this works with variants in size or colour.
• A responsible function or person who checks whether data arriving via the link actually match before a passport is published or updated.
• A procedure for what happens when there is a change in the source system: who signals this, and how is the change implemented in the published passport.
• Agreements with an IT supplier or internal IT department on the technical format of the link, including what happens when a system switches or migration occurs.
• An overview of which data are supplied automatically via a link and which are still added manually, so that there is no gap between what the system thinks it is sending and what actually appears in the passport.