Why the ERP Is Your DPP Starting Point

Before working through the specifics of any particular ERP system, it helps to understand why ERP integration is central to the DPP creation process rather than peripheral to it.

Your ERP system already knows things that a DPP requires: your product catalogue and the identifiers attached to each item, your bill of materials and the suppliers who provide each component, your production records and the batches they belong to, your quality certifications and their validity dates, and the markets where you sell each product. That information was entered into your ERP to support business operations. For DPP compliance, it needs to flow somewhere else — into a regulatory instrument that can be scanned by customs, audited by market surveillance authorities, and read by the recycler at end of life.

The alternative — a separate DPP data entry process — creates two problems that compound over time. First, the data diverges. The DPP has last year's material composition because no one remembered to update it when the supplier changed. Second, the workload scales linearly with your catalogue, and it sits on someone's to-do list competing with operational priorities. Integration solves both problems at once.

Data Mapping: What Lives Where and How It Translates

The hardest part of ERP-to-DPP integration is not the API call — it's the data mapping. ERP data models were not designed with DPP compliance in mind. They use internal codes, proprietary structures, and business-oriented field names that need translating into the standardised format the DPP schema expects.

Product Identification Mapping

Your ERP has a product code or material number. Your DPP needs a GTIN and a persistent unique identifier. The mapping is not always one-to-one. A single ERP material number might correspond to multiple GTINs (different packaging sizes, country-specific variants). Establishing this mapping table before any technical work begins saves significant rework later. The DPP requirements checklist documents exactly what identifier formats the regulation expects.

Material Composition from Bill of Materials

The bill of materials in your ERP is a production instruction — it tells the factory what to combine and in what quantity to make a unit. It is not expressed as percentages of final product weight. Converting a BOM to the material composition format required by a DPP involves calculating the contribution of each component to the finished product weight, then expressing that as a percentage. Components from the same raw material category need to be consolidated. By-products and processing aids that don't appear in the finished product need to be excluded.

This calculation layer is typically built into the integration middleware rather than the ERP itself. It runs when the integration is triggered, not as a standing query on the BOM table.

Supplier and Supply Chain Data

The ESPR regulation requires supply chain transparency in DPPs, not just the manufacturer. Your ERP's vendor master is the primary source for supplier data. The mapping challenge here is that ERP vendor records are often incomplete for DPP purposes — they contain billing and purchasing information but may not have the manufacturing site address (as distinct from the registered office), the country of origin for each component, or the supplier's own sustainability certifications.

Addressing these gaps is a data quality project as much as a technical one. The integration will surface them systematically — every record where a required field is empty becomes a task in your supplier engagement process.

SAP Integration Specifics

SAP S/4HANA and SAP ECC are the most common ERP environments in the manufacturing companies that ESPR will affect first. The integration approach differs somewhat between versions.

SAP S/4HANA

S/4HANA offers the cleanest integration path. The recommended approach uses SAP Integration Suite (formerly Cloud Platform Integration) as the middleware. Integration Suite provides pre-built adapters, message transformation tools, and monitoring dashboards without custom development.

The trigger is an iFlow (integration flow) that subscribes to material master events via the SAP Event Mesh. When a material is created or a specific extension field is updated (a field you add to the material master to track DPP status), the iFlow fires. It calls the BOM API to retrieve material composition, calls the vendor master API for supplier data, calls the quality management API for certifications, transforms the combined payload into DPP schema format, and POSTs to the DPP-Tool API.

SAP's own Product Footprint Management (PFM) module, if deployed, can supply lifecycle carbon data directly. PFM stores PCF (Product Carbon Footprint) values against material numbers — the integration can query PFM and include the latest PCF value in the DPP payload automatically.

SAP ECC

ECC is older and has fewer native API capabilities than S/4HANA. The integration typically uses BAdI MM60_CHANGE or custom User Exits in the material master maintenance transaction (MM01/MM02) to trigger an outbound RFC call. That RFC calls a middleware layer — SAP PI/PO, or a standalone integration tool — which handles the transformation and the call to the DPP API.

