How to integrate Digital Product Passports (DPP) with ERP and improve data management

The project needs to connect several elements: the product record in ERP, information from other sources, the appropriate passport version and the identifier attached to the product. The DPP Registry stores identifiers, registration data and specified metadata, while detailed product information remains in the systems of the responsible economic operator or DPP service provider.

The Digital Product Passport (DPP) provides access to product information within the scope defined for the relevant product group.

PIM (Product Information Management) helps bring together data from different sources, complete product attributes and prepare information for publication in the passport and sales channels.

Integration architecture: Why your ERP needs a PIM buffer for DPP

Defining the relationship between ERP and the Digital Product Passport starts with establishing which system is responsible for each data domain. In the proposed architecture, ERP remains the System of Record for the operational information assigned to it, including purchasing, transactions, suppliers, orders and batch records. In a manufacturing organization, it may also hold the production bill of materials, or BOM. Engineering documentation and revisions may come from PLM, while information about how a product was actually manufactured may come from the production management system.

PIM combines operational data with material descriptions, instructions, documentation, multilingual content and approved environmental assessment results. In this architecture, it serves as a Single Source of Truth for approved product information prepared for publication. We explain this division of responsibilities in our article on why an ERP cannot replace a PIM system.

The buffer is the layer where product information is prepared and checked. Data transport, message queues and retries belong to the integration layer. PIM defines attributes and relationships, checks completeness and supports approval for publication. The available functionality depends on the chosen system and its configuration. Pimcore, for example, provides tools for importing, mapping and transforming data, together with controls over whether imported records are published.

The target data flow may look like this:

ERP + PLM + supplier data + documentation and LCA results → integration layer → PIM → DPP service

Two related processes follow:

DPP service → EU registry: identifiers and required registration data

Product or packaging → data carrier, such as a QR code → relevant passport

In this model, customers access approved information through the DPP service. Handling scans and serving documentation remain separate from the ERP system’s day-to-day operations.

The decision to use PIM depends on the project scope. For a small catalog and straightforward requirements, the DPP application itself may handle some data collection and validation tasks. A more extensive PIM system becomes particularly useful when information needs to be combined from multiple sources and published across different markets, languages and channels.

The regulatory basis for product compliance, or EU compliance, is ESPR, the Ecodesign for Sustainable Products Regulation. It develops the EU Ecodesign framework previously based on EU Directive 2009/125/EC. Requirements for individual product groups are specified through the relevant delegated acts.

What data moves from ERP to the Digital Product Passport?

In Digital Product Passport ERP integration, data mapping defines how a field from the source system will be used in the target information model. This mapping should cover the field’s meaning, unit, source, relationship to the product and update rules.

ERP supplies part of the information needed to prepare a DPP. The scope of publication follows the applicable delegated act or sector-specific legislation. The rules may also determine whether the passport relates to a model, a batch or an individual item.

The table below illustrates how ERP data can be mapped to a PIM/DPP model. Each entry needs to be adapted to the organization’s actual data and the requirements applicable to its products.

Master data and identifiers (SKU, GTIN, manufacturer info)

The integration should use persistent identifiers. Product names may change when an offer is updated, translated or renamed. The key linking records should maintain an unambiguous relationship between systems.

In an organization using several ERP databases, the same SKU may require additional context, such as a legal-entity identifier or source-system identifier. The mapping should therefore distinguish between the internal product-record key, the product identifier used in the supply chain and the passport registration identifier.

Manufacturer data mapping should cover the organization’s name, address and required contact information, linked to the relevant products. It should also establish whether a business-partner record in ERP represents a manufacturer, supplier or importer, since these roles need to be identified separately.

GS1 Digital Link expresses GS1 identifiers, including GTIN, in a form that connects products to online information. The QR code is the data carrier, while GS1 Digital Link defines how identifiers are represented in a web address.

Bill of Materials (BOM) and material breakdown

The BOM describes the components and quantities that make up a product. DPP preparation should establish whether the integration uses the engineering BOM, manufacturing BOM or the record of components actually used in a particular batch.

The mapping needs to connect each component code to its material description and documentation. For example, MAT-017 may identify a specific type of plastic. Information about recycled content or environmental properties requires an additional, substantiated source.

Unit conversions should also be defined. A weight recorded in grams can be converted to kilograms using an agreed rule. Calculating a material’s share in the finished product requires a defined calculation basis, component scope and treatment of packaging.

LCA results and product carbon footprint data should come from the relevant assessment or a verified source. PIM can associate them with the correct product version. We explain this in more detail in our article on integrating LCA data with a PIM system.

Manufacturing & logistics data (batch numbers, serial numbers, plants)

For batch-level or item-level passports, linking information to the time of manufacture is particularly important. The system should keep a record of which versions of components, materials and documents applied to the specific product.

