Where Does a Digital Product Passport Actually Fit? Eight Integration Scenarios for Real System Landscapes

You have sat through a DPP webinar. You learned about ESPR timelines, delegated acts, and data requirements. Interesting. But nobody explained how a Digital Product Passport connects to the ERP you have been running for twelve years. Or the PIM your team spent six months configuring. Or the EPDs you paid a consultant EUR 15,000 to produce.

Every DPP conversation starts with regulation. Almost none of them start with your actual system landscape. That is a problem, because the question manufacturers ask first is not “what data do I need?” It is “where does this thing plug in?”

This article answers that question. Eight scenarios, from a company running spreadsheets to a multi-site enterprise with middleware. Each one shows what you already have, what gets added, how data flows, and where the real challenge hides. Find the scenario that looks like your company. That is your starting point.

The DPP Ecosystem: Seven Building Blocks

Before diving into scenarios, seven concepts show up in every integration diagram. You need to understand these before the rest makes sense.

DPP Service Provider. A company that hosts your passport data and makes it accessible to the outside world. Think of it as managed hosting for product passports. Most small and mid-sized manufacturers will use one rather than building their own infrastructure. DPPA is one such provider, built to support all relevant industries. The EU is developing certification rules for these providers to ensure data quality and availability.

EU DPP Registry. A central index where all passports are registered so they can be found. You do not upload your product data here. You register the address where your data lives. It works like DNS for products: the registry knows where to look, but the data stays with you (or your service provider).

Unique Product Identifier. Every product with a DPP needs a unique identifier. This could be a GS1 GTIN, a URL, a proprietary identifier, or another scheme. A URL has an advantage: it doubles as both identifier and address, pointing directly to the passport data. GS1 Digital Link works this way, encoding a GTIN into a web-resolvable URI. But you do not need GS1 for this. Any stable URL that resolves to your passport works as an identifier. The identifier operates at one of three granularity levels: model (one passport per product line), batch (one per production run), or item (one per individual unit). Two things determine which level you need. First, the delegated act for your product category may specify a minimum. Second, and more practically: does anything actually vary between individual units? If every unit uses the same materials from the same origin with the same production process, a model-level or batch-level passport carries the same information as an item-level one. Granularity should match actual data variation, not just regulatory ambition.

Data Carrier. The physical link between a product and its passport. A QR code, Data Matrix, RFID tag, or NFC chip on the product or its packaging. When scanned, it resolves to the passport data. QR codes are expected to dominate, but the right choice depends on your product and environment. A QR code works for a carton of insulation panels. An RFID tag makes more sense inside an industrial battery.

Data Flow Direction. A DPP does not replace any existing system. It reads from them. Your ERP, PIM, EPD tools, and LCA software remain your sources of truth. The DPP layer aggregates data from these sources, formats it according to regulatory requirements, and exposes it through a standardized interface.

Access Control. Not everyone sees the same passport data, but access works in two distinct tiers. The first tier is public. When anyone (a consumer, a curious competitor, a journalist) scans the QR code on a product, they see the published passport: product composition, environmental impact, recycling instructions. This data is open by design. The second tier is authenticated. Market surveillance authorities, recyclers, and supply chain partners who need compliance documentation, test reports, or disassembly guidance must access the service provider’s portal with credentials granted by the manufacturer. They do not get this data by scanning a QR code. They log in. The manufacturer controls who gets access and to which data. The EU’s long-term vision includes centralized authority authentication through the DPP Registry infrastructure, but that mechanism is not yet operational. Today, restricted access runs through the service provider’s portal. When evaluating providers, ask how they handle these two tiers and whether you can control which fields are public vs. restricted.

Decentralized Architecture. There is no central EU database holding your product data. You, or your service provider, host it. The EU registry just indexes it. This is by design. Data sovereignty stays with the manufacturer. You control what is stored, where it is stored, and how it is updated.

The generic flow looks like this:

Every scenario below is a variation of this pattern. The differences are in what sits at the bottom and how data gets up to the service provider.

Scenario 1: The Spreadsheet Manufacturer

Profile: Small manufacturer, 15 to 50 employees. Specialized building products, niche textiles, or artisanal goods. Product data lives in spreadsheets. No PIM. No integrated ERP. Accounting handled in basic software like Xero, QuickBooks, or Tripletex.

