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

What you must concretely do

What is expected of you

Data must be machine-readable and transferable

Article 10 of the ESPR (Regulation (EU) 2024/1781) requires that data in the digital product passport be available in a structured, machine-readable format. This is immediately the starting point for linking with an internal system: data that is machine-readable is in principle also suitable for automatically flowing in or out of an ERP or inventory system. For a company with 10 to 100 employees, this means above all that the question "can this be linked" is not primarily a legal question, but a technical one: what format does the passport use, and can the internal software read or write that format. See also the page on in what format must I submit the data for the product passport.

The passport must comply with a uniform technical structure

Article 11 of the ESPR addresses the technical design and operation of the passport, and refers to technical specifications that the Commission will develop further. For the practice of linking, this means that "a proprietary file" cannot simply be supplied or retrieved: a standardised structure underlies it, probably based on existing identification systems. Anyone already working with a system for product coding should check how it aligns with the way unique identification codes will be assigned in the future — see how do I assign a unique identification code to each product. An ERP system that already works with unambiguous, stable product codes is better positioned for linking than a system in which codes vary per order or per customer.

The link runs via a data carrier, not via a direct database connection

Article 11 also describes that the passport is accessible via a data carrier on the product. This is an important point for the expectation a company may have of "linking": it is not a direct database connection between two companies, but a chain in which the data carrier (usually a QR code) points to a stored passport. The link with an ERP or inventory system thus sits at two ends: when supplying product data from the internal system to the party that compiles the passport, and when reading passport data (for example when purchasing steel) into the internal system. More about that carrier can be found on the page how does the QR code for the product passport get onto my steel.

Data must remain current as long as the passport exists

Article 10 also implies that data in the passport must be correct and current as long as the passport exists. For a link with an inventory system, this means that supplying data once is usually not sufficient: if properties of a batch of steel change, or if an error is discovered, there must be a way to communicate that to the place where the passport is hosted. Companies linking their ERP system should also look at how long that currency must be maintained — see how long must a product passport remain available.

Where things go wrong in practice

Internal item codes are confused with the official product identification. An ERP system knows a product by an internal SKU, while the passport requires a different, unique identification code. Without a translation table between the two, confusion arises when linking, especially if one internal code covers multiple batches.

Inventory movements are not transferred to the passport data. An inventory system records, for example, that a batch of steel has been remelted, split or combined, but that change does not automatically reach the passport. This plays a strong role in the question of whether steel is registered per batch or per unit — see do I register steel per batch or per unit — because the registration unit in the ERP system must align with the unit on which the passport is based.

Export files from the ERP system do not comply with the required format. Many ERP packages export by default in Excel, CSV or a proprietary XML structure. Without prior alignment, such a file often proves incompatible with the format required for the passport, resulting in delays and additional manual work.

It is assumed that the link also works without an internet connection. Some warehouse management systems on the shop floor run partly offline, for example on a warehouse terminal. This raises the question of whether the passport itself must also be accessible without a connection; this is a separate issue independent of the link with the ERP system. See must the product passport also work without internet connection.

Access rights between systems are not regulated. A link means that data flows between two or more systems, often via a third party that hosts the passport. If it is not clear who is allowed to view, modify or pass on which data, confusion arises about responsibility in the event of an error — a question that relates to how the data is secured in transit, see how do I ensure that the data in the product passport is secure.

What you can document

• An overview of which fields in the ERP or warehouse management system correspond to which fields in the product passport, including a translation table between internal article codes and the unique product identification code.
• A description of the export format used by the system in question, and a comparison with the format required for the passport.
• Agreements with the party that compiles or hosts the passport regarding the frequency and method of data exchange: one-off upon creation, or ongoing when changes are made.
• A procedure for communicating changes in inventory, batch assignment or product properties to the passport data, including who is responsible for this.
• An overview of who within the company has access to the link between the company's own system and the passport, and what rights are associated with this.
• A documented agreement on what happens to the link and the data flow if the passport for a product is amended, withdrawn or replaced.