matrapas.eu

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

Coupling is technically possible, but the form is not yet fixed

The digital product passport is set up as a structured, machine-readable data file, and in principle this fits with coupling to an ERP or inventory system. The ESPR requires that the data behind the passport be recorded on the basis of open standards and that systems must be able to exchange data with each other. This is precisely the starting point on which coupling with an existing business system would be based: no manual entry per mattress, but a supply from the data that a manufacturer or importer already maintains. What that coupling will look like in practice — which file format, which fields, which delivery method — is not yet fixed, because the technical implementation for mattresses has yet to appear.

Who this applies to and who it does not

This explanation concerns the data structure behind the passport, not a specific interface or connector that is already available. The ESPR describes requirements for interoperability and the way the passport is technically structured (the data carrier, the unique identification codes, the storage of data), but does not regulate how an individual ERP package or inventory system must connect to it. The latter is a matter of implementation, not legislation: the regulation determines what must be interoperable, not which software a company works with. For a bedding specialist retailer that only sells and does not compile a passport, coupling with its own ERP system is usually not relevant; this is mainly an issue for the party that supplies the data, usually the manufacturer or importer.

The technical specifications will come with the delegated act

There is no fixed date yet for the technical implementation for mattresses. The European Commission's work plan for 2025-2030 expects a delegated act for mattresses in 2028, but that is a schedule, not a commitment. Until that act is published, it is not fixed which data format, which fields and which delivery method will apply for mattresses. What is fixed is the framework from the ESPR itself: the passport must be structured according to open, interoperable standards and linked to a unique product identification. That framework will not change; the specific implementation for mattresses will.

What this means for preparation

Anyone thinking about coupling now can do a number of things without waiting for the final specification. First, it is useful to determine which data about a mattress already exist somewhere in your own system — material composition, origin of raw materials, production date, batch or order number — and whether that data is recorded at product level or only at order level. Next, it is helpful to see whether the system has an export function that can produce structured data (for example an export in a standard format), because that is the starting point for later coupling, regardless of which exact format the delegated act will eventually prescribe. Then it is practical to determine whether data is maintained per product, per batch or per order, because the passport will ultimately receive a unique identification per product. Finally, it is worthwhile to maintain contact with the party that compiles and hosts the passport, so that when the technical specification is published, it is quickly clear what form of delivery is needed and whether the existing system setup meets that requirement or requires adjustment. A direct, automated coupling between an ERP system and the passport is therefore not something for which a technical standard already exists today; what is possible is to already organise your own data in such a way that coupling can be made easily later.

Where this follows from: Article 10 and Article 11 of the ESPR

Article 10 of the ESPR (Regulation (EU) 2024/1781) describes the requirements for the digital product passport, including the requirement that data is recorded on the basis of open standards and that systems processing data must be interoperable. Article 11 concerns the technical design and operation of the passport, with provisions on the data carrier, the unique identification codes for product, market participant and facility, and the way data is stored and made accessible. Together, these articles form the framework within which a link with an external system is conceivable, without them establishing a specific technical standard for mattresses — that follows only from the delegated act still to be published.

What to do now

For now, the most concrete thing that can be done is: put your own product data in order and record it at product level (rather than only at order level), map out an export option from your existing system, and monitor the publication of the technical specification for mattresses. Once that specification is available, this page will be updated with which format and which submission method apply.

Where this is based on

The regulation itself is on EUR-Lex. We provide references per statement; you do not have to take our word for it.

What you concretely must do

What is expected of you

Linking a product passport to an ERP or inventory system is not a legal requirement in itself. The ESPR does not prescribe which source systems a manufacturer uses to supply passport data. What is established, however, are requirements for the passport itself: how it works technically and what it must be able to do. These requirements indirectly determine whether — and how — a link with internal systems makes sense.

The passport must be technically aligned with uniform operation

Article 11 of the ESPR (Regulation (EU) 2024/1781) describes technical requirements for the digital product passport, such as interoperability with the systems used by the Commission and the market. For a company with 10 to 100 employees, this means that passport data cannot simply remain in its own, non-standard format: it must ultimately be in a form that can be read by the passport system. Whether this is done via a direct link with the ERP system, or via manual export, is a choice — not an obligation from the regulation.

The content of the passport must be current and guaranteed to be correct

Article 10 of the ESPR (Regulation (EU) 2024/1781) sets requirements for what must be in the passport and who is responsible for it. Practically, this means that the data coming from an ERP or inventory system — material composition, production date, batch number — must be correct and current at the time the passport is created or updated. For a company with multiple product lines and regular changes in composition (different foam type, different supplier of filling material) this is a reason to consider whether data is being manually entered, or automatically taken from the system in which it is already maintained.

Each product must be traceable to the correct data

A link with an inventory system only makes sense if each physical product has a unique identification code that connects the passport to the correct product data. Without this link between product and code, an ERP system cannot provide meaningful input to the passport, no matter how automated the rest of the process is. Companies that have not yet set this up will find it here how do I give each product a unique identification code?

Where things go wrong in practice

Inventory system and passport data drift apart. A mattress manufacturer changes the filling of a model line, updates this in the ERP system, but forgets that the same change must also be applied to the already published passports. Result: passport and actual product no longer match.

Link is set up too complex for the company's scale. A company with a handful of product lines builds a fully automated real-time link between ERP and passport system, when a periodic export with manual review would have been more than sufficient for the number of changes that actually occur.

Unique identification number is not applied consistently. The inventory system uses internal item codes, the passport requires a different identification structure, and no one has documented how these two relate to each other. In an inspection or when a return shipment arrives, it is then not easy to trace which passport belongs to which physical product.

Responsibility for data updates is not assigned. The IT department thinks the quality department maintains the passport data, the quality department thinks this happens automatically from the ERP system. No one actually checks it, so data becomes outdated without being noticed.

Assumption that linking is mandatory, while manual submission is also possible. Some companies invest in expensive integrations based on the assumption that this is a legal requirement, while the regulation itself does not prescribe how data is submitted — only that the passport must meet certain technical and content requirements.

What you can record

  • An overview of which data comes from the ERP or inventory system, and which data is supplied separately (for example, by a filling material supplier).
  • A documented link between internal item codes and the unique identification code used in the passport — see also how do I give each product a unique identification code?
  • An agreement on who is responsible for implementing changes to product composition in existing passports.
  • A choice and justification for the method of data supply: automatic coupling, periodic export, or manual entry — including consideration of whether separate software is needed for this, as discussed at do I need special software to create a digital product passport
  • A procedure for checking consistency between inventory data and published passports, with fixed control moments.
  • Documentation on which fields from the ERP system are mandatory for the passport and which are optional, so that new staff can take this over without consultation.
  • A note on the situation for bespoke products, where inventory systems often work differently than for standard models — see how does the product passport work for made-to-measure mattresses?

This is not legal advice. This page provides general information about the legislation 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 wrong? Let us know — corrections are given priority.