What you have today:

• Product specs in Excel or Google Sheets (dimensions, materials, weight)
• Basic accounting software (not a full ERP)
• EPDs as PDF files, if any
• Product photos in a shared folder or cloud drive
• Maybe a basic website with product listings

What gets added:

• DPP Service Provider (the entire DPP layer is outsourced)
• Product identifier assignment
• QR code generation and printing
• Data entry or upload into the service provider’s platform

How data flows:

How you connect to your DPP service provider: Manual data entry in the portal is the simplest path. Type in your product data, upload documents, generate passports. For companies with 50 to 200 products, this works. When volumes grow, export your spreadsheets to CSV or Excel and use the bulk import feature. No API needed, no integration project. If you later adopt an ERP, you can switch to an API connection without losing existing passport data.

The biggest challenge: Data quality. Spreadsheets have no validation rules. Fields are missing, formats are inconsistent, versions conflict. The DPP project forces a cleanup before anything technical happens. Expect to spend more time organizing your data than configuring the service provider.

The key insight: For this company, DPP is not an integration project. It is a data collection and cleanup project. The service provider replaces the need for technical infrastructure. Your job is making sure the data going in is accurate. There is an upside too: a product passport is not limited to regulatory minimums. If you have invested in sustainable sourcing, low-emission production, or circular design, your passport can carry that story. For a small manufacturer competing against larger brands, a well-structured passport becomes a differentiator that was previously hard to communicate.

Scenario 2: The ERP-Centric Manufacturer

Profile: Mid-sized manufacturer, 50 to 200 employees. Construction products (concrete, windows, steel components), industrial goods, or battery components. The ERP is the backbone. Product master data, inventory, orders, and financials all live there. No separate PIM.

What you have today:

• ERP (SAP Business One, Microsoft Dynamics 365 Business Central, Visma Business NXT, or similar)
• EPDs registered with a programme operator (EPD-Norge, IBU, Environdec)
• Product data sheets generated from ERP
• Possibly registered in a national product database (NOBB in Norway, CoBuilder elsewhere)

What gets added:

• DPP Service Provider with ERP integration
• Product identifier assignment (you may already have GTINs)
• QR code integration into your packaging or labeling workflow

This scenario splits into four variants depending on how you prefer to work.

Variant A: ERP pushes data to the service provider

Your ERP exports product data to the service provider’s platform through an API or scheduled file transfer. You manage passports in the service provider’s portal.

How you connect: The service provider’s REST API connects to your ERP through a standard integration point. Configure the API credentials, map your fields to DPP fields, and set a sync schedule. Daily or weekly sync is enough for most manufacturers. EPD data is typically imported separately, either through a digital format (ISO 22057 JSON) or manual upload.

Best for: Companies comfortable working in two systems. Your team uses the ERP for daily operations and the service provider’s portal for passport management. Clean separation of concerns.

Variant B: Extension module inside the ERP

A DPP module installs directly into your ERP as a native add-on. It reads your product master data, presents DPP-specific fields alongside your existing product cards, and syncs with the service provider’s cloud infrastructure in the background.

How you connect: The extension module is installed into your ERP like any other add-on. For Microsoft Dynamics 365, this means a native app from the marketplace. The module reads your product master data and handles the sync with the service provider’s cloud. Your team never leaves the ERP. Passport creation, data enrichment, and QR code generation all happen from the interface they already know.

Best for: Companies that want one system, not two. If your team resists switching between platforms, this removes that friction. The tradeoff is that you depend on a native add-on being available for your specific ERP.

Variant C: External extension pulling from the ERP API

A DPP extension runs as a separate service outside your ERP. It connects to your ERP through the ERP’s own API, pulls product data on a schedule, and syncs it with the service provider’s cloud.

How you connect: The extension connects to your ERP through its API (e.g., D365 Business Central OData API, SAP B1 Service Layer). It pulls product data, but you manage passport-specific tasks in the extension’s own interface rather than inside the ERP. This approach works for any ERP that exposes an API, even if no native add-on exists for it.

Best for: Companies whose ERP lacks a native DPP add-on, or whose IT policy prefers external integrations over installing third-party modules into core systems. You get automated data flow without modifying your ERP.

