A garment exporter in Ludhiana runs SAP Business One. Their PLM holds 400 active material specs. Their PIM holds product descriptions in four languages. Their ERP holds purchase orders, inventory counts, and supplier master data. Somewhere inside these three systems sits every data point the EU Digital Product Passport will ask for: fibre composition, country of origin per processing step, chemical certifications, supplier IDs.
The data exists. It is just not connected. And connecting it is harder than most DPP platforms have planned for.
For a DPP platform, the first milestone that creates real value is not more AI features or a nicer dashboard. It is production-grade connectors running live against enterprise ERP, PLM, and PIM systems. That is the unglamorous foundation everything else sits on.
The data exists. It’s just not the same data.
The DPP problem looks like a data extraction problem. It is not. It is a data translation problem. The source systems speak different languages.
PLM stores what was designed. It tracks engineering BOMs: this jacket uses 80 percent cotton, 20 percent polyester, with zipper specification YKK-5VS. This is the design truth: what the product should be.
ERP stores what was manufactured and shipped. It tracks purchase orders, batch numbers, and what actually arrived at the warehouse. The PO for batch 4521 says conventional cotton, not organic. The shipment record shows the zipper came from a different supplier than the one in the PLM spec. This is the operational truth: what actually happened.
The DPP needs a third thing: the lifecycle truth. A unified, verifiable record that reconciles design intent with operational reality, mapped to reference frameworks like the CIRPASS architecture or GS1’s EPCIS event model. It must answer: where did each material come from? Which processing steps did it go through? What certifications apply, and are they current?
Three systems. Three versions of the truth. The connector’s real job is not moving data. It is reconciling worldviews.
Most of the raw data is already there. The cotton origin sits in the PLM material master. The chemical certifications sit in the ERP’s document management module. The problem is that these systems were never designed to agree with each other. An ERP table called VENDOR_MASTER with 200 custom columns means something different to finance than to compliance. A nested XML structure in the PLM was built for the PLM’s own reporting engine, not for regulatory disclosure.
What “production-grade connector” actually means
A production-grade connector is not a REST endpoint that pulls JSON. It is a system that handles six things the demo version ignores.
1. Schema discovery and mapping. ERP implementations accumulate a decade of custom fields, renamed columns, and repurposed tables. A connector that assumes MATERIAL_MASTER.FIBER_COMPOSITION exists will break on the first real installation.
But here is what matters: schema discovery is not a runtime magic trick. It is an onboarding accelerator. When you first connect to a customer’s SAP instance, automated introspection tells you what you are actually dealing with: the Z-tables, the custom fields, the deviations from vanilla SAP. This saves weeks of manual browsing through SE11 and SE16N. After onboarding, it becomes a validation check: before each release, you verify the schema has not changed in ways that would break the mapping.
The truly hard problem is not discovering that column ZZFASER exists. It is knowing that ZZFASER means “fibre composition” in this customer’s system and not “inspector initials.” That requires a human, or a well-trained mapping layer, because only someone who knows the business can say what a custom field actually represents.
Schema discovery finds the columns. Semantic mapping finds the meaning. The second one is ten times harder.
2. Incremental sync, not full export. A mid-size brand might have 50,000 material records, growing by 200 per season. The connector cannot re-export everything every time a DPP is created. It must track change timestamps, sync only deltas, and handle deletes without corrupting the DPP record chain.
3. Data validation at extraction time. If the PLM says 100 percent organic cotton but the ERP’s purchase order says conventional cotton, the connector must flag the discrepancy before it becomes an EU non-compliance finding. Production-grade means validation rules, not blind passthrough.
4. GS1 standards mapping. The connector must translate internal identifiers: the ERP’s material code, the supplier’s internal ID, into GS1-compliant formats. This involves EPCIS event formatting with proper GS1 identifiers (GTIN, GLN, SGTIN) as defined in the GS1 DPP Provisional Standard. GS1 Digital Link URIs are constructed at the resolver layer, not in the connector itself, but the connector must output the identifiers those URIs resolve from. (For how GS1 Digital Link enables DPP data carriers, see the GS1 Digital Link Resolver post.)
5. Resilience to source system outages. The ERP goes down during month-end closing. The PLM is unreachable during a version upgrade. The PIM’s API rate-limits after 1,000 requests. A production-grade connector queues requests, retries with backoff, and never corrupts a partially written DPP. The demo connector returns a 500 error and stops.
6. Audit trail across systems. Regulators will not just verify the DPP. They will trace the data back to its source system of record. The connector must log every extraction: which system, which record, which fields, at what timestamp, with what validation result. This audit trail is itself auditable.
Beyond the firewall: the Tier-2 cliff
Even a perfect ERP-to-PLM connector solves only the Tier-1 problem. It connects systems inside the brand’s own walls. But the direction of travel in DPP regulation points toward Scope 3 emissions tracing, Product Carbon Footprints, and raw material origin visibility across Tier 2 to Tier N suppliers. The spinning mill, the dye house, the chemical supplier. None of them share your ERP.
PLM systems rarely track beyond direct suppliers. ERP systems store purchasing histories but do not recalculate carbon footprints as materials route through different geographies. A cotton shipment through a Chinese mill has a different carbon profile than the same cotton processed in Turkey. The ERP has the purchase order. It does not have the emissions data.
This means the connector architecture cannot be a closed two-way bridge between PLM and ERP. It must act as an ingestion engine into a federated dataspace: a network where each supply chain actor contributes their own EPCIS events, each in their own format, at their own cadence. Similar federated approaches are emerging for textiles and batteries. (For a detailed look at what data Indian exporters already have and what they are missing, see Indian exporters have 60% of EU DPP data: here is the 40% gap.)
The architecture must handle append-only events from external actors without polluting the internal PLM or ERP core. Each supplier sends what they know. The DPP platform assembles the full picture.
The Tier-2 cliff is where most DPP architectures go quiet. They show a diagram with “supplier data” as a box labeled “TBD.”
Who gets to see what
A DPP is not a single document. A consumer scanning a QR code should see fibre composition and recycling instructions. A customs officer at the EU border needs compliance certificates and proof of origin. A recycler needs disassembly mechanics: data that should never appear on a public QR code.
This means the connector cannot simply dump ERP and PLM data into a public-facing cloud registry. It must feed into a data sovereignty layer that enforces tiered access: one set of fields for the public, another for authorities, another for B2B partners. Each tier gets a different view of the same underlying data. The architecture is a separate concern from the connector itself, but the connector must be built knowing this destination exists. It cannot assume “extract everything, publish everything.”
Batch sync creates compliance risk
Consider a real scenario. A PLM engineer updates a material composition on Tuesday because a supplier shortage forced a substitution. The DPP syncs on a nightly batch. A shipment leaves Tuesday afternoon with Monday night’s data. At the EU border on Thursday, the DPP shows polyamide where the declaration says cotton. The batch shipped with stale data. The brand faces a border rejection.
This is the normal risk of batch integration when changes happen between sync windows. The answer is event-driven integration: when a PLM Engineering Change Order is approved or an ERP goods receipt is posted, an event fires. The connector picks it up, transforms it into an EPCIS event, and appends it to the DPP record. When combined with hash chaining or digital signatures, each new event creates a tamper-evident extension of the previous state.
The three practical patterns remain: event-driven sync (cleanest, requires modern ERP), scheduled batch with change detection (works with any ERP, adds latency), and hybrid with a staging layer (adds infrastructure, removes dependency on source availability). The right choice depends on the source systems. The principle is the same: stale DPP data is a compliance liability.
One design pattern that matters
Whether you are building a DPP platform, integrating one into an existing ERP landscape, or evaluating vendors, one principle separates production architecture from prototypes.
Separation of Concerns. Do not build the DPP registry inside the ERP or the PLM. These are source systems. Their job is to run the business, not to serve regulatory data. Keep them as records of source truth and use an agnostic middleware layer: the connector plus the EPCIS events repository, to compile the digital twin. When the ERP gets upgraded or the PLM gets replaced, the DPP layer should not break.
What happens if this is skipped
A DPP platform that ships without production-grade connectors signs up for one of two outcomes.
Outcome one: the platform signs a brand, but the brand cannot get their ERP data in. The brand’s compliance team becomes a data entry department, re-typing data that already exists in another system. Error rates climb. The brand churns before the regulatory deadline.
Outcome two: the brand hires an external systems integrator to build the missing connector. The integrator discovers the platform’s API is a thin REST wrapper with no schema discovery, no validation, and no resilience patterns. The integration takes six months. It costs more than the platform subscription. The brand leaves anyway.
Both end the same way: the platform loses the customer to a competitor who invested in connectors.
The EU textile DPP deadline is approaching. The delegated acts are expected by mid-2027. Enforcement follows within months, late 2027 at the earliest. The window between delegated act publication and mandatory compliance is the integration window. Teams that understand schema discovery, semantic mapping, multi-tier visibility, and event-driven sync are the ones who will ship production-grade integrations before the compliance window closes. It does not matter whether those teams sit at DPP platform companies, systems integrators, or the brands themselves. Everyone else will be scrambling in 2028.
Coming next: Getting the data out is step one. Where it lands is step two. The next post covers EPCIS events repositories: how they turn raw ERP extracts into interoperable, queryable DPP records that a GS1 resolver, a customs system, or a recycler’s platform can actually use.
