What a Digital Product Passport Costs

Most passport budgets are built the wrong way round. They start from a platform quote, add a contingency, and present a number that survives right up until the first supplier data request comes back empty and the timeline moves by two quarters.

The useful way to build the estimate is to work out how many distinct data sets you need to populate, how many organisations hold pieces of them, and how many of those claims require somebody independent to sign. Software is the last question, not the first.

Why SKU count is the wrong unit

The instinct is to price per product. It produces wildly wrong answers in both directions, because effort attaches to the data set rather than to the item.

A footwear brand with one construction in forty colourways has one attribute set to populate. A furniture manufacturer with eight products across four material families has four. The second company has fewer SKUs and considerably more work.

The four real cost lines

Almost every programme decomposes into the same four buckets, in a fairly consistent order of magnitude.

1. Supplier data collection. Internal time chasing attributes, plus whatever it takes to make responding worthwhile for a supplier with no direct obligation to you. Typically the largest line and almost always underestimated.
2. Verification and testing. Laboratory work, third-party assurance and any declaration a regulation requires to be independently checked. Lumpy: one required study can exceed a year of platform licensing.
3. Carrier application. Artwork changes for a printed code; tooling, tags and line integration for anything physically applied. Trivial or material depending entirely on the product.
4. Platform and integration. Licensing, connectors to ERP or PLM, and the internal engineering to keep them fed. Real, ongoing, and the smallest of the four for most manufacturers.

Where verification changes the arithmetic

Self-declared and third-party verified claims sit in different cost classes, and the regulation decides which applies rather than you. The battery carbon footprint declaration under Regulation (EU) 2023/1542 requires verification; a material composition statement generally does not.

The practical consequence is that a single product group can carry a verification requirement that dwarfs everything else in the programme. Identifying which of your claims fall into that class is worth doing before the budget is submitted rather than after.

How to build a defensible estimate

The sequence below produces a number you can defend line by line, which matters more than precision when the question comes from a finance director who has never heard of a delegated act.

The first three steps cost roughly a week of one person’s time and remove most of the uncertainty from the estimate. Skipping straight to step five is what reliably produces budgets that double between approval and delivery.

The costs that arrive late

Three lines reliably appear after the budget is approved, and all three are predictable enough to include from the start.

The first is translation. A passport served to consumers has to be readable in the markets where the product is sold, and the consumer-facing layer — care, repair, safety, disposal — is exactly the part that must be localised. A programme scoped in English for eight markets has a translation line it has not counted.

The second is reconciliation. When passport data and existing published claims disagree, somebody has to decide which is correct and correct the other. Marketing material, technical data sheets and customer submissions frequently contain figures that predate any measurement discipline, and the passport is what exposes the discrepancy.

The third is internal definition work. Two teams using recycled content to mean different things is not a data problem that a platform solves; it is a governance decision that has to be made once and then applied. Budget it as workshop time rather than as software.

What reduces cost without reducing compliance

Three decisions have outsized effect, and all three are made early or not at all.

Choosing the lowest issuance level the obligation permits is the largest. Item-level serialisation multiplies carrier and data handling across every unit; model-level does not. Where the regulation permits model level, taking it is not a compromise.

Grouping supplier requests by attribute set rather than by product is the second. The same mill supplying eleven of your styles should receive one request, and sending eleven is how response rates collapse.

Sequencing by product group rather than launching catalogue-wide is the third. One group delivered properly becomes the template for the next, and the second group costs materially less than the first because the definitions are already agreed.

What does not reduce cost is deferring the gap analysis until a platform is in place. That sequence feels faster because procurement moves before data collection does, but it reliably produces a system configured against attributes nobody has yet obtained, and a second configuration exercise once they arrive.