Variant D: Middleware pulls from ERP, pushes to service provider

A separate integration layer (custom-built, iPaaS, or third-party middleware) sits between your ERP and the DPP service provider. It pulls data from the ERP’s API and pushes it to the service provider’s API.

How you connect: The middleware connects to both sides through their APIs. Tools like MuleSoft, Azure Logic Apps, Make, or a custom script handle the mapping and scheduling. Your team controls the transformation logic. Neither the ERP nor the service provider needs to know about each other directly.

Best for: Companies that already use integration middleware for other data flows (e-commerce, EDI, warehouse). Adding DPP becomes one more connector in an existing integration layer. Also useful when neither a native ERP add-on nor a service provider extension exists for your specific ERP.

Shared across all variants

The biggest challenge: Data completeness. Your ERP has technical specs and logistics data. It usually lacks environmental data, substances of concern, and end-of-life instructions. These gaps require new data collection processes, not new software. Identifying which DPP-required fields exist in your ERP and which do not, is the real work. This is true regardless of variant.

The key insight: ERP integrations can be cumbersome and costly, especially with older systems or limited API access. That is exactly why four variants exist. Variant A requires a basic export or API call from the ERP but no modifications to it. Variants C and D read from the ERP’s API without installing anything inside it. Variant B requires the deepest ERP involvement, with a module installed directly into the system. Match the variant to your ERP reality, your team’s capacity, and your budget. And regardless of which variant you pick, the data gap analysis is unavoidable.

Scenario 3: The PIM-Driven Brand

Profile: Consumer-facing brand, 30 to 200 employees. Fashion, outdoor textiles, or building products with a strong retail presence. Invested in a PIM because products sell through multiple channels (own webshop, marketplaces, retail chains). Product data is structured and enriched.

What you have today:

• PIM (Akeneo, Bluestone PIM, inRiver, Salsify, or Pimcore)
• ERP for operations and finance
• E-commerce platform (Shopify, WooCommerce, Adobe Commerce, or custom)
• Possibly PLM for product design (in textiles)
• Sustainability certifications (GRS, OEKO-TEX, EU Ecolabel) as PDF documents

What gets added:

• DPP Service Provider with PIM integration
• Certification data structured into data fields (not just PDF scans)
• Supply chain data collection for upstream traceability (especially textiles)

How data flows:

How you connect to your DPP service provider: The same integration patterns from Scenario 2 apply here, with the PIM replacing the ERP as the primary data source. The PIM pushes via a built-in DPP connector (like Variant A), a service provider extension pulls from the PIM’s API (like Variant C), or middleware sits between the two (like Variant D). PIM systems are built for outbound data syndication. Your PIM team has done this before for e-commerce feeds. DPP is one more channel.

The biggest challenge: Supply chain data. Your PIM has your product data, structured and enriched. But DPP also requires upstream information: where raw materials came from, under what conditions they were produced. For textiles, this means reaching into supply chains with five to eight processing stages across multiple countries. The PIM-to-DPP connection is easy. Getting supplier data into PIM is the hard part.

The key insight: Companies with a PIM are already ahead. Product data discipline translates directly to DPP readiness. The gap is supply chain transparency, not product data management.

Scenario 4: The Multi-Source Reality

Profile: Manufacturer, 50 to 300 employees. Any industry. Has an ERP but it only covers part of the picture. Product specs live in the ERP. Environmental data lives in an LCA tool or an external consultant’s report. Safety data sheets are PDFs. Certifications are scanned documents or emails from suppliers. Some product data lives in a PIM, some in Excel files maintained by the product manager. No single system has everything the DPP needs.

This is the most common real-world starting point. The previous scenarios each have a dominant system. Most companies do not.

What you have today:

• ERP for production, logistics, and basic product data
• Spreadsheets or PDFs for environmental data (LCA results, carbon calculations)
• Safety Data Sheets (SDS) as PDFs from suppliers
• Certifications stored as scanned documents, emails, or a shared drive folder
• Some product data in a PIM, some in the ERP, some in both (with discrepancies)
• Possibly an LCA tool (SimaPro, OneClickLCA, openLCA) used for specific projects, not all products

What gets added:

