A European buyer asks a China-linked supplier whether it is “DPP-ready.” The supplier answers by showing a QR code, a product-data platform, or a spreadsheet with material fields. Everyone in the call feels that a concrete object has appeared. That is precisely why the answer can be dangerous.
The EU Digital Product Passport is not a universal QR-code project. Under the Ecodesign for Sustainable Products Regulation (ESPR), a product needs a passport when an applicable product-specific rule makes one available as an information requirement; the passport then has to meet that rule and the framework’s essential requirements. The regulation itself matters more than a supplier’s label design. A code may become part of a future passport. It does not decide whether the product is in scope, who is responsible for the information, which data points apply, what access must be granted, or whether the information is accurate.
That distinction is newly practical. The European Commission’s Digital Product Passport Registry is operating, but it is an indexing and registration layer rather than a warehouse for every supplier document. The Commission says the Registry handles unique identifiers, registration data and high-level metadata while detailed product data remains decentralised under the relevant economic operator or service provider. Its Registry guidance makes the boundary unusually clear: registration does not make the factory’s evidence trail somebody else’s problem.
For a supplier in China, the useful question is therefore not, “Which DPP platform should we buy?” It is: Can we hand a named EU operator a controlled, updateable product-evidence file when the applicable rule asks for it? That is a much harder question. It involves factory identity, model and batch scope, bill-of-materials lineage, documents behind claims, user access, data corrections, and an agreement about who is allowed to change what. It also works across future product groups more reliably than a premature attempt to predict a final data template.
This article offers a bounded readiness model. It is designed for a buyer, brand, importer, marketplace operator or sourcing team working with a Chinese factory. It does not declare any product compliant, supply legal advice, or replace a product-specific EU act. Its aim is simpler: make it possible to distinguish meaningful preparation from an attractive but unsupported “DPP-ready” claim.
Source file: what this article can and cannot establish
The legal starting point is Regulation (EU) 2024/1781, the ESPR framework. It says that, where the applicable delegated act requires it, products can be placed on the market or put into service only if a Digital Product Passport is available. It also describes core characteristics such as a persistent unique identifier connected through a data carrier, and data that is accurate, complete, up to date, open-standard based and interoperable as appropriate. Those framework requirements are important. They are not a published universal field list for every product a Chinese supplier might make.
For the operational boundary, this article uses the Commission’s DPP Registry documentation and its 20 July 2026 Registry launch notice. The Commission describes the Registry as an EU-level index and explains that the detailed passport information follows a decentralised approach. That matters because a supplier can mistakenly assume that a registration step transfers the obligation to preserve source documents, model changes or product data to the Registry. It does not.
For timing, the Commission’s Digital Product Passport timeline records the Registry’s operation on 20 July 2026 and identifies 18 February 2027 as a milestone for certain batteries. It also says that, after ESPR delegated acts are adopted, economic operators have a transition period of at least 18 months. The same page calls the broader timetable indicative and subject to publication requirements. The calendar is useful for sequencing work; it is not a licence to tell every customer that a given product has the same deadline.
Finally, the article uses GS1’s DPP provisional-application notice only for a narrow technical point: identifier and data-carrier standards can help an organisation prepare the retrieval layer. They do not themselves determine legal conformity. The six-file model below is an editorial synthesis of those boundaries. It is not an EU template, a certificate, or a substitute for product-specific legal review.
For the battery-specific route, read EU Battery Passport: The China Supplier File. This is a different job: a reusable handoff for product groups whose exact EU passport requirements may arrive on different schedules.
Quick answer: prepare the evidence system, not a compliance slogan
| Question from a buyer or importer | A useful answer | An answer that should make you pause |
|---|---|---|
| “Does this product need a DPP now?” | “We have identified the applicable product rule and the responsible EU operator.” | “All products need QR codes now.” |
| “Is the EU Registry the product dossier?” | “No. It indexes registration information; we control the underlying evidence and access.” | “We will upload everything to the Registry.” |
| “Can the factory create the code?” | “Yes, and we can tie it to a controlled identity record and change history.” | “The code proves the product is compliant.” |
| “What happens when material or model information changes?” | “A named owner approves the change, preserves the old version and tells the operator.” | “We will update the spreadsheet.” |
| “Who is accountable in Europe?” | “The agreement names the economic operator and separates supplier evidence from legal placement duties.” | “The factory will handle EU compliance.” |
| “When are we ready?” | “When scope, evidence ownership, access, updates and handoff are testable on a real product family.” | “When the dashboard is live.” |
For teams used to factory sourcing, this should feel familiar. A supplier may show an attractive inspection certificate, a material list or a line drawing. None is useless. Each is narrow. The buyer still has to ask whether the document belongs to the same legal manufacturer, product variant, time period, order and claim now being made. The DPP raises the value of doing that discipline consistently, because product information is intended to be accessible and reusable across a longer life cycle.
The DPP is a conditional market rule, not a universal QR-code project
The first failure happens before any data is collected. A team sees “Digital Product Passport” and treats it as a single new border requirement for everything sold from China into Europe. That is too broad. The ESPR creates a framework for product-specific ecodesign requirements; the DPP becomes an operative product condition through applicable delegated acts and related EU law. The regulation’s design is deliberately more structured than a single code on a carton.
This has a surprisingly useful sourcing consequence: scope comes before data. Before asking a factory for a passport, write down the object that might need one. Is it a product model, a batch, an individual item, a component, a battery pack, a finished kit, or a product with interchangeable accessories? Which company manufactures it? Which company places it on the EU market? Is the object sold through a marketplace, an importer, a distributor, or a brand’s own EU entity? Which legal instrument is thought to apply, and has the team saved the version and date it is relying on?
These are not bureaucratic warm-ups. They control whether later evidence can be joined. If a material declaration refers to one factory’s internal item number while a purchaser uses a customer SKU and an EU operator uses a marketplace listing identifier, a future code can retrieve a record without proving that all three describe the same product. The work starts by making the identity chain explicit.
The framework also makes a broader point that a buyer should preserve in commercial conversations. A DPP has to be based on information that is accurate, complete and up to date when the requirement applies. “Accurate” is not a graphic-design property. It means a supplier needs a way to know the difference between a current bill of materials and an old one; between a declared factory and a subcontractor; between a controlled document and a sales attachment; and between a verified source fact and a marketing phrase.
That is why a supplier should never promise a universal field set in advance. A common core is useful: product identifiers, variant relationship, manufacturing and evidence ownership, material data source, document reference, update time and responsible person. But the applicable product rule may determine the actual data points, the level of the passport, access rights, placement of the carrier, who can create or update data, and how long information must remain available. A generic implementation can be preparation. It cannot erase those unanswered questions.
A better first meeting with a supplier
Replace the question “Do you have DPP?” with five smaller questions:
- What exact product family and variant is this answer about?
- Which EU rule and responsible market operator do you believe are relevant?
- Which source documents support the current product statements?
- Who can change each field, and how will an old version remain traceable?
- How will the supplier hand the operator a usable record if the operator uses a different system?
If the answer begins with a platform demonstration, bring it back to these five questions. A platform is a possible implementation choice. It is not the object of verification.
The Registry is an index, not your supplier dossier
The second failure is to treat the EU Registry as if it will solve evidence management by itself. The Commission’s current description is more limited and more useful. The Registry is intended to store unique identifiers, registration data and high-level metadata, while the detailed information contained in a passport follows a decentralised model. Relevant economic operators retain responsibility for that product information, directly or through an authorised DPP service provider. The Registry page also describes enrolment, technical documentation and a testing environment.
An index is valuable. It can make it easier to find the controlled record associated with a product and to support regulatory or customs checks where the applicable law provides for them. It can create a common reference point across different systems. But an index cannot decide whether the source record is reliable. Think of it as a library catalogue. A catalogue entry can point to a book. It cannot make an incomplete book complete, resolve contradictory editions, or tell you whether someone quietly replaced a chapter without recording the change.
For a China-linked supplier, that distinction changes the data architecture. The factory may hold technical files, component declarations, process information, test reports, product photos and packaging proofs. An EU importer or brand may hold the market placement decision, language versions, commercial presentation, customer documentation and regulatory contact. A DPP service provider may host or transmit structured data. These parties can all participate. They should not be allowed to silently overwrite each other’s responsibilities.
The immediate decision is therefore not “where will the information live?” It is “who owns each evidence object, who can edit it, who approves it, and who must receive notice?” A responsible sourcing agreement can answer those questions without pretending to determine statutory liability:
- The factory owns and maintains its product identity and production-side evidence.
- The buyer or brand owns the commercial configuration and accepts changes that alter the ordered product.
- The named EU economic operator is responsible for the market-facing legal decision within its role.
- A service provider may host, format or expose data, but should not be treated as the originator of a claim it did not verify.
- Every material change needs a timestamp, reason, old-value reference and named approver.
This is also where a factory’s export maturity becomes visible. A supplier may be excellent at making a product but not at carrying an evidence record across different customers. That is not an accusation. It is a capability gap that needs a plan. If the supplier can only issue one all-purpose PDF, cannot identify the model revision behind it, or cannot show which team controls the document, it is not yet ready for an information system that depends on repeatable retrieval and updates.
Use the timeline to sequence work, not to invent deadlines
The DPP calendar creates urgency, but it should create the right kind. The Commission says the Registry became operational on 20 July 2026. Its public timeline lists a first implementation deadline on 18 February 2027 for certain large batteries, including EV, light-means-of-transport and industrial batteries, and says that operators generally have at least 18 months after ESPR delegated acts are adopted. It also identifies an indicative sequence for other groups such as iron and steel, textiles, aluminium, tyres, furniture, ICT products and energy-related products. The Commission’s timeline should be read with the page’s own warning that publication requirements can change the sequence.
The right response is neither “wait until the last rule is published” nor “tell every customer the deadline has arrived.” It is to divide work into three horizons.
Horizon one: capability that is useful even if a product rule changes. This includes product identity, revision control, supplier and component mapping, document naming, source retention, and a handoff method that a buyer can read. No future act is likely to make those capabilities less useful.
Horizon two: data that may be needed but requires controlled collection. This includes material composition, recycled-content claims, repairability information, environmental statements, chemical or safety evidence, manufacturing location detail, and product-life documentation. A supplier can map where these facts come from, who can verify them and how often they change, without guessing that every field will apply to every product.
Horizon three: data, interface and access choices that must wait for the applicable rule and commercial route. This includes the final data points, model/batch/item granularity, carrier placement, public versus restricted access, mandatory language presentation, registration workflow and the precise obligations of the EU operator. Prematurely locking these can create expensive rework.
The most useful planning question is not “How close is the deadline?” It is “Which of our current records would be hardest to reconstruct after a model change?” Those records deserve attention first. They normally include component substitutions, source documents for material claims, safety or conformity records, and the internal approval trail that confirms a document belongs to the current product.
Why the battery timeline should not become every supplier’s timeline
The DPP framework is often discussed through batteries because they have a clear and prominent implementation path. That is helpful for learning, but it can produce a bad shortcut: importing the battery schedule, access model or data list into a toy, furniture, textile, tool or electronics conversation. A buyer should resist that shortcut.
The right comparison is structural, not literal. Battery work shows that a passport can require information to remain connected across a value chain and be accessible to different actors. It does not mean another product group will use the same fields, same object level, same evidentiary source, same timing or same commercial responsibility. A China supplier that has learned to preserve evidence continuity from battery projects may be better prepared. It is not automatically compliant for another category.
That distinction is especially relevant for complex, multi-component goods. A product can change because a casing supplier is replaced, a charger is revised, an accessory is added, a packaging instruction is updated or a software version changes. The problem is not simply data volume. It is whether the record can say which version changed, which claim it affects, who approved it and which customer or operator must receive the change. This is the kind of operational maturity a buyer can test before a legal deadline is settled.
A code can locate evidence; it cannot create it
The physical data carrier is the most visible part of a DPP. It may be a barcode, a two-dimensional symbol or another automatic-identification medium, depending on the applicable rules. That visibility encourages a natural but false inference: if the product has a scanable code and a web page, the passport must exist.
GS1’s current provisional material is useful because it describes identifier and data-carrier work as preparation for regulatory DPP requirements. It can help a company think about how an identifier will be represented consistently in a supply chain. It cannot determine the completeness or legal sufficiency of the underlying product record. GS1’s notice is a preparation reference, not a certificate.
The safest mental model is:
> The code is an address. The passport is the controlled information reached at that address. The compliance decision depends on the applicable rule and the truth of the information.
An address is still useful. It can connect a product, package or accompanying documentation to an identifier. It can reduce ambiguity at handoff. It can make it easier for a buyer, repairer, customer or authority to retrieve the version of a record they are allowed to see. But it cannot answer questions that were never captured:
- Does this identifier refer to a model, batch, unit or marketing bundle?
- Was this component present in the product when the record was created?
- Is the material statement the supplier’s own declaration, an upstream declaration or an independently verified result?
- Has the operator been told about a substitution?
- Which users are entitled to see which data?
- Does the visible page reflect the current version or an old cached record?
If a supplier cannot answer those questions, adding a better QR code makes the uncertainty more convenient to retrieve. It does not remove it.
Build the file before you build the interface
The most durable readiness work is a supplier-to-operator handoff file. It does not need to imitate a future EU schema. It needs to preserve the relationships that future schemas and customers will ask the organisation to express. The following six files are an editorial model for that work.
1. Identity file: name the object before naming its attributes
The identity file connects all the names one product may have. At a minimum, it should record the manufacturer’s legal entity, factory location where relevant, internal item number, customer SKU, model designation, revision, product-family relationship, production lot or serial convention if one exists, and the person or team allowed to approve identity changes.
The crucial question is granularity. A file that says “Model X” is not enough if Model X exists with several battery capacities, plug versions, charger revisions, material options, firmware versions or market bundles. The team does not have to predict whether a future act will require model, batch or item-level data. It does need to know which distinction is meaningful in its own operation.
Ask the factory to demonstrate the identity file using one recent product change. Can it show the old and new model relationship? Can it tell you which purchase orders, packaging artworks and technical documents used each revision? Can it identify when the new version began production? The quality of that answer is more informative than a generic DPP slide.
2. Composition and claims file: make every assertion traceable to its source
This file joins bills of materials, component declarations, material descriptions, product claims and their source documents. It should not be a dumping ground for every certificate the factory has ever collected. Its job is to let someone ask, “What statement are we making about this current product, and what source can we retrieve to understand that statement?”
For each material or product claim, preserve the statement, the product identity it applies to, the underlying source, who supplied the source, the date, the allowed use, the verification status and the next review trigger. A claim might concern materials, origin, recycled content, repairability, performance, chemical content, energy use or safety. The article does not say that each category is required for every DPP. It says the architecture should be able to hold a claim without detaching it from its provenance.
The hard case is an upstream substitution. A supplier may replace a resin, fastener, cell, motor, coating or subassembly without changing the outward appearance of the product. Commercially, that may be sensible. Evidence-wise, it may affect several downstream claims. The composition-and-claims file should create a place where the change is assessed before a statement is repeated.
3. Evidence file: keep documents bounded, current and retrievable
The evidence file contains the documents behind the record: declarations, test reports, technical drawings, controlled specifications, supplier statements, manuals, instructions, photographs, process records or other relevant material. It should record what each document can establish and what it cannot.
A common quality mistake is treating a document title as its conclusion. “Test report” does not tell a reader which product variant was tested, under which method, on which date, by whom or with what limitation. “Certificate” does not say whether it belongs to the legal manufacturer, current model, factory, market or claim in question. A DPP-oriented file should preserve those joins instead of assuming that a PDF filename will carry them.
For a buyer, the practical test is retrieval time. Ask for a current product record, then ask for the source document behind one material or performance statement. Next ask for the preceding revision. If the factory can retrieve both, identify their product scope and explain the change without improvising, it has a working evidence habit. If the answer becomes a search through individual inboxes, the DPP conversation is early.
4. Access and ownership file: decide who may see, edit and rely on data
The Registry’s decentralised design makes this file unavoidable. Not every person in a supply chain should see every document, and not every user who can view a record should be able to edit it. The access-and-ownership file maps those boundaries.
Record the data owner, host, editor, approver, recipient, visibility level, retention expectation, language or market version where relevant, and the route for a correction. A factory might own manufacturing-side composition evidence. An EU operator might own the market-facing placement decision. A service provider might host the records. A retailer might need a limited customer-facing field set. An authority might obtain access under a particular legal mechanism. The specific rights will depend on the applicable rule. The discipline of naming the roles is reusable now.
This is also where confidentiality should be discussed honestly. “Confidential” cannot mean “unstructured and unavailable.” A supplier may have legitimate reasons to limit access to a formula, sub-supplier pricing or proprietary process detail. The right response is to agree what evidence can be exposed, at what level, to whom, through what controlled route, and what summary can support the relevant claim. Hiding the question until a customer asks for access is a poor readiness strategy.
5. Change-history file: preserve the difference between current and correct
Every mature DPP process needs a way to show that a record was current at the time it was used and that a later change did not silently rewrite history. The change-history file records a version number, date, changed field, reason, evidence affected, person who proposed the change, approver, affected product scope, notification route and, where appropriate, the previous value.
This matters because product information ages unevenly. A model name can stay the same while the bill of materials changes. A declaration can remain formally valid while a product’s manufacturing configuration changes. A marketing page can be updated faster than a technical file. Without a change history, a team cannot explain which statement was true for which production period.
The operational test is simple: pick a change that would matter to a buyer, such as a material substitution or accessory revision. Can the supplier show whether it altered any customer-facing or compliance-relevant statement? Can it identify the owner who decided that? Can it show whether the EU operator received the notice? If not, the gap is not a lack of QR-code technology. It is uncontrolled change management.
6. EU operator handoff file: make responsibility visible at the boundary
The final file is the handoff. It connects the product record to the party that will place it on the EU market or otherwise fulfil the relevant role. It should name the product scope, recipient, date, document package, unresolved questions, access route, change-notice commitment and acknowledged recipient.
The purpose is not to transfer every risk to the importer. A factory cannot simply email a folder and declare its job done. Nor should an importer assume that a supplier’s dashboard has made the importer the author of factory information. The handoff file makes the boundary visible enough for the parties to allocate work: who verifies, who retains, who publishes, who corrects, who responds to a question and who stops a listing if a material fact changes.
For teams that already source from specialised clusters, this can be combined with a familiar supplier-verification discipline. A factory is rarely the only actor. There may be a trading company, component maker, assembler, test laboratory, packaging contractor and brand. The handoff should name the legal entity that issued each source record and the party that can answer a follow-up. This is the same reason a buyer should distinguish a market, trader and factory when working through a cluster such as Chenghai Toy Cluster: A Buyer’s Sourcing File.
Turn supplier readiness into a short, testable exercise
A sourcing team does not need to wait for perfect regulatory certainty to test the six files. Use one real product family and run a ninety-minute evidence drill. The goal is not to score the factory. It is to learn whether the record can survive a handoff.
Start by giving the supplier one product question: “Show the current evidence package for this exact customer SKU and explain what changed since the last production revision.” Then ask the following sequence:
- Name the legal manufacturer, factory and product revision.
- Match the customer SKU to the supplier’s internal identifier.
- Open one current material, safety or performance statement and identify its source document.
- Show the document’s product scope, date and owner.
- Identify one change made since the previous revision.
- Explain whether the change affects any statement shared with the buyer or EU operator.
- Show who approved the change and how the operator would be notified.
- Identify which information could be accessible through a carrier and which remains controlled.
The drill has three possible outcomes.
Ready to develop: the supplier can retrieve records, connect them to the correct product identity, show a reasonable approval path and name open questions without hiding them.
Usable but incomplete: the supplier has documents and product knowledge, but identifiers, version control or ownership are inconsistent. This can still be workable if the buyer scopes a remediation project and does not make broad readiness promises.
Not ready to represent: the supplier cannot identify the current variant, evidence owner, change history or responsible handoff party. In this case, a DPP interface would mostly make the confusion easier to display.
The value of this exercise is that it creates a shared baseline without pretending to predict future legal fields. It also helps a buyer decide where to spend money. If the gap is document lineage, buy document-control discipline before an integration. If the gap is conflicting identifiers, clean master data first. If the gap is unclear responsibility, amend the supplier and operator handoff. If the gap is technical transport, then evaluate a platform.
The contract questions that belong before platform selection
Software conversations are often easier than responsibility conversations because software can be demonstrated. But the DPP readiness decision is safer when the responsibility questions are written first.
| Contract question | Why it matters | A workable evidence outcome |
|---|---|---|
| Who is the named EU economic operator for this product route? | Legal placement and data-access duties do not disappear into a supplier portal. | A named entity, route and escalation contact. |
| Which identity controls the record? | Model, batch, item and bundle names can diverge. | Cross-reference table with revision rules. |
| Who supplies each material or product assertion? | A statement needs a source and a scope. | Source register with document owner and review trigger. |
| Who can edit, approve and publish a change? | A current page can otherwise conceal an uncontrolled substitution. | Role matrix and change log. |
| What can each audience access? | Confidentiality and accessibility must coexist. | Access policy and controlled disclosure route. |
| What happens when a source document expires or conflicts? | The safest record is not one that hides uncertainty. | Pause, correction and notification rule. |
For a broader view of where evidence can break in a China-linked sourcing route, see China Supply Chain: A Buyer’s Dependency Map. The DPP does not remove normal supplier, document, continuity or handoff risk. It makes some of those links more visible.
A pause rule for “DPP-ready” claims
The most valuable sentence a buyer can add to a project plan is a stop condition:
> Do not describe a product as DPP-ready until the team can name the applicable product scope, the relevant EU operator, the controlled product identity, the owner of each material claim, the change-notice path and the legal basis for the specific representation.
This does not require paralysis. It only prevents a vague label from travelling farther than the evidence. A supplier can still say, “We are building a reusable product-evidence file,” or “We can support a controlled identifier and document handoff.” Those are meaningful statements when they are true and demonstrated. They are better than a premature promise because they identify the work that remains.
The rule also makes commercial conversations calmer. A buyer need not accuse a factory of noncompliance when there is no product-specific determination yet. The buyer can say: “We are not asking you to certify the future rule. We are asking you to show how the current product record will remain identifiable, sourced, updated and transferable.” That is a fair request today.
Method and limitations
This is a desk-research article, reviewed on 2026-08-28. It relies on the cited ESPR legal text, European Commission DPP Registry and timeline material, and a limited GS1 identifier-preparation reference. It does not rely on a factory visit, a product test, a Registry registration, a customs check, a legal opinion or a named company implementation.
The DPP framework and public timeline are evolving. A product’s actual obligation, data fields, access rights, object level, responsible actor and deadline depend on the applicable EU legislation and product-specific measures. This article therefore does not certify a supplier, a platform, a code or a product. It offers an editorial readiness model for preserving evidence and assigning handoffs before a specific rule turns those capabilities into a concrete obligation.
Frequently asked questions
Does every product imported from China into the EU need a Digital Product Passport?
No. The ESPR framework provides for DPPs where an applicable delegated act or other relevant EU law creates the requirement. A buyer should identify the product scope and applicable rule before asking a supplier to represent a product as subject to a particular DPP duty.
Is a QR code the same as a Digital Product Passport?
No. A code can act as a data carrier or address for information. The passport is the applicable, controlled product information behind it, and the legal requirement depends on the relevant product rule. A code with an uncontrolled or incomplete record is not a reliable compliance conclusion.
Does the EU DPP Registry store all product documents?
The Commission describes the Registry as storing identifiers, registration data and high-level metadata, while detailed data remains decentralised and under the responsibility of the relevant operator or service provider. A supplier should therefore preserve document ownership, access rules and change history outside a one-time registration event.
What should a China supplier prepare first?
Start with product identity, controlled source documents, a claim-to-evidence register, ownership and access rules, and a change-history process. These capabilities help regardless of which later product-specific fields apply. Do not start by promising a universal DPP template.
Can a supplier use a DPP platform before the final rule is known?
Possibly, but only as a preparation tool. The buyer should first establish what the platform can and cannot prove, whether the data remains portable and controlled, and who owns changes. Platform selection should follow a real evidence and responsibility model, not replace it.
Related entries
- EU Battery Passport: The China Supplier File — battery-specific preparation and data-boundary questions.
- China Supply Chain: A Buyer’s Dependency Map — a broader China-linked dependency and supplier-risk map.
- Chenghai Toy Cluster: A Buyer’s Sourcing File — why entity, factory and document identity must be separated in a sourcing cluster.
By China Made & Tech Team. Independent English field guide to China's niche hardware brands, hidden champions, founders, factory towns, and supplier clusters.