Can I link the digital product passport to my ERP or inventory system?
Coupling is possible, provided the data is supplied in a structured format
Linking a product passport to an ERP or inventory system is basically possible, because the ESPR prescribes that the digital product passport is technically built in such a way that data exchange takes place in an interoperable and machine-readable manner (Article 11 of the ESPR, Regulation (EU) 2024/1781). This means that the data already stored in an ERP or inventory system — material composition, origin, components, batch or serial numbers — can in principle be the source from which the passport is built. The link then does not consist of a direct, live connection between two systems, but in the fact that the same data already maintained internally is supplied in a suitable format for the passport.
Which data this works for, and which it does not
This concerns data already recorded somewhere and relevant to the passport of a specific product: technical specifications, material information, repair and maintenance data, or origin information. For that kind of data, structured supply from an existing system makes sense. This does not concern a general, permanent system link prescribed by the ESPR — the regulation does not oblige any manufacturer or importer to use a specific technology, API or software package. Article 11 addresses the technical design of the passport itself: how the data carrier, the register and access to data are arranged. It does not lay down how a company organises or exports its own ERP system. Also important: which data precisely must be in the passport differs by product group and is worked out per product group in a delegated act. What is a relevant ERP field for one product (for example a material percentage) may not apply to another product group.
The technical requirements already apply, the product group specifications not yet everywhere
The ESPR itself, with the general requirements for the digital product passport (Article 10) and its technical design (Article 11), has been established and forms the framework within which each product passport must function. When a specific product actually needs a passport and which data must be in it exactly is regulated separately per product group. For many product groups that elaboration has not yet been published or not yet come into force. Until it is established for a product group which data are mandatory, there is therefore no concrete obligation to set up a link or data flow from an ERP system — it is nevertheless useful to already know where the relevant data would come from internally, so that when an obligation starts there is no need to start from scratch.
How this is tackled in practice
The first step is to check which data in your ERP or inventory system are already present and relevant to what a passport typically contains: product identification, material composition, origin, components, warranty or repair information. Next, it is useful to examine how to export that data from the system — as a file, as a report, or via a structured connection — in a form that is readable and transferable, in line with the open and interoperable design that Article 11 requires for the passport. Subsequently, it is important to link the data to the unique product identification that the passport requires under Article 10, so that each passport is demonstrably associated with the correct product. Because a passport must remain current throughout the entire lifespan of a product, it is practical to also think about a recurring process: how is a change in the ERP system (for example, an adapted component or a new supplier) implemented in the passport at a given time. This does not necessarily have to be real-time — periodic submission, for example when adjustments or new productions occur, is sufficient in most cases. A platform that compiles passports from submitted data, such as prodpas.eu, typically receives that data in exactly that way: as structured submission from the existing administration of a manufacturer or importer, not as a permanent live connection between two systems.
Where this follows from: Article 10 and 11 of the ESPR
The obligation for interoperability and machine readability of the digital product passport is laid down in Article 11 of the ESPR (Regulation (EU) 2024/1781), which governs the technical design and operation of the passport. Article 10 of the same regulation describes the general requirements that a passport must meet, including the link to a unique product identification. Together, these articles form the basis for why source data from an existing system, if submitted in a structured manner, can be suitable as input for a passport — without the regulation prescribing which technique or which system a company uses internally for this purpose.
If you want to prepare now, it is best to start with an overview of which product data are in your own ERP or inventory system and in what format they can be exported. Once it is clear for your own product group which data a passport must contain, that submission from the existing administration is usually the practical starting point.
Where this is based on
- Regulation (EU) 2024/1781 (ESPR), Article 11 (technical design and operation of the digital product passport)
- Regulation (EU) 2024/1781 (ESPR), Article 10 (requirements for the digital product passport)
The regulation itself is on EUR-Lex. We provide references for each claim; you do not have to take our word for it.
What you must do concretely
What is expected of you
A link between an ERP or inventory system and the digital product passport is not a standalone wish that exists separately from the regulations — the way in which data is supplied, made accessible and kept up to date directly affects what Article 10 and Article 11 of the ESPR (Regulation (EU) 2024/1781) prescribe about the digital product passport. For a company with 10 to 100 employees working with multiple product groups, the link is usually not a "nice to have" but the only practical way to maintain passports for hundreds or thousands of articles.
The passport must be linked to a unique identification code
Article 10 of the ESPR requires that each digital product passport can be traced back to the product it belongs to, via a unique identification code. This is also immediately the key to linking it with your own system: the ERP or inventory system already works with article numbers, batch numbers or SKUs, and these must align with the identification code used in the passport. Without that unambiguous link, there is a risk that an update in one system cannot be found in the other. How that identification code is precisely constructed and assigned is described on the page about how each product receives a unique identification code.
The technical implementation must align with a standardised system
Article 11 of the ESPR addresses the technical setup of the passport: how data is stored, made accessible and made machine-readable. For a link with an ERP system, this means that the exchange cannot be freely formatted, but must align with a standard that machines on both sides can read. In practice, this usually comes down to working with a system such as GS1 Digital Link, where an identification code directly points to the correct passport data. What this entails and whether it is relevant for a specific company is explained on the page about what GS1 Digital Link is and whether it is necessary for the digital product passport.
Data that changes must remain up to date in the passport
An ERP system is constantly changing: inventory levels, batch data, compositions, suppliers. Not all of that information belongs in the digital product passport, but the data that does — such as material composition, repair information or sustainability characteristics — must be correct at the moment someone scans the QR code. For many companies, a link with their own system is the only way to make this manageable at scale, rather than manually updating each passport. Whether and how this can be done automatically is covered on the page about automatically updating data in the digital product passport.
The passport must remain accessible, even independently of your own system
Article 10 sets requirements for the availability of the passport. A link with an ERP system is useful for maintaining data, but the passport itself must continue to exist and remain accessible, even when the internal system is replaced, migrated or phased out. This requires a separation between the place where the source data lives (the ERP system) and the place where the passport is hosted and made accessible.
Where things go wrong in practice
The ERP system is viewed as the passport itself. Some companies think that exporting a product overview from the ERP system to a PDF or web page is sufficient. However, the passport requires a fixed identification code, lasting accessibility and a standardised technical structure — an export rarely provides that.
Article numbers in the ERP system do not align with the passport identification. When the internal article number does not correspond one-to-one with the identification code on the QR code, a mismatch occurs that only becomes apparent when someone scans and sees the wrong passport.
A system change breaks the link. When switching to a new ERP system, the link to the product passport is sometimes forgotten, causing updates to stall while the passport remains online with outdated data.
Stock and batch data are accidentally published. A link that is set up too broadly sometimes passes internal data to the passport that is not intended for public consumption, such as purchase prices or supplier names.
One product with multiple passports is not properly distinguished. For products that fall under more than one product group, or that consist of components each requiring their own passport, a simple link at article level leads to confusion about which passport belongs to which component. See on this subject the pages on multiple product passports for one product and one passport per component versus for the product as a whole.
What you can document
- An overview of which fields from the ERP or inventory system automatically flow to the passport, and which do not.
- The link between the internal article number or SKU and the unique identification code used in the passport.
- Agreements on who is responsible for keeping data current after a change in the source data system.
- A procedure for what happens to the link in the event of a system migration or switch, so that the passport does not stall.
- A check on which data may and may not be publicly visible via the passport, before the link goes live.
- Documentation of the standard used for data exchange, including any use of GS1 Digital Link.
This is not legal advice. This page provides general information about the regulations that this platform concerns. We do not know your situation. If you are in doubt about your own case, consult a lawyer or the competent supervisory authority.
Written with AI on the basis of the sources above, checked by a human on 2026-08-22. Is something incorrect? Let us know — corrections are given priority.