• DPP Service Provider as the convergence point for all sources
• Data mapping exercise: which DPP field comes from which system?
• Structured data extraction from unstructured sources (PDFs, scanned certificates)
• Source-of-truth decisions per data field

How data flows:

How you connect to your DPP service provider: There is no single integration. This scenario uses multiple methods simultaneously. The ERP connects through an API or extension (Scenario 2 variants). Environmental data from LCA tools may come through a digital format (JSON or XML) or manual import. Certifications and safety data sheets get uploaded as documents and mapped to the right products. Spreadsheets fill remaining gaps through CSV import. The service provider’s portal becomes the place where all these streams converge into a complete passport.

The biggest challenge: Knowing what you have, where it lives, and which system masters it. Before any integration work begins, you need a data map: every DPP-required field, which system (if any) holds it, in what format, and how current it is. Many companies discover that the same data exists in multiple systems with conflicting values. Product attributes get synced between ERP and PIM, material data lives in both the product sheet and the certification, environmental figures appear in the LCA report and the sales documentation. Defining which system is the master for each attribute is the real project. Without that, your DPP inherits the conflicts instead of resolving them.

The key insight: Do not wait until every source is perfectly connected before creating your first passport. Start with what you can collect today, even if that means manual entry and PDF uploads for some fields. Automate the high-volume, frequently changing data first (ERP product specs, batch data). Move the static, rarely changing data (certifications, LCA results) to structured formats over time. A DPP with some manually entered fields is still a valid, compliant passport.

Scenario 5: The Manufacturer with EPDs and a Product Registry

Profile: Building product manufacturer, 50 to 500 employees. Mature product data infrastructure. Has EPDs, is registered in a national or regional product database, holds a GS1 membership. This is the “best prepared” construction scenario.

What you have today:

• ERP (SAP, Microsoft Dynamics, Visma, or similar)
• Registration in a product database: NOBB (Norway), CoBuilder (multi-country), ETIM International portal, or a national equivalent
• EPDs registered with a programme operator (some available in digital ISO 22057 format)
• GS1 membership with GTINs assigned to products
• LCA tool used during EPD creation (SimaPro, OneClickLCA, GaBi/Sphera, openLCA)
• Possibly BIM object library

What gets added:

• DPP Service Provider that can ingest from multiple existing sources
• Mapping layer: product registry fields to DPP fields, EPD environmental data to DPP sections
• Gap-filling for circularity data (recycled content, end-of-life instructions, repair information)

How data flows:

How you connect to your DPP service provider: This scenario has the most data sources but also the most structured data. The service provider connects to your product registry’s API (many of these registries already offer well-documented REST APIs with OAuth 2.0 authentication). EPD data comes in through digital formats or programme operator APIs. Your ERP supplements with batch and logistics data. Because your identifiers are already assigned through GS1, the mapping is direct. The service provider’s REST API ties it all together. Alternatively, if your ERP is the central hub, use the ERP integration module and import registry and EPD data into the ERP first.

The biggest challenge: Data orchestration. Your data exists across four or five systems. No single system has everything. The service provider needs to merge product specs from the registry with environmental data from your EPD with production data from your ERP, validate consistency, and flag conflicts. If the material composition in your product registry does not match what the EPD declares, which is correct? Defining the source of truth per data field is the real integration decision.

The key insight: This company has 70 to 80 percent of its DPP data already digital and structured. But “having data” and “having it connected” are different problems. The project is about building bridges between existing islands, not creating new data.

Scenario 6: The Textile Brand with a Multi-Tier Supply Chain

Profile: Textile or apparel brand, 50 to 300 employees. Sells in EU markets. Has sustainability commitments and certifications. The defining characteristic: a long, multi-tier supply chain running from raw fiber through spinning, weaving or knitting, dyeing, cutting, and assembly.

What you have today:

• PLM for product design and development (Centric PLM, Lectra, or simpler tools)
• ERP (SAP Fashion Management, Microsoft Dynamics 365, or similar)
• Possibly a traceability platform (TextileGenesis, TrusTrace, Retraced)
• Textile Exchange certifications (GRS, OCS, RCS) or OEKO-TEX
• Supplier management system or spreadsheets for vendor data

What gets added:

