Look for software that can hold structured product data, keep a source and evidence with each value, record who reviewed it, handle conflicts without inventing facts, version and audit changes, control public and restricted access, manage identifiers and data carriers, connect to other systems, track regulatory updates, isolate tenants, and export a complete record if you leave. Products cover different layers: regulatory guidance, readiness, product and supplier data, traceability, passport services and identifiers. They are not automatically substitutes. There is no single universal software specification for every product category. Exact legal and data requirements depend on the applicable product-specific rules. A category name, a QR generator or a claim of ESPR compliance does not settle those questions. Software selection does not determine a legal duty or establish compliance. This is a buying guide, not a ranking.
What does DPP software actually need to do?
Answer checked:
It needs to support the information, identifier, carrier, access, update and availability requirements that apply to your product. There is no single software feature list that makes every product legally compliant. Start with the applicable rules and the evidence your organisation must maintain.
For a passport service, test structured and machine-readable data, interoperability, identifiers at the required granularity, rights-controlled access and updates, security, integrity and continuity. Separate legally required outcomes from buying preferences such as a particular dashboard, ERP connector or automated supplier reminder.
Ask the vendor to demonstrate a product-specific record, restricted-data access, a correction and audit history, data export, service exit and the appropriate registration workflow. Six harmonised DPP standards are cited by Decision (EU) 2026/1736; they support presumption of conformity only for the requirements they cover, not blanket product certification.
DPPLogic’s public tools help assess readiness and organise preparation. They do not publish passports, issue QR codes, submit Registry records, contact suppliers or independently verify documents. The buying brief below records your needs; it does not activate a passport service.
Source: ESPR — Regulation (EU) 2024/1781 — Articles 2, 4, 9–13 and 27–38; current displayed consolidation. As checked 22 September 2026.
Source: Battery Regulation — current consolidated text — Consolidation 13 August 2026; Articles 1, 3, 13, 39, 77–78 and Annex XIII. As checked 22 September 2026.
Source: DPP standards — Implementing Decision (EU) 2026/1736 — Articles 1–2 and Annex: six cited harmonised standards, within their covered requirements. As checked 22 September 2026.
What this guide covers
This guide covers buying questions: layers, capabilities, evidence, supplier workflow, review, versioning, access, identifiers, interoperability, updates, security, operating-cost questions, and what software cannot solve by itself. Documented vendor capabilities are compared separately. Price units and scoped-cost questions are on the cost guide.
DPP platform versus spreadsheets: compare the controls you need
A controlled workbook can be sufficient for a bounded preparation task. Evaluate a platform when recurring supplier requests, multiple reviewers or product revisions make the existing process difficult to maintain. Neither format establishes legal compliance or independently verifies a supplier claim.
Compare the actual workflow, including manual controls and operating effort. Product count alone is not a reliable threshold for buying software.
| Task | Controlled spreadsheet approach | What to demonstrate in a platform |
|---|---|---|
| One product and one reviewer | Named workbook owner, fixed fields and controlled evidence references | A clear product record with the same source relationships |
| Repeated supplier responses | Request IDs, a response log and manual reconciliation | Responses linked to the correct request and product, with missing answers visible |
| Several reviewers | Access policy, change history and an agreed sign-off process | Appropriate roles and a recorded review decision |
| Product changes | Retain versions and maintain an affected-record list | Show the old value, changed scope and records needing review |
| Handoff or exit | Export values plus an evidence-reference register | Usable export with identifiers, units and supported review/provenance information |
Build your software buying brief
Separate must-have capabilities, unresolved requirements and procurement questions. This worksheet does not choose a vendor, determine applicability or calculate a compliance score.
Your choices stay in this page’s memory and disappear on reload or close. No name, email, company, budget amount or vendor choice is requested. Worksheet answers are not sent to acquisition measurement.
No questions answered.
Your buyer-needs summary
Must-have capabilities
Other capability priorities
Unknown requirements to resolve
Data and supplier gaps
Integration needs
Procurement questions
Next steps
These are your planning choices. Validate requirements, evidence and contract terms before procurement; a completed brief does not establish compliance or product suitability.
Different layers solve different problems
Product-specific measures determine relevant information, scope, granularity and access arrangements. A software category name, QR code or vendor statement does not settle those legal questions. ESPR Articles 9–11 and Annex III provide the framework; applicable measures supply the product-specific choices.
The map is a preparation sequence, not a required architecture. One offer may span several layers; others supply only one component. Check the actual module, license, implementation and operating responsibilities.
- DecideApplicability and readiness
- CollectData, evidence, suppliers
- RecordPassport structure
- ShareCarrier, access, registry
- MaintainUpdates and monitoring
A generator that prints a QR code does not replace applicability analysis, evidence control or product-specific legal requirements.
In text: first decide what applies and what is missing; then collect data and evidence; then structure a record; then attach a carrier and access rules if required; then maintain the record. Those layers can sit in different products.
| Layer | Buying question | Categories to investigate |
|---|---|---|
| Regulatory scoping | Which instrument, product conditions and dates apply? | Regulatory guidance and compliance platforms |
| Readiness and gaps | Which responsibilities, data and evidence remain unresolved? | Readiness and preparation tools |
| Product and supplier data | Where will values, supplier responses and provenance be maintained? | PIM, traceability and supplier-data platforms |
| Passport creation and hosting | Which service creates, publishes and maintains the relevant passport? | DPP-native and broader passport services |
| Identifiers and carriers | Which identifier schemes, carriers and resolver functions are documented? | Identifier and connected-product platforms |
| Integration | Which APIs, connectors and mapping work connect the required systems? | Product-data, integration and passport platforms |
| Monitoring | Who tracks source changes and updates the implementation? | Regulatory monitoring plus assigned internal review |
Capability matrix — what to verify, not a score
Use this matrix to decide what a shortlisted offer must actually do. A cell is a buying question, not a finding that any named vendor meets it. Do not treat a marketing category as proof.
| Capability | Why it matters | What to verify | Claim class |
|---|---|---|---|
| Instrument and product-class support | The act decides fields, dates and granularity | Named instruments, exclusions and review dates — not “ESPR-ready” | PRODUCT-SPECIFIC / DELEGATED-ACT DEPENDENT |
| Data ingestion and provenance | A received value is not a verified field | Source system, owner, date, version and supporting file on the same record | Analysis |
| Supplier request and response | Many required facts sit upstream | Documented request, reminder, validation and update path — not a shared inbox | Analysis |
| Human review | Conflicts and gaps need a named decision | Who can accept, reject or leave a field open; the review stays visible | Analysis |
| Versioning and audit | Published values change; history must remain reconstructable | Who changed what, when, and which version a carrier currently resolves | FRAMEWORK / PREPARATION |
| Public and restricted access | A required passport is not an all-public file | Role or purpose-based views; demonstration of a restricted field remaining restricted | Current law |
| Identifiers and carriers | A code points to a record; it is not the record | Supported schemes, resolver behaviour, collision handling and reprint process | FRAMEWORK / PRODUCT-SPECIFIC |
| Interoperability and export | You may need another host, a successor vendor or an internal archive | Machine-readable export, attachments, identifier continuity and exit timing | Current law |
| Regulatory-update handling | Delegated acts and standards continue to move | What is monitored, who reviews a change, and how a live record is updated | DELEGATED-ACT DEPENDENT |
| Security and tenant separation | Supplier and product files are commercially sensitive | Current security documentation, tenant isolation and access logging — scoped to the offer | Analysis |
Compare categories before comparing vendors
Guidance and preparation
Helps identify scope questions, data gaps and responsibilities. Verify whether it also stores or publishes customer product records.
PIM and supplier information
Organises product attributes or supplier requests. Verify supporting evidence, partner modules and the separate passport service.
Product and supply-chain relationships
Connects batches, items or events where supported. Ask what is directly observed, supplier-reported or derived.
Creation, hosting and carriers
Publishes and maintains the documented offer. Verify granular access, identifiers, export, service continuity and the exact commercial scope.
Data ingestion, provenance and human review
Ask how a value enters the system: typed, imported, mapped from another application, or received from a supplier. Then ask how that value stays attached to a source, a date, an owner and a supporting file. A spreadsheet upload without provenance is a data dump, not a passport record.
Human review is a capability, not a disclaimer. Software can structure, extract, flag, compare, route and assist. It should not be treated as automatically converting uncertain supplier information into verified legal facts. Ask who can accept a value, who can reject or correct it, who can leave a gap open, and whether a conflict can remain visible instead of being overwritten. Software that forces a complete field to close a workflow is a risk, not a feature. Do not treat an AI suggestion as verified data, a compliance certificate, or a substitute for product or legal review.
| State | Meaning | Do not |
|---|---|---|
| Value | The number, text or code currently shown | Treat display as proof |
| Source | Originating system, file or supplier response | Treat as verified |
| Evidence | Dated, scoped supporting file | Keep only in a personal inbox |
| Review | Named acceptance for a stated scope | Equate received with true |
| Accepted data | A reviewed value allowed for a stated use | Assume every accepted value is already a passport field |
| Passport dataset | Values that may be published if the act requires them | Publish an unverified gap |
PIM handoff example: keep source fields and evidence connected
Fictional manual mapping exercise, not a claim that DPPLogic provides a PIM integration. The PIM holds product facts; an evidence register identifies their support. A reviewer must check that both describe the same revision before accepting a handoff.
| Source field | Destination meaning | Check before acceptance |
|---|---|---|
| sku = TR-100; revision = B | The assessed product record | Do not drop the revision during mapping |
| material = recycled polymer; content = 60; unit = % | Declared material claim and unit | Preserve the calculation boundary; do not infer one |
| evidence_ref = DEC-14 | Reference to the supporting source | DEC-14 covers revision A; request support for B |
| review_state = pending | Human review is incomplete | Do not map pending to accepted or READY |
Supplier-data workflow questions
Many DPP fields cannot be invented by the placing operator. Ask whether missing data can be requested from suppliers, whether requests can be scoped to specific products and fields, whether suppliers can attach evidence, whether submissions remain unverified until reviewed, whether reviewers can accept, reject or correct information, whether unresolved data can remain visibly unresolved, and whether supplier access can be restricted. A portal login is not a workflow if reminders, scope and review sit outside the product.
Do not send a universal questionnaire to every supplier. The request should name the product class, the values needed, the evidence expected, and the review date. There is no single supplier-data list for every Digital Product Passport. This is procurement guidance. It is not a statement that DPPLogic currently sends live supplier messages.
Public data, restricted data and identifiers
Where a Digital Product Passport is required, access rights decide who sees which fields. Public retrieval of a required passport does not make every technical or commercially sensitive record public. Ask the vendor to demonstrate a restricted field remaining restricted for an unauthorised role.
A data carrier points to an identifier. The identifier retrieves the record. ESPR Article 10 treats the carrier more broadly than a QR code and asks for open, interoperable, machine-readable formats without vendor lock-in. GS1 Digital Link is one identifier route; it is not a legal monopoly unless the applicable act says so. Printing a code does not create the dataset, the access rules or any required Registry entry.
Versioning and audit
Versioning is a robust implementation requirement, not one identical technical design mandated for every product regime. Ask what changed, when, who changed it, why, which source or evidence supported it, who approved it, which version was published or exported, and whether historical states can be reconstructed. If a carrier still resolves after a correction, ask which version a scan now retrieves.
Interoperability and operating cost
Implementing Decision (EU) 2026/1736 cites six DPP standards. Remaining standards are still listed as planning on the Commission overview. Ask which cited standards the offer implements today, which are on a roadmap, and how a later standard change is applied to records already published. Do not treat one file format as already legally mandatory for every Digital Product Passport.
Ask how the offer connects to PIM, ERP, PLM and supplier systems, and whether structured import, structured export, APIs and identifier systems are documented for the exact product you would buy. A connector name is not an implemented mapping.
Price a module, an implementation, hosting, usage, support and exit separately. A connector price is not a complete project cost. This page does not estimate prices.
Who owns regulatory updates
Vendors do not determine what EU law means. Ask who maintains the regulatory model, how new delegated or implementing acts are incorporated, whether requirement versions can be identified, whether developing requirements can be separated from enacted ones, whether historical workflows remain tied to the rule version used, and how customers are notified of changes. A “we will connect to the Registry when the API is available” statement is a plan, not a live integration. Keep roadmap items out of the scored offer.
Security and tenant separation
Supplier responses, composition data and unpublished drafts are commercially sensitive. Ask how organisations are separated, how supplier permissions are limited, how public information is kept apart from private source evidence, how authentication works, what is logged, how deletion and retention are handled, and whether one tenant can export another customer’s records. A generic ISO badge without a scope statement is not enough.
If a vendor discusses AI features, ask what is sent to the model, how tenant data is isolated, whether outputs can introduce unknown fields, how citations are retained, whether AI output remains reviewable, whether AI can automatically mark information verified, and how failures are handled. Those are buying questions, not a description of any DPPLogic system.
If the offer uses partners for hosting, translation or supplier collection, name those partners in the contract review. A partner module is a separate offer.
A vendor-evidence standard
Compare offers against your own brief, not against a published “best software” list. For each important capability request: the product name and version, a first-party page or documentation locator, a retrieval date, and a demonstration on non-sensitive sample records. Marketing language alone is not proof of production capability.
If battery passport capability matters, request explicit evidence for that battery use case. Do not assume generic DPP functionality covers it. Vendor-specific battery details belong in the sourced comparison, not as assumed hub copy.
| Evidence state | Meaning |
|---|---|
| Public production evidence | A current first-party product that can be observed in ordinary use |
| Named customer case study | A dated, scoped customer example — still not your requirement |
| Public demo | A controlled demonstration; ask which version it is |
| Pilot | Limited operation; ask what is excluded |
| Non-production preview | Not offered as a production product |
| Announcement | A named future or newly described product without production evidence |
| Roadmap | Planned work; keep it out of the scored offer |
| Partner-dependent | The capability sits in another organisation’s product |
| Unknown | No usable first-party evidence yet |
Questions to carry into a demonstration
Use the worksheet above to identify priorities. Ask vendors to demonstrate the specific product and version they would supply, using non-sensitive sample records. A documented feature is not proof that it meets your particular requirement.
| Question | Evidence to request |
|---|---|
| Which product rules and limitations are supported? | Named instruments, source locators, review dates and explicit exclusions. |
| How are product values and evidence related? | A sample record with source, version, ownership and change history. |
| What does supplier collection include? | A documented request, response, validation and update workflow. |
| Who reviews a value before it can be published? | Named roles, conflict handling, and a demonstration of an open gap that is not overwritten. |
| Who can read, create and update information? | Role/access documentation and a demonstration of the relevant restrictions. |
| Which identifier schemes and carriers are documented? | Scheme names, resolver behaviour, reprint process and lock-in terms. |
| Which systems actually connect? | Connector/version compatibility, API documentation, mapping and delivery responsibilities. |
| How are regulatory source changes handled? | What is monitored, who reviews, and how a published record is updated. |
| What can be exported on exit? | A representative export, attachments, identifiers, timing, costs and URL-continuity terms. |
| What exactly does the price cover? | Itemised software, partner/module, implementation, usage, hosting, support and renewal units. |
| What is live rather than planned? | Current product documentation and written scope; keep roadmap items separate. |
Software evaluation: test one product and one conflict
Use a fictional or authorised test dataset. Ask for observed outcomes rather than a general assurance that the software is DPP-ready. This is a procurement exercise; test the additional legal and technical requirements of the intended passport service separately.
| Test input | Action to demonstrate | Evidence to retain |
|---|---|---|
| TR-100 revision B; declaration covers revision A | Record the mismatch without silently accepting the value | Visible unresolved status and source reference |
| Two different composition values | Review both sources and explain the decision | Reviewer, reason and retained previous value |
| A supplier response with a missing unit | Keep the response pending and assign follow-up | Request/product link and a named next action |
| A restricted evidence reference | Test access using the proposed user roles | Observed allowed and refused access |
| A reviewed product record | Export and inspect the actual file | Identifiers, units and source/review information supported by the export |
What software cannot solve by itself
Software cannot decide whether a Digital Product Passport applies to your product. It cannot invent a missing supplier fact, repair poor source data, resolve contradictory evidence, convert a Working Plan year into an application date, settle legal interpretation, create internal ownership, or force supplier cooperation. It cannot enrol your organisation in the EU DPP Registry or certify that a published file meets an act you have not read. Software can support the process. It cannot manufacture trustworthy evidence or turn uncertain law into certainty.
Those limits are why a buying brief starts with applicability, data ownership, evidence and governance — then software. A low monthly price for an unlimited QR pack does not close those gaps.
Build, buy or combine components
An internal build offers control over the model and integrations, but requires ongoing engineering, operations, security, source review and exit planning. Buying a service can transfer some implementation and operating work; it does not remove the buyer’s responsibility to define requirements and verify contractual scope.
A combined approach may reuse existing ERP, PIM or supplier systems and add only the missing passport layer. Compare maintenance ownership, portability and total scoped work before treating a component price as a complete project cost. This page does not estimate prices.
Where DPPLogic sits today
DPPLogic’s live public offer includes regulatory guidance, the readiness assessment, the bounded applicability checker and battery/data preparation checklists. The buyer worksheet helps structure procurement questions. It does not select a best vendor.
The DPPLogic workspace is available on Free, Professional and Business plans; every plan includes the preparation workflow, and Professional and Business add team, bulk and governance tools (catalogue import, optional independent review by a second team member, multi-product supplier requests, supplier response import, secure supplier response links, bulk work and an audit trail export). It supports manual DPP data preparation, requirement gaps and actions, supplier information tracking with requests you send yourself, evidence references, human review, internal READY packages and JSON or CSV export. AI-based document reading, document upload or storage, a supplier portal, automated supplier email, public passport publication or hosting, QR codes, official Registry submission, a customer passport API, automated regulatory monitoring and legal-compliance certification are not offered. A controlled assessment runtime is not a customer passport API. DPPLogic is included in the comparison as the publisher’s own product, with the same evidence rules.
Resolve uncertainty before committing to an offer
If product or regulatory scope is unknown, review applicability first. If scope is reviewed but data, evidence or supplier readiness remains uncertain, the broader readiness assessment can help organise preparation. Buyers with defined requirements can proceed directly to documented capability comparison.
Primary and authoritative sources
Source links are provided for verification. Scope, consolidated versions and later measures should be checked again before implementation or reliance.
Regulatory disclaimer. This content provides general diagnostic and preparation information. It is not legal advice, certification or regulatory approval. Requirements may differ by product category, jurisdiction, market and supply-chain role and may change over time.