A supplier change may result in different material data for a new batch of a product carrying the same commercial code. The integration should assign information to the correct batches and preserve records relating to earlier production.

Where large numbers of individual items are involved, detailed production records can remain in the system responsible for managing them. PIM and the DPP service can maintain the necessary relationships and the approved information selected for publication.

Supplier documents and compliance records

A purchasing document helps identify the supplier and a specific delivery. Separate certificates, declarations or reports may be needed to substantiate material properties.

The data model should therefore include the document type, issuer, version, validity period and the products or materials covered. The file itself may remain in a document repository or DAM system, with PIM holding its description and relationships.

It is equally important to distinguish between the supplier’s country, the country of dispatch and the material’s country of origin. These fields have different meanings and should be mapped separately. We explain how to obtain missing information in our article on why supplier data can block Digital Product Passport implementation.

Synchronization patterns: Real-time API vs. batch processing

Choosing a synchronization pattern involves two decisions: how data is transferred and when it is processed. An API can support individual updates or larger sets of data retrieved on a schedule. Batch integration can use either files or APIs.

Microsoft’s documentation, for example, distinguishes synchronous OData integration from asynchronous batch data APIs in Dynamics 365 finance and operations apps. Pimcore supports imports triggered manually, on a schedule or through a push endpoint.

REST APIs expose system resources and operations to external applications. GraphQL APIs allow the requesting application to specify which fields it needs. This can be useful on the PIM side: Pimcore Datahub provides a GraphQL API and allows the data exposed through each configuration to be restricted.

Larger environments also use OData interfaces. SAP integrations may additionally involve IDoc and BAPI. Availability depends on the product, version and deployment model. In SAP S/4HANA Cloud Public Edition, communication scenarios define the interfaces available for particular integration purposes.

For file-based exchange, Excel can support data preparation and review, while CSV or XML files can carry the information between systems. The project should define column names, character encoding, date formats, decimal separators and identifier formats. GTINs need to retain every digit, including leading zeros.

The format used to publish the passport is a separate consideration. JSON-LD connects fields with explicitly defined concepts and identifiers. It can support interoperability where the chosen DPP data model uses it. The final format and vocabularies should follow the applicable requirements and the publishing service’s specification.

A mixed approach can work well: basic product data is transferred to PIM periodically, a new batch triggers an update after production approval, and an environmental document is published once its content has been approved by the responsible person.

How to integrate DPP with ERP in 5 steps

Step 1: Data gap audit & ERP attribute mapping

The first task is to identify the products in scope, their data sources and the requirements that apply or are being developed. A useful starting point is one product family representing the company’s typical variants, documentation and processes.

For each attribute, establish the source system, data owner, retrieval method and required update frequency. The audit should also determine whether the available information describes the product at the necessary level: model, batch or individual item.

The audit should produce a data map identifying missing information and the people responsible for completing it. If the ERP material field contains an internal code, the integration needs to connect that code to a material dictionary and the relevant documentation.

At this stage, test the export or retrieval of a representative data set from the ERP version actually in use. This helps identify interface limitations before implementation begins.

Step 2: Implementing PIM as the data aggregation & cleansing layer

The next step is to design the product, material and document models, together with their relationships. This includes controlled vocabularies, unit conversions and rules for resolving inconsistencies between sources.

In the proposed process, a record passes through the following stages:

Data received → checked → completed → approved → ready for publication

Automated checks can identify missing units, unknown material codes, unlinked batches or documents approaching expiration. A task to complete the missing information is assigned to the relevant data owner.

PIM import tools can reduce manual work. Pimcore Data Importer supports formats including CSV, JSON, XML and XLSX, configurable mapping and previews of transformed data. These capabilities require rules that reflect the actual product model.

Step 3: Choosing the right integration method (REST API, ESB, iPaaS)

For DPP ERP integration, the connection method should reflect the number of systems, available interfaces and requirements for keeping data up to date.

For a small number of connections, a dedicated integration module may be appropriate. In a larger organization, an ESB, or enterprise service bus, or an iPaaS, or integration platform as a service, can provide an intermediary layer. Its responsibilities should be defined explicitly: transferring messages, transforming formats, recording errors and retrying failed transfers.

Installing an integration module should include tests covering interrupted connections, repeated delivery of the same record and receipt of an older data version.

The integration design should address duplicate prevention, version control, least-privilege access for technical accounts and responsibility for resolving errors. Retrieval from ERP, approval in PIM and DPP publication should be recorded as separate stages.

The scope of this work affects the project budget. Our separate article provides a detailed breakdown of DPP implementation costs.

Step 4: Serialization and real-time GS1 Digital Link generation

The identification level should follow the requirements applicable to the product. Serialization, which assigns an identifier to each individual item, supports item-level passports. For batch-level passports, the essential relationship is between the product and its batch number.