• DPP Service Provider
• Supply chain data aggregation (if no traceability platform exists, this is a major new requirement)
• Mapping from certification data (e.g. Content Claim Standard) to DPP fields

How data flows:

How you connect to your DPP service provider: If you have a traceability platform, it becomes the primary data bridge. The platform already collects upstream data and structures it. The service provider’s API pulls from the traceability platform, your PLM, and your ERP. If you do not have a traceability platform, the service provider’s portal with Excel import becomes the starting point for supply chain data: collect what you can from suppliers, structure it in a template, and upload. As supplier data collection matures, you can move to API-based integration.

The biggest challenge: Getting supplier data. A typical garment passes through five to eight processing stages across three to five countries. Each stage adds information the DPP needs: fiber origin, chemical processing, labor conditions, certifications. If a traceability platform is already in place, the service provider can connect to it. If not, you face a data collection project that spans your entire supply chain. The internal PLM-to-service-provider connection might take weeks. Getting Tier 3 and Tier 4 suppliers to provide structured data could take a year.

The key insight: For textiles, the DPP integration challenge is not your internal systems. It is the supply chain. The Textile Exchange Materials Matter Standard (replacing GRS, OCS, RCS from late 2026) will create a unified certification framework that partially satisfies DPP traceability requirements. If you are already certified, you have existing chain-of-custody data to build on.

Scenario 7: The Battery Manufacturer

Profile: Battery cell or pack manufacturer, or component supplier. 100 to 500 employees. High digital maturity. Manufacturing Execution Systems already track production data at cell level. ERP deeply integrated with production. The defining characteristic: you already collect most DPP-required data for quality and safety reasons.

What you have today:

• MES tracking cell chemistry, production parameters, test results per unit
• ERP (SAP S/4HANA, Oracle) integrated with production
• Quality Management System (QMS) with safety certifications
• Carbon footprint calculation tools (Scope 1, 2, and 3)
• Possibly participating in GBA Battery Passport pilots

What gets added:

• DPP Service Provider or direct integration with EU Battery Passport infrastructure
• Connection to GBA Gateway (UNTP-based) if participating in the alliance
• Carbon footprint calculation aligned with EU Battery Regulation methodology
• Unique identifier at item level (individual battery unit, not model)

How data flows:

How you connect to your DPP service provider: Batteries demand API-first integration. Item-level passports for every unit produced means manual entry or Excel import is not viable at scale. Your MES exports production data through its API. Your ERP supplements with supply chain data. The service provider’s REST API ingests both streams, creates individual passports, and registers them. For manufacturers in the GBA ecosystem, the GBA Gateway provides an additional integration layer using the UN Transparency Protocol.

The biggest challenge: Granularity and volume. Battery DPPs are item-level. Every individual battery needs its own passport with specific production data, test results, and state-of-health tracking. If you produce thousands of cells per day, that means thousands of passport records created daily. The integration must handle high-volume, real-time data flows from MES to the service provider. A secondary challenge: the EU Battery Regulation specifies how carbon footprint must be calculated (specific methodology for Scope 1, 2, and 3 with defined boundaries). Your existing calculations may not align with the required methodology.

The key insight: Battery manufacturers have the data. The challenge is volume and precision, not data gaps. System integration is more about performance engineering and scaling (handling millions of individual passports) than about connecting systems that do not talk to each other.

Scenario 8: The Multi-Site Enterprise

Profile: Large manufacturer, 500+ employees. Multiple factories, multiple product lines, possibly crossing industry boundaries. A construction group that also makes industrial components. A conglomerate with brands across segments. May already have a central data platform or data lake.

What you have today:

• Multiple ERP instances (possibly different vendors per business unit)
• Central or federated PIM or Master Data Management (MDM) platform
• Multiple product registries per division
• Enterprise integration middleware (MuleSoft, Azure Integration Services, SAP Integration Suite)
• Dedicated IT team with integration experience

What gets added:

• DPP Service Provider or an in-house DPP layer for large enterprises
• Integration middleware configuration for DPP data flows
• Data governance layer: which system is the source of truth for each DPP field?
• Multi-regulation mapping if the same product falls under both ESPR and sector-specific rules

How data flows:

