Most manufacturers already hold the data a Digital Product Passport requires — in their ERP, in their product master, in their batch records. The question is whether the DPP platform they choose can actually read it. Or whether someone on the operations team is about to spend three months in spreadsheets.
When a compliance manager or IT director evaluates a DPP platform, the conversation usually starts with ESPR requirements and ends somewhere in a discussion of API protocols. That's the wrong level of abstraction.
The question that actually matters is simpler: does your team have to enter product data twice? Once in your ERP, and once in the DPP platform?
If the answer is yes, you've bought yourself a compliance workflow that runs parallel to your operations — and parallel systems diverge. A material composition that gets updated in SAP but not reflected in the DPP is not just an inconvenience. Under ESPR (Regulation EU 2024/1781), the DPP must reflect the current state of the product — not its state at the time of first publication. If it's out of date, you're out of compliance.
This is why the integration architecture of a DPP platform matters more than its interface.
The market has a habit of calling everything an integration. A CSV template is called an integration. A third-party middleware connector is called an integration. A webhook that fires once a day is called an integration.
There is a difference between a plugin and a platform layer.
Fluxy.One built its SAP connection as a native layer within the platform — not an external connector that sits between two systems, not a middleware dependency with its own failure modes and licensing terms. The SAP Business One integration is live today: bidirectional synchronisation of product master data and batch records, without manual export steps and without custom ABAP development on the SAP side.
For companies running SAP ECC — the older, still widely-deployed version — the same architecture arrives in Q2 2026, operating via SAP Service Layer. Again, no custom development required on either side. The platform absorbs the complexity; your SAP environment stays unchanged.
Odoo is live. CSV and SFTP import covers any ERP that can produce a standard export — which is most of them, and for many mid-size manufacturers will be the primary integration path for the first year or two. It is worth treating seriously: a well-structured CSV import with field validation and error reporting is more reliable than a poorly implemented API connection, and Fluxy.One's bulk import handles up to 10,000 records per batch with both.
Microsoft Dynamics integration is confirmed for July 2026, timed to align with the EU DPP Service Provider certification deadline.
Take a concrete situation. A manufacturer updates a material composition in SAP — a supplier changed a component, the BOM is revised, the record is saved. In a one-way integration, nothing happens on the DPP side. Someone has to notice the change, log into the DPP platform, find the affected SKUs, and update them manually. In a catalogue of 300 models, that is a manageable nuisance. In a catalogue of 1,300, it is a compliance risk — because the gap between what SAP knows and what the DPP says will widen every time a record changes and no one catches it.
Bidirectional integration closes that gap structurally, not by process. When a product record changes in the ERP, the DPP platform sees it. When a DPP is published, validated, archived or flagged by a compliance check, the ERP reflects that status. The operations team stops maintaining two versions of the same product.
Because Fluxy.One is built on GS1 standards natively — not as a layer on top of a proprietary data model — status changes are recorded using EPCIS 2.0, the GS1 standard for supply chain event data. EPCIS 2.0 (Electronic Product Code Information Services) captures what happened to a product, where, when, and why — in a format that other GS1-compliant systems, customs authorities, and market surveillance bodies can read directly. That means the event record of a DPP being published, updated, or archived is not a platform-specific log. It is a standardised, interoperable event stream. For companies operating across multiple markets or trading partners, that distinction matters.
This matters specifically under ESPR because the regulation requires the DPP to reflect the current state of the product — not its state at the time of first publication. A DPP that was accurate in January and wrong in March is not a compliant DPP in March. Bidirectional synchronisation is not a convenience feature. It is how you keep the record current without adding headcount.
One practical boundary worth naming: ERP systems hold product master data well. They hold material composition, batch identifiers, production facility codes, and variant structures. What they typically do not hold is DPP-specific data — recycled content percentages in the format ESPR requires, supplier GLNs (Global Location Numbers) as defined by GS1, or lifecycle event records like repair and ownership transfer. That data has to be added to the DPP layer separately, usually during onboarding and supplier data collection. The integration automates what the ERP already knows. The rest is a one-time enrichment, not ongoing manual entry.
Most manufacturers thinking about DPP are focused on the input problem — getting product data into the passport without rebuilding their operations. That is the right place to start. But it is not the whole picture.
ESPR requires collecting structured, validated data about every product in your catalogue: material origin by batch, supplier identifiers, recycled content, production facility records, lifecycle events. That data has to be machine-readable, queryable, and retained for at least ten years. It is a compliance obligation.
It is also a dataset that most companies do not currently have in this form — centrally stored, validated against a regulatory schema, and linked to individual SKUs and production batches.
A manufacturer who builds this infrastructure properly ends up with something useful beyond the QR code on the product. Material composition across the full catalogue, in one place. Supplier origin by batch, not buried in a procurement system. Lifecycle events — repairs, resales, ownership transfers — appended by authorised actors over time and recorded as EPCIS 2.0 events. That last point is worth pausing on: every state change in the product's life is written to an immutable, standardised event log that travels with the product identifier, not with the platform. A repairer in Poland and a recycler in the Netherlands can both append to the same chain of events, in a format any GS1-compliant system can read. That is what supply chain traceability looks like when it is built on open standards rather than on a vendor's proprietary schema.
What this looks like in practice today: Fluxy.One provides access to the DPP data layer via standard Google APIs. Companies already using Looker Studio or other tools in the Google ecosystem can connect without custom development and build their own reporting on top of live DPP data. It is not a packaged analytics product — it is API access to a validated, structured dataset, and what you build with it depends on what questions you are asking.
Before the end of 2026, the platform will add a dedicated analytics API and a developer sandbox for custom integration and testing. That is when the data layer becomes properly programmable for teams outside the Google ecosystem.
The companies treating DPP as data infrastructure rather than a compliance checkbox are the ones who get something back from the process. The regulation forces you to collect the data. What you do with it after that is optional — but the option is there.
1 - Is the ERP connection built into the platform, or does it depend on a third-party connector or middleware? Third-party connectors introduce their own reliability, maintenance and licensing considerations.
2 - Is synchronisation bidirectional, or does data only flow one way? One-way import means your ERP never knows what's happening on the DPP side.
3 - What happens when a product record changes in your ERP after the DPP is published? Is there an automated update path, or does someone have to trigger it manually?
4 - Is the integration included in the subscription, or is it a separate implementation fee? Custom integration scopes have a habit of expanding.
5 - Can you access the DPP data layer for your own analytics, or is it locked inside the platform's own reporting interface?
The answers will narrow the field considerably.
Fluxy.One is an EU ESPR Digital Product Passport platform for manufacturers, importers and distributors preparing for EU product regulations. The platform covers the full DPP lifecycle — from product master data and GS1 Digital Link QR codes to regulatory compliance validation and supply chain traceability — with native integrations for SAP Business One, SAP ECC, Odoo and Microsoft Dynamics, and a GS1-native EPCIS 2.0 event layer for standardised supply chain event recording. Enterprise clients can connect existing BI tools via standard Google APIs today; a dedicated analytics API and developer sandbox are scheduled for Q4 2026. This article reflects the regulatory and platform position as of May 2026. ESPR implementing acts continue to develop; this article is for orientation, not legal advice.
Fluxy.One — the transparency infrastructure for the global economy.
Book Free Demo
Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information
Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information
