CSRD, ESRS E5 and Product-Level Data

Sustainability reporting and product compliance are usually run by different teams against different deadlines, and they are increasingly asking the same questions of the same suppliers.

The Corporate Sustainability Reporting Directive requires disclosure against the European Sustainability Reporting Standards. ESRS E5, covering resource use and circular economy, is where entity-level reporting collides most directly with product-level data.

What ESRS E5 actually asks for

The standard covers resource inflows, resource outflows and waste. Read carefully, several of its datapoints are physical facts about products rather than financial or operational aggregates.

The second row is where most reporting teams first discover a gap. A company can report tonnes purchased from its finance system and cannot split them into virgin and secondary, because that distinction lives in supplier certificates nobody aggregated.

Why the two programmes converge

A Digital Product Passport collects material composition, recycled content with its chain-of-custody model, durability and reparability data, and end-of-life routing. That list is close to a direct match for what E5 needs.

The difference is aggregation. The passport records these facts per product; the disclosure needs them summed across the entity for a reporting period. That is an aggregation problem, which is considerably easier than a collection problem.

Reconciliation is the audit exposure

CSRD disclosure is subject to assurance. That changes the nature of the exercise from reporting to evidencing, and the question an assurance provider asks is how the number was derived.

Where a company publishes product-level recycled content figures in passports and an entity-level secondary material share in its sustainability statement, those two must reconcile. If they do not, one of them is wrong, and both are public.

This is the practical reason to run them as one programme. Two independent collection exercises against overlapping suppliers reliably produce two different answers, and discovering that during assurance is considerably worse than discovering it during collection.

Where the numbers usually diverge

Three specific discrepancies account for most reconciliation failures, and all three are avoidable by agreeing definitions before collection rather than after.

• Different boundaries. Passport figures are per product; disclosure figures may include operational materials never in a product at all.
• Different custody treatment. A mass balance allocation counted as physical secondary content in one report and as an allocation in the other.
• Different periods. A product record reflects the current specification; disclosure covers a reporting year during which the specification changed.

The third is the most common and the least obvious. A supplier change in September means the product record is right, the annual figure is right, and they do not match — which is defensible only if somebody documented the change at the time.

Structuring one collection for both

The practical design is to collect at product level with enough metadata that aggregation is possible without going back to suppliers.

The aggregation rules layer is the one most often missing. Without documented rules, each year’s disclosure is assembled by whoever is available, and the figures move for reasons nobody can reconstruct.

Who should own the overlap

Neither team alone. Reporting owns the disclosure and has no route to suppliers; compliance owns the passport and no reporting mandate. The overlap needs an explicit owner or it falls between them.

The lightest arrangement that works is a shared attribute register — one list of attributes, each with a definition, an owner and a note of which obligations consume it. That single artefact prevents most of the duplication, and it costs a workshop rather than a system.