How you connect to your DPP service provider: The enterprise already has integration infrastructure. The service provider’s REST API becomes another endpoint in the middleware layer. The middleware handles data transformation, field mapping, and routing from each business unit’s systems to the DPP layer. If the enterprise prefers to build its own frontend, some service providers (e.g., DPPA) offer a headless mode: you use their API and infrastructure for passport storage, resolution, and registry compliance, but present the data through your own portal or internal tools. The technical pattern is familiar territory for enterprise IT teams. What makes this scenario different is not the plumbing. It is the governance.

The biggest challenge: Data ownership. When multiple systems across multiple business units all contain product data, the fundamental question is: who owns the truth for each data field? The material composition in the ERP does not match the PIM. The environmental data from one factory uses a different methodology than another. DPP forces this into the open because the passport must present a single, consistent view. Without clear data ownership rules, the integration project becomes a political project.

The key insight: For enterprises, DPP is often the forcing function for the master data management project they have been postponing. The technical integration is solvable with existing middleware. The organizational alignment is the real project.

Find Your Scenario

Scenario	Industry	Size	Integration Effort	Biggest Gap
1. Spreadsheet manufacturer	Any	Under 50	Low (manual or CSV to portal)	Data quality
2. ERP-centric	Construction, industrial	50-200	Medium (one API or native module)	Environmental data gaps
3. PIM-driven brand	Textiles, retail	30-200	Medium (PIM is ready)	Supply chain transparency
4. Multi-source reality	Any	50-300	Medium (many small connections)	Knowing what you have and where
5. EPD + product registry	Construction	50-500	Medium (data exists, bridges needed)	Data orchestration
6. Textile supply chain	Textiles	50-300	High (supply chain is the project)	Tier 3-4 supplier data
7. Battery manufacturer	Batteries	100-500	Medium-High (item-level scale)	Volume and methodology
8. Multi-site enterprise	Any	500+	High (governance, not tech)	Data ownership

Most companies are a blend. You might recognize elements from two or three scenarios. That is normal. Scenario 4 might be your starting point even if your industry matches a later scenario. Identify your primary pattern and your secondary challenges. The integration path follows from there.

How Much Time Do You Have?

The timeline depends on your product category. Delegated acts are published per category, and each specifies when DPP compliance becomes mandatory. The EU DPP Registry itself is required to be operational by July 2026. Here is the current schedule based on the ESPR Working Plan 2025-2030 (adopted April 2025) and the Battery Regulation:

Product Category	Regulation	Delegated Act	DPP Mandatory (est.)
Batteries (>2kWh, EV, LMT)	Battery Regulation	Published 2024	Feb 2027
Iron and Steel	ESPR	2026	~2028
Textiles and Apparel	ESPR	2027	~2029
Tyres	ESPR	2027	~2029
Furniture	ESPR	2028	~2030
Aluminium	ESPR	2028	~2030
Mattresses	ESPR	2029	~2031
Construction products	CPR (2024/3110)	CPR Working Plan 2026-2029	~2028-2029

Categories not yet in the ESPR Working Plan but under study: detergents, cosmetics, paints, lubricants, chemicals, footwear. These may be added after the 2028 mid-term review.

A delegated act typically includes an 18-month transition period before its requirements become mandatory. The “DPP Mandatory” column reflects this.

The pattern is clear: batteries are first, iron and steel follow, then textiles and tyres. If you are in batteries, you are already in implementation mode. If you are in textiles or construction, you have time to prepare, but not as much as you think. A data audit, pilot project, and service provider evaluation take six to twelve months in practice. Starting in 2027 for a 2028 deadline leaves little margin.

Where To Start

The timeline table above may give you a false sense of comfort. Textiles in 2029. Construction in 2028. That feels far away. It is not. Companies that went through battery passport pilots report that the technical integration was the easy part. The hard part was the data work: auditing systems, collecting missing fields, aligning supplier data, resolving conflicting sources. That takes time. Companies that start twelve months before a deadline end up rushing. Companies that start now get to learn, iterate, and fix problems while the stakes are low.

Our strong recommendation: DO NOT WAIT. Start with these three steps.

Map your data landscape. List every system that holds product data. For each, note what DPP-relevant fields it contains. Materials, dimensions, weight, environmental data, certifications, supplier information, end-of-life instructions. This exercise takes an afternoon and tells you exactly where you stand.