Under GS1 standards, a GTIN can be combined with a batch/lot number or serial number. An illustrative address using the GS1 Digital Link URI syntax for a batch could look like this:

https://id.example.com/01/09521234000006/10/B2026-001

Here, 01 identifies the GTIN and 10 identifies the batch/lot number. Application Identifier 21 is used for a serial number.

The project should establish which system assigns the identifier, when it is linked to the product and how the resulting address reaches the label printer. Where the production process requires real-time generation, this can happen as a batch or individual item is recorded. Other implementations may generate the address during packing or another controlled process stage.

The finished label also needs to be tested. Scanning the code should open the correct passport, and documentation updates should preserve the relationship with the appropriate batch. The data carrier, its placement and the required identification level follow the applicable rules.

Step 5: Trust services integration (eIDAS) & automated EU Registry sync

The European Commission launched the DPP Registry and its testing environment on 20 July 2026. Registration is available through a user interface and an API, allowing it to become part of the company’s publishing process.

At this stage, the organization needs registry access and appropriate permissions for people and services acting on its behalf. Commission Implementing Regulation (EU) 2026/1778 specifies identity-verification methods linked to eIDAS. For a legal person required to be established in the EU, these include a qualified electronic seal supported by a qualified certificate or a qualified electronic attestation of attributes. The verification method depends on the type of entity.

The DPP service then makes the approved passport available and submits the required registration information. Registry checks include semantic conformity and the appropriate identification level. Following successful verification, the registry returns a registration identifier.

The integration should record passport publication status and registry registration status separately. If registration is rejected, the cause needs to be identified and resolved. The process must also provide for a backup copy and continued passport availability for the required period. ESPR establishes obligations in both areas.

Integrating DPP with major ERP systems (SAP, Dynamics 365, Oracle)

The feasibility of DPP integration with ERP systems depends on access to the required data through supported interfaces or exports. The assessment should cover identifiers, components, batches, documentation and information about changes over time.

SAP, Microsoft Dynamics 365 and Oracle provide different integration mechanisms. The table below summarizes documented options. Their suitability for a DPP project needs to be checked against the actual product, version, enabled modules and configuration.

For SAP S/4HANA, SAP documents APIs for product master data, including descriptions, units of measure and GTIN data. Separate interfaces cover bills of materials and batch records. The integration should select APIs appropriate to the installed edition and release, then confirm the relevant operations and authorizations. 

In Microsoft Dynamics 365 Finance and Supply Chain Management, public-enabled data entities can be accessed through OData in supported deployments. Microsoft also documents data-management package APIs for asynchronous imports and exports. The choice should reflect the deployment model, data volumes and required update frequency. For organizations operating across several legal entities, the integration must also account for company context and access rights.

Microsoft Dynamics 365 Business Central has a separate API model. Microsoft recommends REST API web services for external integrations and supports custom API pages and queries developed in AL. During discovery, the team should confirm which required fields are available through standard endpoints and which need a custom extension.

In an Oracle Fusion Cloud environment, product, component and lot information may be held in SCM applications alongside ERP processes. Oracle documents REST resources for Items Version 2, Item Structures and Inventory Item Lots. Mapping should preserve the relevant item, organization and lot relationships. The available data must be checked against the applications and release used by the company.

In practice, implementing DPP in an ERP environment means configuring the existing systems to supply the data, identifiers and statuses needed to support the passport. Once data extraction is in place, integration acceptance testing should confirm correct relationships, updates and error handling.

Operational benefits: Streamlining data management across the enterprise

ERP integration with DPP provides an opportunity to establish clearer rules for managing product information. Its effects should be measured through everyday data-management activities.

After a document changes, the team should know which products it covers. When an error is identified, it should be clear which system contains the data that needs correcting and who is responsible for the correction. Approved changes should reach the appropriate recipients without repeatedly preparing the same information by hand.

The following metrics can help evaluate the integration:

Data prepared for DPP in ERP and PIM systems can also support e-commerce, B2B catalogs and service operations. Each channel receives the appropriate information through a controlled publication process.

How Tandemite connects ERP, PIM, and DPP into a seamless ecosystem

Tandemite supports product-data organization, PIM data-model design and system integration. Its Product Data X-Ray assessment reviews readiness for DPP, including data availability, links to the relevant products, supporting documentation and gaps in integrations or processes.

An ERP-PIM-DPP project can begin with an assessment of the existing systems and a walkthrough of a typical company process: from a product record or batch data in ERP to an approved passport. This establishes the integration scope, the required PIM changes and the rules for subsequent data updates and quality control.

Before implementation begins, consider how to choose a PIM implementation partner, paying particular attention to experience in data modeling and source-system integration.

Book a free consultation with Tandemite to discuss DPP integration with your ERP system and the scope of a data audit.