The short answer
Yes, a company can create thousands of Digital Product Passports without manually authoring thousands of completely different documents. The scalable pattern is to create one approved product or model template, import the variable data for each manufactured item, mint or validate a unique identifier for each item, generate the corresponding QR destination, print or attach the correct code, and record the complete issuance and commissioning trail.
The important distinction is between reusing passport structure and reusing an item identity. You can reuse the model's common technical and sustainability data. You cannot reuse the same item-level identifier and QR destination where the applicable rules require an individual product record. For batteries, this distinction is central: Regulation (EU) 2023/1542 requires a battery passport for each relevant LMT battery, industrial battery over 2 kWh and electric vehicle battery from 18 February 2027. It also requires the passport to be accessible through a QR code linked to a unique identifier attributed to the battery, and the passport contains information specific to the individual battery. Read Article 77 of the Batteries Regulation on EUR-Lex.
This does not mean every future DPP in every product category will always be item-level. Under the ESPR, the applicable delegated act can specify whether a passport is created at model, batch or item level. Article 9 of Regulation (EU) 2024/1781 makes that level a product-group-specific requirement. Treat batteries as the current, fixed-deadline item-level case, and check the delegated act for every other category.
What changes when you move from one DPP to 10,000
At small volume, a team tends to think about fields: materials, carbon footprint, manufacturer, repair information and end-of-life instructions. At scale, the hard problem becomes the relationship between common data, variable data and physical identity.
| Layer | Reusable across a model | Variable for each item | Control question |
|---|---|---|---|
| Product definition | Product name, specification, materials, approved supplier evidence | Usually little or none | Has the correct model revision been approved? |
| Manufacturing record | Process rules and validation rules | Serial number, production date, plant, test results | Can this exact item be traced to its production evidence? |
| Passport identity | Template and access policy | Unique product identifier and item record | Does one identifier resolve to only one intended item? |
| Physical carrier | Label layout, print settings, human-readable fields | The actual QR payload for each item | Was the correct label applied to the correct unit? |
| Lifecycle state | Workflow and audit schema | Commissioned, shipped, repaired, repurposed or recycled status | Can a later change be proven without erasing history? |
The wrong shortcut is to generate one QR code for a model, copy it onto every unit and call the result an item-level passport. That may be appropriate only when the applicable rule defines the passport at model or batch level. Where the passport is item-level, that shortcut destroys the link between the physical product and its record.
The scalable DPP workflow
The workflow below separates decisions that should happen once from events that must happen for every unit.
1. Define the product model and the applicable level
Start by identifying the legal and operational scope. Record the product category, the applicable regulation or delegated act, the economic operator responsible for the passport, the required data fields, the access tiers and the required level: model, batch or item.
For batteries, build the process around the fixed requirements in Article 77 and Article 13 of Regulation (EU) 2023/1542. For other DPP categories, do not assume that the battery pattern automatically applies. The ESPR requires the relevant delegated act to specify the level and the data carrier arrangement.
The output of this step is an approved passport template, not a QR code. It should contain the common fields, field definitions, source systems, evidence requirements, validation rules and version number.
2. Prepare a clean batch-import file
Do not begin by pasting data into a passport form thousands of times. Prepare a controlled import file or integration payload with one row per physical unit when the passport is item-level.
A practical minimum for a serialized battery import might include:
| Field group | Example fields | Why it matters |
|---|---|---|
| Product identity | GTIN or other approved product identifier, model code, product revision | Connects the unit to the correct template |
| Instance identity | Serial number or allocated serial range | Distinguishes one physical unit from another |
| Manufacturing context | Production date, manufacturing plant, production line | Supports traceability and investigation |
| Compliance evidence | Test reference, conformity record, material or carbon evidence reference | Prevents unsupported claims in the passport |
| Lifecycle data | Initial performance values, status, commissioning date | Supports item-specific and dynamic information |
| Publication control | Target market, language, access profile, release status | Prevents premature or overexposed publication |
The exact fields depend on the applicable rules and product. A CSV can be a sensible pilot format, but the file must be treated as a controlled data exchange, not as an informal spreadsheet. Validate column names, data types, units, required values, duplicate identifiers and references to evidence before any passport is published.
3. Mint or validate the unique identifier
A scalable system needs an explicit answer to the question: who owns identifier allocation, and how is uniqueness guaranteed? Possible patterns include allocating serial numbers in the manufacturing system, importing a pre-issued serial range, or generating identifiers inside a controlled DPP workflow. Whatever the pattern, the DPP system must reject duplicates and preserve the original allocation record.
When a GS1 identity model is used, a serialized trade item can be expressed as a GTIN plus serial number. GS1 describes the combination of GTIN and serial number as a way to uniquely identify an individual product instance. Its Digital Link syntax can represent that identity in a web URI such as /01/{GTIN}/21/{serial}. See the GS1 Digital Link standard and the GS1-Conformant Resolver Standard.
Do not invent a GTIN, claim that a random UUID is automatically a compliant GS1 identifier, or treat a URL slug as proof of global uniqueness. Confirm the identifier standard, issuing authority, company prefix, serial allocation policy and any required registration or verification process. The DPP implementation should store the source, time, operator and validation result for every identifier.
4. Generate the resolver destination and QR payload
The QR code should carry a stable, resolvable destination that includes or reliably maps to the unique product identity. A resolver then uses that identity to return the appropriate passport view, API representation or other authorized resource.
The QR is not the passport itself. It is the physical data carrier that gives a person or system a route to the passport. The resolver layer matters because you may need to change the destination, access policy, presentation language or linked resource without changing the printed identity. The identifier must remain persistent even when the passport content is updated.
For a GS1 Digital Link pattern, a payload may look conceptually like this:
https://id.example.com/01/09506000151519/21/12345678p901
This is an illustrative syntax example, not a production identifier. Every production payload must be generated from your verified identifier allocation and resolver domain. Before printing, test that the payload is syntactically valid, resolves over HTTPS, resolves to the intended item and does not expose data to an unauthorized audience.
For background on how DPP data carriers connect to persistent unique product identifiers, see Article 10 of the ESPR. The regulation also requires the carrier to be physically present on the product, its packaging or accompanying documentation as specified by the applicable delegated act.
5. Render, print and apply the right code
Bulk QR generation is only half of the physical process. The other half is association control: proving that the label generated for serial A was attached to serial A.
Use a print data set that keeps the item identifier, QR payload, human-readable serial number, model code and label version together. At minimum, the print workflow should support:
- A deterministic row or job identifier for every label.
- A preview or preflight check before the print run.
- A clear separation between approved, printed, applied and rejected labels.
- Reconciliation of requested labels versus successfully printed labels.
- Scan verification after application.
- Quarantine and destruction records for misprints, duplicates and unused labels.
For batteries, Article 13 requires the QR code from 18 February 2027 and says the QR code and labels must be visible, legible and indelible on the battery, or on packaging and accompanying documents where placement on the battery is not possible or warranted because of its nature or size. See Article 13 of the Batteries Regulation. The exact production method, symbol layout and placement should follow the final applicable requirements and your validated packaging process.
6. Commission the passport at the right production event
Issuing an identifier is not the same as commissioning a passport. Define the event that changes a record from reserved or draft to active. It could be a passed end-of-line test, a quality release, a packaging event or the act of placing the battery on the market, depending on your process and legal responsibility.
The commissioning event should capture:
- The item identifier and model revision.
- The production or quality event that authorized publication.
- The source batch and evidence references.
- The user, system or line that performed the action.
- The timestamp and release status.
- The QR payload and resolver response observed at release.
This prevents a common failure mode: thousands of QR codes are printed before the underlying records are complete, then production ships units whose scans return a draft, an empty page or another product.
7. Validate in layers, not only at the end
A high-volume DPP program needs automated validation before, during and after issuance.
| Validation layer | Checks | Failure action |
|---|---|---|
| File validation | Required columns, encoding, units, date formats, row count | Reject the import with an actionable error report |
| Identity validation | Duplicate GTIN and serial combinations, invalid ranges, reused identifiers | Block issuance and quarantine the affected rows |
| Content validation | Required fields, allowed values, evidence references, access classification | Keep the record in draft or review status |
| Resolver validation | HTTPS response, correct item mapping, expected status and access | Block release until the resolver passes |
| QR validation | Decode rate, payload equality, print contrast, quiet zone and physical readability | Reprint or quarantine the label job |
| Line association | Scan item and label at the point of application | Stop or divert the line on a mismatch |
| Post-release monitoring | Broken links, unexpected access errors, stale data, revoked records | Open an incident and preserve the audit trail |
Do not measure success by the number of QR images generated. Measure the number of correct, active and traceable item records that survive a scan from the real product.
How ERP, PIM and manufacturing systems fit together
The DPP layer should have clear source-of-truth boundaries. The ERP may own commercial identity, orders and supplier relationships. The PIM may own descriptive product content and translations. MES, QMS or a battery management system may own manufacturing events and performance measurements. The DPP system assembles the authorized view, validates it and exposes it through the required carrier and access controls.
The integration pattern can be staged:
- Pilot: controlled CSV import for one model and a small serial range.
- Scheduled sync: periodic exchange for stable model and supplier data.
- Event-driven sync: publish changes from ERP, PIM, MES or QMS when a qualifying event occurs.
- Reconciliation: compare source counts, passport counts, label counts and shipment counts.
Do not let two systems silently mint serial numbers for the same product family. Choose one allocation authority and make every downstream system consume or validate that identity. The DPPAutomate ERP and PIM integration guide explains the broader mapping and synchronization problem, while the integrations overview is the appropriate place to evaluate connection options. These links describe the integration problem and available product surface; they are not a claim that every connector or manufacturing-system integration is already available.
Updates, replacements and rework
A passport at scale is a lifecycle record, not a static landing page. Regulation (EU) 2024/1781 requires DPP data to be accurate, complete and up to date, restricts update rights by access level and requires data authentication, reliability and integrity. It also says that when a new DPP is created for a product that already has one, the new passport must be linked to the original passport or passports. See Articles 9 to 11 of the ESPR.
For batteries, the regulation is even more explicit about status changes. A battery that has been prepared for re-use, prepared for repurposing, repurposed or remanufactured must receive a new battery passport linked to the original passport or passports. The original identity and history should not be overwritten to make the current state look like the original state. See Article 77(7) of the Batteries Regulation.
Design the workflow around immutable events and controlled current state:
- Correction: update a factual field with the reason, approver and evidence.
- Rework: record the rework event, affected fields and new quality release.
- Replacement: create or link the new identity according to the applicable rules and preserve the relationship to the old record.
- Recall or withdrawal: change availability or status without deleting the historical record.
- Repurposing or remanufacturing: create the required new passport and link it to the original.
- Recycling: retain the required history and close the passport only when the applicable rule says it ceases to exist.
The QR code should continue to resolve to the stable identity. The resolver can present the current authorized state while the audit system preserves the version history.
A commissioning checklist for your first 10,000 units
Before scaling beyond a pilot, confirm each item below:
- The applicable product rule defines whether the passport is model, batch or item-level.
- The product template has an owner, version and approval status.
- Every required field has a named source and evidence rule.
- One system owns identifier allocation; all other systems validate it.
- Duplicate and collision tests run before issuance.
- Each QR payload resolves to exactly one intended record.
- The print data links serial, payload, model revision and job ID.
- A physical scan test runs at the point of label application.
- Misprints and unused labels are quarantined and reconciled.
- Draft, approved, active, withdrawn and recycled states are distinct.
- Updates create an audit event rather than erasing the prior value.
- Rework, repurposing and replacement rules are written before the first incident.
- Access tiers are tested with representative user roles.
- ERP, PIM, MES or QMS ownership boundaries are documented.
- The team can export the passport data and the issuance audit trail.
If the answer to any of these is "not yet," the program is not ready for a full-volume print run. Use the DPP readiness check to structure the gap conversation, then compare the required implementation work with the DPP cost guide.
What to look for in a DPP platform or QR code batch generator
The phrase "bulk QR generator" can describe anything from a simple image script to a regulated production workflow. Compare platforms on the controls around the generator, not only on how fast they create PNG files.
Ask vendors to demonstrate:
- Template reuse without accidental sharing of item-specific data.
- A documented identifier model and collision handling.
- Batch import with row-level errors and repeatable reruns.
- Resolver monitoring and scan-level verification.
- Print-job reconciliation and label quarantine.
- Role-based access and approval workflows.
- Version history, audit exports and status transitions.
- Integrations or APIs that match your source systems.
- A clear data-export and business-continuity policy.
- A practical pilot path before a full catalogue rollout.
The DPPAutomate platform page, API documentation and free sign-up are verified DPPAutomate routes for evaluating the broader platform and technical starting points. The right choice depends on your product scope, data maturity, manufacturing process and required identifier level.
Conclusion
Thousands of DPPs are manageable when the work is divided correctly: define the model once, allocate one identity per required product instance, import the variable data, generate a resolver payload, print and apply the matching QR code, validate every handoff and preserve the lifecycle history. The QR image is the visible part of the system, but identity governance and production reconciliation are what make the result trustworthy.
For batteries, prepare now for the 18 February 2027 obligation. Build the item-level process around Article 77, verify the QR and label requirements under Article 13, and test the complete path from source data to physical scan. For every other product category, follow the applicable delegated act rather than assuming that all DPPs require the same granularity.
Ready to map your first serialized DPP pilot? Start with the DPP readiness check, review the integration options, or create an account.
Continue through the cluster
If granularity is not yet settled, start with whether you need a separate DPP for every product. Battery teams should also review the QR-code obligation, identifier hierarchy, and model-to-item data architecture.