Check your product identifier status. Do you have GTINs or other structured product identifiers? Are they at the right granularity (model vs. batch vs. item) for your product category? If you do not have structured identifiers, start the process. Whether through GS1 or another scheme, having unique, resolvable identifiers is a prerequisite for any DPP approach.

Pick one product line for a pilot. Do not try to create passports for your entire catalog at once. Choose one product line, ideally one where you have the most complete data, and work through the integration for that line. The patterns you discover will apply to everything else. A single pilot teaches more than six months of planning.

What Should You Budget For?

Cost depends on your scenario more than your industry. Here are rough ranges to help you frame a budget conversation. These are not quotes. They are order-of-magnitude indicators based on what integration projects of similar scope typically cost.

Approach	Typical Cost Range	What Drives Cost
Manual portal entry	Service provider subscription only	Your team’s time for data entry
CSV/Excel import	Service provider subscription only	Data cleanup effort before import
API integration (Variant A)	EUR 5,000-20,000 setup + subscription	Field mapping, ERP consultant hours, testing
ERP add-on (Variant B)	EUR 2,000-10,000 setup + subscription	Module licensing, configuration, training
External extension (Variant C)	EUR 5,000-15,000 setup + subscription	API configuration, field mapping
Middleware (Variant D)	EUR 10,000-30,000 setup + subscription	Middleware licensing, connector development, multiple source mapping
Enterprise / headless	EUR 20,000-50,000+ setup + subscription	Custom development, governance design, multi-system orchestration

The biggest cost for most companies is not the integration itself. It is the data work: auditing what you have, collecting what you are missing (especially from suppliers), cleaning inconsistencies, and defining master data ownership. Budget time for that separately. A realistic pilot for a mid-size manufacturer (one product line, one integration path) typically takes three to six months from kickoff to first live passport.

Patterns That Apply Everywhere

Across all eight scenarios, the same truths keep showing up.

DPP replaces nothing. It is an additional layer that reads from your existing systems. No system gets decommissioned because of a product passport. Your ERP stays. Your PIM stays. Your EPD programme stays. DPP sits on top.

The hardest part is rarely technical. API connections, data exports, and QR code generation are solved problems. Data quality, data governance, and supply chain data collection are the real challenges. Every company that starts with a technology evaluation and postpones the data audit ends up circling back.

Start with a data audit, not a software purchase. Before evaluating DPP service providers, map which DPP-required fields you already have, where they live, and what is missing. That map determines your integration effort, your timeline, and the right approach for your company.

If you already have product identifiers, you have a head start. GS1 GTINs, proprietary article numbers, or industry-specific identifiers can all serve as the foundation. You do not necessarily need to adopt a new identification scheme. Check what the delegated act for your product category requires, and build from what you have.

Batch-level is enough for most products. Ask yourself: does anything actually change between individual units? If every unit of a product uses the same materials, the same suppliers, the same production line, then an item-level passport just duplicates the same data thousands of times. Batch-level or even model-level carries the same information with far less overhead. Batteries are the exception because cell chemistry, test results, and state-of-health genuinely vary per unit. For most construction and textile products, batch-level is where the data variation starts.

A passport can carry more than the regulation requires. The delegated act defines the minimum data set. But nothing stops you from adding information that matters to your customers: sustainability certifications, sourcing transparency, carbon reduction efforts, repair guides, recycling instructions. For companies that have invested in responsible production, DPP becomes a channel to communicate that value in a structured, verifiable way. Buyers increasingly want this. Your passport can deliver it.

Passports are living records. Going live is not the finish line. Materials change, suppliers switch origins, certifications expire, EPDs get updated, formulations are revised. Your passport data needs to reflect these changes. Think about who owns the update process: when a supplier changes, who updates the passport? When an EPD expires, who triggers the renewal? If you use an API integration, updates can flow automatically when source data changes. If you use manual entry, you need a review cycle. Build this into your process from day one, not as an afterthought.

Integration methods scale with you. Start with manual portal entry or Excel import. Move to API integration when volumes justify it. Adopt a native ERP or PIM module when one is available. The right method matches your current digital maturity, not your aspirational one.