How to Choose Digital Product Passport Software

Start with the product, the market and the job

Write down what you need the software to do before comparing providers. Creating a consumer-facing passport, preparing textile product data, maintaining a battery passport and delivering a retailer's product-data pack are different jobs. A platform can support several of them without supporting every category or every destination equally.

Define the product group, the markets involved, your business's role and the first output you need. Include the level at which your products differ: model, sellable variant, production batch or individual item. Then name the person who will operate the process after the pilot.

Separate current obligations from preparation. The Commission says textile-specific DPP requirements will be set through a future delegated act. A software provider's textile readiness model is not that final legal specification. The existing textile DPP requirements guide and DPP dates by category own those questions. Source: European Commission.

Ask a prospective provider to explain the boundary of its support in plain English. Which categories can you use today? Which parts require configuration or another service? Which outputs are available now, and which are on a roadmap? Get those distinctions into the pilot brief, not just the sales conversation.

Understand what you are buying

Three useful capabilities often appear under the same label. They can be separate services or parts of one platform.

None of those capabilities is inherently the wrong purchase. A business with an established product-data operation may need a different service from a small brand whose information is spread across a store, spreadsheets and supplier documents.

The important distinction is between software doing the work and software giving you a place to do the work. Ask the provider to show both, using the records you actually hold.

Start the evaluation with the data you already have

Do not spend the pilot budget creating a perfect dataset before the platform sees it. That removes the very conditions you need to test.

Bring the catalogue record, identifiers, relevant variant information and the documents already used in the business. Include awkward but ordinary inputs: a composition in a description, a supplier reference in a spreadsheet or a report that applies to one batch rather than the entire range.

For a textile example, see how to build a passport from the data you already have. The point is not that every existing value is ready to publish. It is that useful information should be used before anyone asks you to collect it again.

Record four things for each important fact: what you supplied, what the software established, what remained unresolved and what a person had to do. Keep supplied declarations, calculated values and independently supported evidence distinguishable. Otherwise a full-looking output can conceal an unchanged workload.

Split the second of those in two. A suggested value, such as a composition read from a product description or a figure proposed by a model, isn't the same as a result the software can support with a source and scope. Ask the provider to show which values are still suggestions waiting for someone to accept them, and who that someone is. A suggestion shown as a settled fact moves the checking onto your team without telling them.

For Shopify, use the catalogue-to-passport journey to frame the test. Ask the provider to demonstrate which product, variant, inventory and custom-data values its actual connection retrieves. A field existing in Shopify does not prove that a particular app reads it.

Run a pilot that includes the difficult cases

Use the same small test set with every shortlisted provider. Keep a copy of the starting records and agree the expected outcomes before the session. The following five cases are ActivateDigital's suggested buying test, not a statutory test suite or a promise that any platform passes it.

1. An ordinary product

Choose something you already sell, with the normal mix of catalogue information and supporting evidence. Do not choose only the best-documented product in the range.

Follow one material fact from input to output. Can you see its source, product scope and any qualification? Does the system distinguish a merchant statement from something it calculated? Ask which steps were performed by the software and which were completed manually before the demonstration.

The result to inspect: a record you can explain, plus a clear account of the work needed to create it.

2. Variants that are genuinely different

Include products that share some facts and differ on others. Two sizes may use the same declared fabric while having different weights. Two colours may have different material compositions, suppliers or test evidence. Choose a difference that actually exists in your range.

Test both directions. Shared evidence should not become unnecessary repeated work. Evidence for one variant should not silently become evidence for every variant. Keep the detail with the existing guide to model, variant and SKU-level facts.

The result to inspect: the correct shared facts and the correct exceptions, attached to the right products.

3. Missing or incomplete evidence

Remove one supporting document, or use a real gap that has not yet been answered. Watch what happens to the fact it was meant to support.

The software should not turn an empty recycled-content field into zero, a missing certificate into a failure finding or a description into proof of an unrelated claim. It should make the next task specific: confirm the product scope, obtain a document or leave a properly identified unknown.

For the operating response, use how to handle missing product information.

The result to inspect: an explicit gap with a reason and a next action, not an invented value or an unmanageable questionnaire.

4. Two credible sources that disagree

Provide two relevant records that disagree about the same product fact. Establish first that they cover the same product, component, period and basis of comparison. Different batches or different methods can explain an apparent disagreement without either source being wrong.

Then inspect a genuine conflict. Can you see both values, both sources and the decision still required? A platform should not make the conflict disappear by averaging the numbers, choosing whichever file arrived last or selecting the more commercially attractive claim.

Use the worked example of what happens when a supplier declaration and a test report disagree. It explains why comparing the evidence comes before choosing a value.

The result to inspect: a traceable unresolved conflict or a reasoned resolution. Whether a particular unresolved state may be published is a separate, product-specific question.

5. A change after the first publication

Change a fact for a reason your business recognises: a corrected declaration, a new batch or a material change for one variant. Ask the provider to show who can make the change, what review it needs and what happens to the earlier record.

