Extended Producer Responsibility Reporting for Engineers

What EPR actually asks of a data system

Extended Producer Responsibility schemes hold producers financially responsible for the end-of-life treatment of what they sell. Practically, that means periodically declaring what you placed on a given national market, broken down by material category and weight, and paying fees calculated from those declarations. The declaration is the engineering artefact, and the fee is calculated from it by somebody else.

The difficulty is not the arithmetic. It is that the declaration requires joining product data, packaging composition data and sales volume data, per market, with material categories that differ between jurisdictions. A product sold in three countries may be reported under three different category schemes with three different weight thresholds and three different submission formats.

This is why EPR reporting is genuinely a data engineering problem rather than a compliance form-filling exercise. The underlying facts are the same everywhere; the mapping from those facts to a submission is what varies, and conflating the two is what produces systems that need rebuilding for every new market.

Why spreadsheets fail, and when

Almost every EPR programme starts in spreadsheets, and for the first market and the first year that is entirely rational. The failure arrives predictably at the point where the number of markets multiplied by the number of reporting periods exceeds what one person can hold in their head, which in practice is around the third market or the second year.

The specific failure is not usually an error in a number. It is the inability to reconstruct one. An auditor asks how a particular weight figure was derived, and the answer requires a formula that has since been overwritten, a factor set that was updated in place, and a colleague who has left. The figure may well have been correct; the problem is that nobody can demonstrate it.

This is the requirement that shapes the architecture. EPR figures are challengeable for years after submission, so the system must be able to reproduce exactly how any declared number was produced, using the inputs and rules as they stood at the time rather than as they stand now.

The architecture that holds up

Model the activity data first: products, packaging components, materials, weights, and the markets and periods in which units were placed. This layer is the same regardless of jurisdiction and should contain no reporting logic at all. Getting this separation right is what makes adding a fourth market a configuration change rather than a rebuild.

Layer per-market reporting rules on top as versioned, tested transformations. A market's category mapping, thresholds and exemptions are rules that change over time and must be dated, because a resubmission for a prior period has to use the rules that applied then. Treating them as code with tests, rather than as spreadsheet lookups, is what makes that possible.

Store the submission itself immutably, together with the inputs and the rule versions that produced it. Re-running the pipeline later is not evidence, because the pipeline has changed. The stored artefact is the evidence, and it is the difference between answering an audit query in an hour and spending three weeks reconstructing history.

Practical requirements that catch teams out

• Material categories differ between markets and do not map cleanly onto each other
• Weight thresholds and small-producer exemptions vary and change between reporting periods
• Submission formats differ, and several schemes still require manual portal entry
• Packaging composition data usually lives with suppliers rather than with you
• Products change specification mid-year, so composition must be dated rather than current
• Returns and unsold stock affect declared volumes in market-specific ways
• Corrections to prior periods must use the rules that applied at the time

Where the data actually comes from

The hardest input is packaging composition, and it almost always sits with suppliers who have never been asked for it in a structured form. Expect a long tail of partial responses, inconsistent units, and components nobody can characterise. This is a procurement relationship problem before it is a data problem, and starting it late is the most common reason EPR programmes miss deadlines.

Sales volume by market is usually available but rarely in the shape required. Figures held for financial reporting are organised by legal entity and revenue recognition rules, not by physical units placed on a market, and reconciling the two consumes more time than teams anticipate. Establishing that reconciliation once, with documented rules, prevents it recurring every period.

Handle gaps explicitly. Where composition data is missing, use a documented proxy with a disclosed basis, and record it as a proxy in the data rather than as a measurement. The failure mode to design against is a proxy value that becomes indistinguishable from measured data in a later report, at which point the whole submission becomes difficult to defend.

Part of the Circular Economy & Digital Product Passports cluster · Read the pillar page