The weight of a product sits in materials management. The recycled share sits in the recipe system. The supplier’s certificate is a PDF on a shared drive. The product passport needs all three in one single record, and that is where the integration project lies, not in connecting two systems.
“Seamless ERP integration” is a standard promise that in practice is followed by a three-month project. We publish our guide so that your IT can check, before signing the contract, what is actually queried. This article shows which data the passport needs from your systems, the three routes it takes to reach us and why that fits into two weeks.
What your ERP actually has to deliver
For a DPP to be created, we need per product:
- master data - article number, designation, variants, weights, dimensions, images
- bill-of-materials data - components with quantities and recycled-content shares
- origin data - place of production, batch number, production date
- environmental data - CO2eq per unit, water consumption, energy consumption
- supplier data - who supplies which component (for due diligence)
In your ERP this data is theoretically all present. In practice it is spread across 4 to 7 modules: materials management, production, quality, the supplier master, sometimes a separate module for environmental data, sometimes a system of its own for recipes and bills of materials.
The integration question is not: “Does your ERP deliver data to a DPP?” It is: “How do you bring the data from 5 subsystems together into one coherent data set?”
Three proven routes
Route 1: pull the data from the ERP
Works well with modern ERPs (SAP S/4HANA Cloud, Dynamics 365, Odoo). The DPP provider fetches the data through the ERP’s interface (technically OData or REST). Only the changes, on a schedule or triggered by an event.
Advantages: little development on your side, you provide read access, the provider builds the conversion.
Disadvantages: does not work with older SAP ECC installations without an additional interface layer. You need clear rules on who may read which data.
Route 2: forward the changes
Your ERP reports every change as an event (through SAP Event Mesh, Apache Kafka or RabbitMQ), and the DPP provider takes them in.
Advantages: near real-time, grows with you, the systems do not depend on each other.
Disadvantages: the set-up is demanding and needs infrastructure that not every IT department has. For smaller firms usually overkill.
Route 3: use the integration layer you already have
You already have an integration layer (Mulesoft, Boomi, Informatica, Azure Data Factory) between the ERP and external systems. That layer is the contract: the DPP provider talks to it, never directly to the ERP.
Advantages: existing investments can be used, the rules stay stable, no direct ERP access for third parties.
Disadvantages: your costs for the integration layer grow with it.
What we do differently in concrete projects
Many providers want to connect directly to your ERP. As a matter of principle, we build in an intermediate step: our interface accepts a neutral data format (a JSON schema) that you fill with a tool of your choice. This means:
- you can do the data preparation yourself, with the tools your team knows
- you can replace us - the neutral format is portable
- you retrieve your entire inventory at any time - as CSV, XLSX, JSON-LD and SQL as well as via the REST API
- we provide an import validator that checks your data before the upload
The complete format and every query are publicly documented under /apidocs, as an interface description to OpenAPI. Your IT can examine the interface before a contract is signed - including example requests, error responses and authentication details.
Timeframe with this approach in practice:
- day 1 to 2: mapping workshop. Which ERP field becomes which DPP field?
- day 3 to 5: first JSON exports from the ERP, through our validator.
- day 6 to 8: error fixing (missing fields, inconsistent codings).
- day 9 to 10: first DPPs are live.
Two weeks, not three months. The crux is the mapping workshop - that is where data quality is decided.
What goes wrong: the most common pitfalls
Product master data in several systems: SAP has the article number, the PIM has the images and marketing texts, the PLM has the bill of materials. Nobody has a consistent picture. Solution: define before the project which system leads for which field.
Certificates as PDF: suppliers deliver GOTS, OEKO-TEX or REACH certificates as a PDF scan. That is not a structured data source. Solution: certification operators increasingly offer a query through an interface (OEKO-TEX is ahead, GOTS lags behind). Or: capture manually, but with a validity date so that no expired certificates appear in the DPP.
Formulation confidentiality: especially in cosmetics, food and pharma: the complete formulation is a trade secret. The DPP is supposed to make it public? Solution: the ESPR three-level model. Publicly the product category is shown, authorities see the full formulation. Almost never a blocker, but it has to be clarified early.
CO2 data on a supplier basis: your supplier gives an average value for its entire portfolio, not per batch. Solution: accept it temporarily, adjust supplier contracts in the long term. The ESPR requires product-specific values from a certain deadline, but current practice is a compromise.
Local language versions: your ERP contains the product designation only in German and English. For 27 EU countries you need more. Solution: machine translation with a terminology database; we have a separate article on this.
The questions you should ask before the project
Before you send an RFP to three providers, answer internally:
- How many products/article numbers should have DPPs? (10, 10,000, 1 million?)
- Which systems hold DPP-relevant data today?
- Which department administers each of the systems?
- Do you have an integration layer that should be used?
- Is there an already working interface on top of your ERP?
The answers determine which of the three routes fits you. And they decide whether a project takes two weeks or six months.
Questions on this article
Is the REST interface enough, or do we need middleware?
The interface is enough. The three patterns differ in where the transformation happens, not in what we accept - our interface takes a neutral JSON schema, whatever produced it. A pull from a modern ERP, an event stream and an existing integration layer all end at the same endpoint. Middleware pays off where you already run one and want it to stay the contract with third parties. If none exists today, do not buy one for the product passport.
What does the mapping workshop actually decide?
Which ERP field becomes which passport field - and which system is the leading source where several hold the same value. The workshop sits on days 1 and 2 and is the crux of the whole project, because data quality is decided there and not later in the code. Bring the people who maintain the systems, not only the people who own the project - master data, production, quality and purchasing rarely sit in one department. Everything after it, meaning exports, validation and error fixing, is craft.
Our certificates exist only as PDF scans. What do we do with them?
A scan is not a structured data source and therefore unusable for the passport. Two routes work - certification operators increasingly offer API queries, and where none exists you capture the values by hand, but always with the validity date, so no expired certificate stays in a published passport. Plan the manual route as recurring work, not as a one-off task.
Can our IT examine the interface before we sign anything?
Yes. The complete schema and every endpoint are published as an OpenAPI specification at /apidocs, with example requests, error responses and authentication details. None of it sits behind a sales conversation, so your integration team can size the work before a contract exists. If a provider will not show you its interface at that stage, that is an answer too.
What happens to our data if we change provider?
It leaves with you. The interface accepts a neutral JSON schema rather than a proprietary format, and your entire inventory comes back out as CSV, XLSX, JSON-LD and SQL or through the REST API. That is deliberate - the format you fill is portable, so a change costs an export and not a rebuild. Ask every provider the same question before the mapping workshop, because after it your field names sit in their model.
How long does an integration really take?
Two weeks in the projects we accompany - two days of mapping, three days to the first exports through our validator, three days of error fixing, two days to the first published passports. The long pole is never the code, it is what the validator finds - missing fields, inconsistent codings, values nobody feels responsible for. Plan those days in rather than cutting them. A project that skips them publishes the gaps along with the passports.
Do we have to connect every product at once?
No. Start with the products that need a passport first and with one source system - the neutral schema takes a partial catalogue as readily as a complete one, and imports are repeatable, so later runs update what is already there. That also keeps the mapping workshop small enough to finish in two days. Widening the scope afterwards is a mapping exercise, not a new project.