Follow the change beyond the internal screen. Does the public passport show the correct information? Does the exported record reflect the change? Where an update is not automatic, is the outstanding work visible and assigned?

Agree the required history and approval controls before testing. The existing guide to who can update a DPP separates operational controls from the applicable access rules.

The result to inspect: a controlled change whose effect on each required output can be demonstrated.

Test identity, access and continuity separately

These checks are connected, but passing one does not pass the others.

Identity: ask the provider to show how an internal SKU, a recognised external identifier and the passport record stay associated. Test one variant with a similar name to another. Check that a barcode reaches the intended product, not simply a page that opens successfully. Keep identifier choices with your first product identifier.

Access and governance: nominate the people who may supply evidence, approve a change and publish it. Test a permitted action and a refused action using non-sensitive test data. Ask which information becomes public and which remains restricted. Do not infer access control from the presence of a login screen. Use who can see what in a DPP for the access question.

Standards and interoperability: ask which standards, versions and conformance claims the provider relies on. Test the required identifier, carrier, resolution and data exchange separately. ESPR provides a legal foundation for open, interoperable DPP data exchange without vendor lock-in; that does not certify a specific product, connector or implementation. Source: ESPR, Articles 10–11.

Provider responsibilities: distinguish the business publishing the information from a company hosting it or operating part of the service. Product demonstrations do not settle those legal roles. Use the DPP service-provider guide alongside the proposed contract.

Exit and continuity: export an actual pilot record and inspect what survives outside the platform. Include identifiers, relevant evidence references, scope and the history you require. Ask who controls the domain and printed address, what happens during a migration and what continued availability costs. The detailed owner is what you can take with you when you leave a provider.

A downloadable file is a useful start. A usable exit requires the data and the operating arrangements to work together.

Test the destinations you will actually use

The passport is one output. The business case can extend to buyer requests, retailer data, marketplace listings, APIs and customer experiences. Name the destinations you need rather than accepting “export available” as a complete answer.

Give the provider one real destination specification: a retailer's required columns, a marketplace feed requirement or an agreed API response. Ask it to produce that output from the pilot record. Inspect whether identifiers, units, product scope and qualifications survive. Check whether an unsupported claim is omitted or flagged rather than silently flattened into a confident value.

Also ask who owns the final mapping and whether delivery is manual, through an export or through a maintained integration. “The data can be exported” and “this retailer integration is operating” are different claims.

This is the practical value of governed product information: establish and maintain the fact once, then use it appropriately. The detail belongs with how product evidence travels downstream, not with another passport form.

Compare total work, not just the licence price

Record the effort inside the pilot. Count the manual corrections, supplier requests, approvals and repeated entry. Record who performed them and whether they are a one-off setup task or recurring product work.

Then ask what the quotation includes: setup, imports, data resolution, document handling, exception review, hosting, updates, export and support. Agree the charging unit. A price per model is not automatically comparable with a price per variant, item or published passport.

Use the textile passport cost guide for cost drivers and the limits of published estimates. A pilot supplies evidence about your workload; it does not establish a market-wide savings percentage.

The strongest question is straightforward: what will my team still be doing on the hundredth product, and when the first hundred products change?

Use this pass/fail pilot scorecard

Mark every test Pass, Fail or Not tested. A claim in a sales document is not a pass. Keep an evidence reference for each result, such as the exported record, a redacted screen capture or the written operating procedure you tested.

Before starting, mark which requirements are essential to your purchase. An optional criterion can be marked Not applicable only with a recorded reason. That is not a way to waive a legal requirement.

Accept a provider against the essential tests you agreed, not an averaged score that hides a failed critical requirement. Leave untested items open. Where a provider offers to fix a failure, agree the deliverable and repeat that test before treating it as passed.

Keep the pilot record simple: test case → expected outcome → observed outcome → evidence → owner → decision. The result should tell a colleague why you chose the system without requiring them to attend every sales call.

Put ActivateDigital through the same test

ActivateDigital's approach starts with the product data and evidence you already hold. We resolve what the record supports, keep the basis for the result and focus attention on genuine gaps and disagreements. The objective is governed product information you can use, with the passport as one important output.

Do not take that description instead of a test. Bring a representative product and examine the result against the same scorecard.

Connect → Build → Activate. Start with your records. Inspect the decisions. Put supported product information to work.

Explore textile passport software

Using Shopify? Start from your Shopify catalogue. Working on batteries? Explore battery passport software.

Sources and scope

This is ActivateDigital's buyer-evaluation method, not a vendor ranking, certification scheme or legal compliance checklist. No competitor's performance, price or capability is scored here.

The regulatory statements draw on the European Commission's textile DPP page and Regulation (EU) 2024/1781, reviewed on 6 October 2026. Linked Knowledge pages retain ownership of their specialist legal, identity, evidence and operating questions. Product capabilities should be demonstrated in the current product, not inferred from this buying method.