Can I link the digital product passport to my ERP or inventory system?
Linking is possible, within the limits of the data format
A link between the digital product passport and your own ERP or inventory system is in principle possible, but how it works depends on the technical design that will be established for the passport. The ESPR (Regulation (EU) 2024/1781) prescribes in Article 10 what requirements a digital product passport must meet, and in Article 11 how it is technically structured and operates. From this it follows that a passport must be machine-readable and interoperable — not that each manufacturer is free to build their own link with any system as they see fit. In practice, the link runs through the platform that compiles and hosts the passport, and through the data format that is agreed for this purpose.
For whom this is relevant, and for what it is not
This question is relevant for manufacturers and importers of aluminium semi-finished products who must supply data for a product passport — profile makers, foundries, packaging aluminium producers. For them it is relevant whether their existing production data (material composition, batch numbers, origin, technical specifications) can flow automatically to the passport, rather than being manually re-entered. This is not about whether a company is obliged to build an ERP link — there is no such obligation. The ESPR regulates what the passport must be able to do (interoperable, machine-readable, accessible via a data carrier such as a QR code), not how an individual company arranges its own internal software. A company without an ERP system can supply data just as well via a form or file; a company with an extensive ERP system may be able to supply that data more efficiently, but is not obliged to do so.
When this applies: date not yet fixed
There is no fixed date yet for when these obligations for aluminium semi-finished products come into force. According to the European Commission's work plan for 2025-2030, the delegated act that must make this concrete for this product group is expected in 2027. Only with that act will it become clear which data fields are mandatory, in what format, and with what technical specifications for exchange — so only then will it become precisely clear how a link with an ERP system can technically work. Until then, it is established that Article 10 and Article 11 of the ESPR form the general framework: interoperability and machine-readability are the starting point, the concrete technical implementation follows later. Once the delegated act is published, the expected implementation date will be added here.
What this means for your approach
For those who want to prepare for this now, the logical sequence is: first map out what data about an aluminium product is already stored in your own system — composition, origin, batch data, technical characteristics. Next, it is worthwhile to see whether that data is available in a structured, exportable way (an export to a file, a link via an interface) rather than only on paper or scattered across multiple departments. After that, it is a matter of aligning with the format that the platform requires for compiling the passport: alupas.eu compiles the passport based on the data that the manufacturer or importer supplies, and how that supply technically takes place — manual entry, file upload, or an automated link — is something to be coordinated with the platform once the technical specifications from the delegated act are known. A company that already keeps its product data clear and structured now will have less work to do later to supply that data, regardless of whether that will eventually be via an ERP link or otherwise.
Where this comes from: Articles 10 and 11 of the ESPR
Article 10 of the ESPR describes the requirements that a digital product passport must meet, including data accessibility and the linking to a data carrier. Article 11 specifically addresses the technical design and operation of the passport system: how data are recorded, stored and exchanged, with a view to interoperability between different systems and actors in the supply chain. Both articles leave the concrete technical standards and formats to later implementing rules; they do establish the principle that the passport must be machine-readable and system-independent in its functioning, which forms the basis for any future linking to an external system such as an ERP package.
If you want to prepare now, the best approach is to get your own product data in a structured and digital order, so that submission — in whatever form — later becomes a matter of connection rather than reorganisation.
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 on EUR-Lex. We refer per statement; you do not have to take our word for it.
What you must concretely do
What is expected of you
The passport must be transferable as a dataset, not only as a screen
Article 10 of the ESPR (Regulation (EU) 2024/1781) describes the digital product passport as a collection of data that is readable and transferable via electronic means. This is a different requirement than "a nice page that opens after scanning a QR code". For a company with 10 to 100 employees, this means that the data contained in the passport must also be available as structured data — not exclusively as text on a web page. Whether and how this is linked to the company's own ERP or inventory system is a choice that the company itself makes; the regulation does not require a link, but it does require a dataset that lends itself to one.
Interoperability between systems is a principle, not a technical choice by the supplier
Article 11 of the ESPR addresses the technical design and operation of the digital product passport and mentions interoperability as one of the principles to which the passport system must comply. This directly affects the question of whether integration with an internal system is possible: a passport set up in accordance with this article is in principle intended to enable data exchange between systems, not to be a closed environment. In practice, a company will mainly notice this when considering which data formats and identification codes the platform uses, and whether these align with what its own ERP system already uses.
The unique identification code is the link between the passport and internal administration
A link between a product passport and an internal system depends on a conclusive identification code per product or batch. Without a clear coupling key, an ERP integration remains difficult to automate in practice, even though this is not explicitly stated anywhere in the text of articles 10 or 11. How that identification code is structured and assigned is described on the page on how you assign each product a unique identification code. For a company that sells aluminium per batch, this is also related to the question of whether registration takes place per batch or per unit, which is explained in more detail on the page on batch or unit registration.
The passport remains in existence even if the internal system changes
An ERP system is replaced, migrated or updated at some point. The product passport itself does not automatically follow suit — it is hosted for ten years, regardless of what happens internally with the inventory administration. This distinction is relevant when setting up an integration: the integration is a convenience for the company's own operations, not a replacement of the obligation for the passport to remain accessible. More about this retention period can be found on the page on how long a passport must remain available.
Where things go wrong in practice
A few situations regularly come up with companies considering an integration between passport and internal system:
- The ERP system is seen as the source, whereas the passport must be the source. Once data has been published, the passport is the authoritative reference for the outside world. Changes in the internal system do not automatically flow through to it, and anyone who confuses this runs the risk that the passport and internal administration diverge.
- Inventory movements are confused with passport changes. An internal inventory system changes daily: quantities, locations, batch statuses. The product passport records product characteristics, not the current inventory position. Anyone who mixes these two types of data in a single integration creates unnecessary complexity — and sometimes unwarranted changes to a passport that has already been published. How changes after publication work exactly is described on the page on amending data after publication.
- An integration is built without taking into account the identification code of the platform. If the internal article number does not align with the code used in the passport, this creates a manual translation step that largely undermines the link in practice.
- It is assumed that an ERP integration also ensures the physical QR code on the product. These are two separate components: the data integration handles information exchange, and the placement of the carrier on the aluminium itself is a separate process. See on this subject how the QR code gets on the product.
- It is assumed that your own system will generate a passport itself in the future. As long as the delegated act for aluminium has not yet been published, it is not established which data format will be exactly mandatory. An integration can be prepared, but the assumption that your own ERP system will independently meet all requirements in the future is premature.
What you can document now
For companies considering an integration between the digital product passport and their own system, it is practical to establish the following points internally — even if the integration has not yet been built:
- Which fields in the ERP or inventory system correspond to which fields in the digital product passport, including the identification code used for each product or batch.
- Who within the company is responsible for keeping current the data that is used both internally and in the passport.
- An agreement on the moment at which data from the internal system is taken over into the passport, and the moment at which this does not automatically happen.
- Documentation on which system serves as the source for which data — so that in the event of an inspection or a question from a buyer, it is clear where a figure or characteristic comes from.
- An overview of whether the passport is set up per unit or per batch, since this determines how an integration with inventory records can best be arranged.
These points do not establish a result and are no guarantee that an integration meets what the delegated act will require — that text does not yet exist. However, they do ensure that a company, once the technical requirements become concrete, does not start from scratch working out which data belongs where.
This is not legal advice. This page provides general information on the legislation that this platform covers. We do not know your situation. If 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 not right? Let us know — corrections are prioritised.