Can I link the product passport to my ERP or inventory system?
Linking is possible, the form is not fixed in law
Yes, a digital product passport can in practice be linked to an ERP or inventory system, but the ESPR does not prescribe how that linking should look. The Regulation does set requirements for the passport itself: it must be technically structured so that data is machine-readable and systems can automatically read and process it on the basis of open standards rather than closed, brand-specific formats (Article 11 of the ESPR, Regulation (EU) 2024/1781). That requirement is directed at the passport and the data carrier, not at the internal systems of a tyre importer, wholesaler or fleet manager. Whether and how a link with a specific ERP package works is therefore a matter of technical implementation by the party that compiles and hosts the passport — in this case a platform such as tyrepas.eu — and not something the law regulates in detail.
For whom this is relevant, and for whom it is not
This question is particularly relevant to parties processing large volumes of tyres and where product data already exists somewhere in a system: importers managing article numbers, batch data and technical specifications, wholesalers keeping inventory by tyre type, and fleet managers linking tyres to vehicles. For them, a link is mainly practical: data does not then need to be entered twice, and passport information can flow back to their own system.
For end users who simply buy a tyre and scan the QR code, linking to an ERP system plays no role — they read the passport, they do not feed it. And for smaller parties without their own system, linking is also not relevant: the passport can just as well be supplied and consulted manually, without this affecting its validity. The technical requirements from Article 11 moreover concern the passport as such, not the question of whether a provider of passport services must offer a specific link with a particular ERP brand.
No firm date yet, but a clear work programme
When the obligation for a digital product passport for tyres comes into force is not yet fixed. In the ESPR work plan for the period 2025-2030, a delegated act for tyres is expected in 2027; only with the publication of that will a concrete date of entry into force become known. Until then, there are no mandatory requirements for tyres on the passport itself, and thus not on the way data is supplied or exchanged.
This does not mean there is nothing to do. The general requirements from Article 10 and Article 11 of the ESPR are already fixed as a framework within which the delegated act for tyres is further detailed: machine readability, open standards and interoperability are not a new invention appearing only in 2027, but the foundation on which tyre-specific rules are built. Whoever now thinks about a link is therefore not building on sand, even though the final date is still missing.
How this is approached in practice
The first step is to determine which data already exist in the ERP or inventory system that will later need to appear in a passport: article number, batch or batch data, production date, technical specifications per tyre type. Many of those data already exist, they are just not yet available in structured form for a passport.
The second step is to find out what format the party that compiles and hosts the passport accepts as input. Because tyrepas.eu builds the passport from data supplied by the manufacturer or importer, the practical question is not so much whether linking is possible, but in what form data supply works most conveniently: a periodic export from the ERP system, a structured file, or another supply route.
The third step is to consider the other direction: feeding passport data back into your own system, for example so that a fleet manager can link passport information to a vehicle registration without having to search for the passport themselves via the QR code. This too is a matter of technical alignment between the ERP system and the platform, not a legal obligation.
Finally, it is important to take into account the duration: a passport is hosted for a period of ten years. If you set up a link, it is wise to also think about updates during that period — for example when product data changes — so that the link not only works at the first delivery, but also with later amendments.
The legal basis: Article 10 and 11 ESPR
The requirements for the digital product passport itself are laid down in Article 10 of the ESPR (Regulation (EU) 2024/1781), which sets out the general requirements for the passport. Article 11 of the same regulation specifically addresses the technical design and functioning of the passport, with emphasis on interoperability and open standards so that data is machine-readable and interchangeable. Both articles focus on the passport as a product, not on the internal information systems of importers, wholesalers or fleet managers — linking to these is a technical implementation that comes on top of this.
If you want to prepare now, the best approach is to map your own product data and contact the party that will compile and host the passport for tyres, to discuss which delivery route best fits your existing ERP or inventory system.
What 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 available on EUR-Lex. We provide references per statement; you do not have to take our word for it.
What you must do concretely
What is expected of you
The product passport must be able to receive data from a source system
A product passport is not manually typed into a standalone form — the data comes from somewhere: from an ERP system, an inventory management package, an export from the manufacturer, or a combination thereof. Article 10 of the ESPR (Regulation (EU) 2024/1781) sets requirements for which data must be in the passport and how that data is accessible, but does not prescribe via which system a company supplies that data. For a tire importer or wholesaler with 10 to 100 employees, this practically means there must be a fixed, repeatable way to get product data from their own system into the passport — not a one-off manual entry that has to be reinvented for the next shipment of tires.
The link must match a unique identification code per product
Article 11 of the ESPR describes how the digital product passport must function technically, including the link between a product and its passport via an identification code. An ERP or inventory system usually works with its own article numbers, SKUs or internal codes. For the link with the passport, that internal code must match or be translated to the identification code that the passport uses. Companies that already maintain a clear, unique code per tire size or per batch in their inventory system have an advantage here; companies that work with collective items or general model names often discover only when linking that their internal administration is not granular enough. More on that first step can be found in how do I give each product a unique identification code?
Changes in the source system must be reflected in the passport
An inventory system is never static: prices change, specifications are updated, a supplier adjusts a composition. Article 10 assumes a passport that reflects the current state of affairs insofar as the data category requires. For a company, this means that a link with its own system must work not only at first entry, but also at later modifications — otherwise a passport is created that was correct at the moment of publication, but no longer is.
The link must be traceable back to the source
A passport that displays data without it being possible to trace which system, which export or which version that data comes from is difficult to justify in an inspection. This does not follow from a specific article but from the practical side of articles 10 and 11 together: data must be correct and verifiable. For companies with a link to their ERP, this means that some form of logging or version control is desirable — when which set of data was transferred, and by whom.
Where things go wrong in practice
A wholesaler links the inventory module of the ERP system to the passport once at launch, but forgets that new tire sizes added later are not automatically included — the passport remains stuck with the product range from the start date.
An importer uses a collective code in the ERP system for an entire product line ("175/65R14 summer tire, various brands"), while the passport must work per unique identification code. The link then produces one passport for products that actually each need their own passport — see also how does the tyre size relate to the unique identification code?
A fleet manager receives an export from the manufacturer in a format that does not match their own inventory system, and the data is manually retyped into an intermediate file. At the next delivery, that intermediate file is not updated, so the passport shows an older version of the specifications than what is actually in the warehouse.
A company links the ERP system directly to the passport without an intermediate step, and an error in an export field (for example, a mixed-up column with tire sizes) ends up unseen in multiple passports, because no one checks the linked data after transfer.
An importer thinks that coupling once is sufficient for all future variants of a model, while in fact separate data are required for each size or version — the question of whether data may be reused for different tire sizes of the same model then comes up too late, see can I use the same data for multiple tire sizes of the same model?
What you can record
- An overview of which system (ERP, inventory management, supplier portal) is the source for which data field in the product passport, so that in case of a question or inspection it is immediately clear where a figure or specification comes from.
- A fixed procedure for transferring data for new products, including the moment when the unique identification code is assigned and linked.
- An agreement on who is responsible for updating the product passport when data in the source system changes — and within which workflow that occurs.
- A control step after each coupling or export, in which spot checks are carried out to verify whether the data in the product passport match the source system.
- A log or version history of what was transferred and when, so that a change can be traced afterwards.
- Documentation of the technical coupling itself (which export formats, which fields are mapped, which software or intermediate layer is used), usable as an appendix in internal audits.
For companies that still need to determine whether their tires are even subject to this obligation, that is a logical prior step — see does the digital product passport apply to my tyres? Those who want to know more about the role of the product passport in the chain as a whole, and where the coupling with their own system fits in, will find a general explanation in what is a digital product passport for tires?
This is not legal advice. This page provides general information about the legislation 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 based on the sources above, checked by a human on 2026-08-22. Is something incorrect? Let us know — corrections are given priority.