ECC integrations are more complex to build but perfectly viable. The key recommendation: use an SAP-certified integration consultant for the ECC-side BAdI work, and keep the transformation logic in the middleware rather than ABAP — it's easier to maintain and update as the DPP schema evolves.

Oracle ERP Cloud Integration

Oracle ERP Cloud (Oracle Fusion) has strong native REST API support, which makes the integration architecture simpler than SAP. Oracle provides business events that fire when product records are created or updated — the same event-driven model that works well for DPP integration.

The Oracle Integration Cloud (OIC) is the natural middleware. OIC has native connectors for Oracle ERP Cloud and can call external REST APIs. The integration flow: Oracle ERP creates/updates an item → OIC business event triggers → OIC retrieves item details, BOM, supplier data via Oracle ERP APIs → OIC transforms to DPP schema → OIC calls DPP-Tool API → DPP-Tool returns DPP URL → OIC writes URL back to item record in Oracle ERP for reference.

Writing the DPP URL back to the item record is a detail that's easy to skip but valuable in practice. It lets your operations team see, in the ERP, whether a DPP exists for a given product and what the URL is — without needing to log into a separate system.

Microsoft Dynamics 365 Integration

Dynamics 365 Supply Chain Management is increasingly common in mid-market manufacturing. Its integration with DPP-Tool can be achieved through Power Automate with no custom code, making it accessible to companies without dedicated integration developers.

The Power Automate flow: trigger on Dynamics 365 entity creation (Released Products entity in D365 SCM) → retrieve product details via Dataverse API → retrieve BOM via D365 Engineering Change Management API → build DPP payload → HTTP action to DPP-Tool API → store returned DPP URL in a custom field on the Released Product entity.

For higher volumes or more complex transformations, Azure Logic Apps or Azure Integration Services provide the same event-driven approach with better monitoring and error handling. The Dynamics 365 data connector for these services is well-documented and widely used.

Automation and Real-Time Synchronisation

The integration should not require human intervention for routine updates. The goal is a system where your team manages products in the ERP exactly as they always have, and DPP records stay current automatically.

Achieving this requires thinking through all the events that should trigger a DPP update, not just initial creation. The list typically includes: material composition change (supplier change or BOM revision), new certification added or existing certification renewed, carbon footprint recalculation (quarterly or after methodology update), manufacturing site change, and market scope change (product newly sold in a market where DPP is required).

Each of these events is a separate trigger in your integration. Building them all at launch is ambitious — the practical approach is to launch with creation and critical updates (composition changes, certification renewals) and add remaining triggers in subsequent sprints. The step-by-step guide includes a prioritisation framework for deciding which data updates are most critical to handle in real-time versus periodic batch sync.

Testing and Governance

ERP integrations that work perfectly in test environments sometimes fail in production because of data quality issues that the test data didn't expose. Before go-live, run the integration against a representative sample of your actual production data — not clean sample records created for testing. This is where you'll find the vendor records missing country codes, the materials with BOM percentages that don't add up to 100%, and the GTINs that are duplicated across product codes.

Governance matters beyond go-live. Assign ownership of the integration — someone who is notified when API calls fail, who monitors the error queue, and who coordinates with your ERP team when schema changes require mapping updates. The DPP regulation will evolve as delegated acts are finalised, and the DPP schema will evolve with it. Your integration will need maintenance, not just deployment.

The DPP-Tool platform includes an integration health dashboard that shows call volumes, error rates, and data validation failures in real time. Connecting your on-call alerting to this dashboard is a straightforward step that prevents compliance gaps from going unnoticed.

Where to Start

The first step is a data audit, not a technical specification. Map your product catalogue against the DPP requirements checklist and identify which fields you have, which are partial, and which are missing entirely. That audit tells you the scope of the integration and the data quality work that needs to happen in parallel with technical development.

The DPP software comparison is worth reviewing before committing to a platform — the integration capabilities of the DPP platform matter as much as the features of the passport itself. And the pricing page has enterprise plan details for organisations needing dedicated integration support.