Extended Producer Responsibility Reporting: Are You Paying Fees on Packaging You Never Sold There?

The number you submit is a guess, and both directions of error cost real money

Producer fees are assessed on the packaging you place on market, by material type and weight, in each jurisdiction, on that jurisdiction's own schedule. That sentence contains four joins your business has almost certainly never made. Material type and weight live in supplier specifications, often as PDFs. Placed on market means sold into a specific market, which your sales data expresses as ship-to rather than market of sale. Jurisdiction rules differ and change. And the schedules do not line up, so one team is assembling four different submissions from four different cuts of the same underlying data.

The usual result is a compliance manager with a spreadsheet, a folder of supplier specs of varying age, and a set of assumptions: average weights applied across a product family, a default recyclability status where nobody knows, and a national sales figure split by a percentage that was calculated once. Under-report and you invite an audit, with back-fees and penalties attached. Over-report and you simply hand over money every single period and nobody ever finds out, because no regulator has ever written to a producer to say they paid too much.

Over-reporting is the more common failure and the quieter one. It happens for a specific reason: when you do not know a component's weight or material, the safe assumption is the conservative one, and conservative assumptions accumulate across thousands of SKUs. A packaging file built on defaults is a standing overpayment, and it grows every time you launch a product.

Problem one: nobody in your company owns the SKU packaging material master

Ask who holds the definitive record of what every SKU's packaging is made of, by component, by material, by weight, and you will get four answers. Procurement has purchase specifications. Product development has drawings. The compliance manager has a spreadsheet. The supplier has the truth and has never been asked for it in a structured form.

The data model is not complicated, and this is why the problem persists: it looks too simple to fund. A SKU has packaging components. Each component has a material, a weight, a recyclability status, a recycled content share where you can substantiate it, and a component role such as primary, secondary or transport packaging. Components can be shared across SKUs, which matters enormously, because a change to one carton specification then updates every product that uses it instead of requiring 300 edits.

The hard part is collection, not storage. Suppliers will not fill in your spreadsheet, or they will fill it in wrongly, and chasing them is the compliance manager's whole quarter. What a custom build does: a supplier portal where each supplier sees only their own components, with validation at entry so a weight in the wrong unit is rejected immediately rather than discovered in an audit. Document extraction handles the rest, reading the specification PDFs and technical data sheets suppliers already send and proposing component records for human confirmation. That is the honest use of AI here. It does not decide anything, it reads the hundreds of documents nobody has time to open and turns them into rows a person approves. Then every field carries a provenance: supplier declared, measured internally, or estimated. Estimated fields are your overpayment, and once they are visible you can attack the largest ones by volume.

Problem two: sales by market of sale, which your ERP (Enterprise Resource Planning) does not record

Fees are owed where the packaging is placed on market. Your sales data records where you shipped. Those differ, and the gap is where both compliance risk and overpayment live.

Concretely: goods shipped to a distributor's central warehouse in one jurisdiction may be sold onward into three. Goods exported are generally not liable in the origin jurisdiction, but they must be excluded on evidence rather than by assertion. Ecommerce direct-to-consumer sales are attributed by delivery address, which your carrier data has and your ERP may not join. Own-brand versus branded goods, and the question of who the obligated party is in a private label arrangement, changes who reports at all.

What a custom build does: an allocation layer between sales transactions and the fee calculation, holding explicit rules per channel and per customer. Distributor volumes allocate on an agreed basis with the evidence for that basis attached. Exports are excluded against export documentation. Direct-to-consumer allocates on delivery address. Private label arrangements are flagged with the contractual position recorded. Every allocation shows its rule and its evidence, which is precisely what an auditor asks for and precisely what a spreadsheet cannot show.

Problem three: the schedules change every year, and eco-modulation raises the stakes

The regulatory landscape here is genuinely moving. In the United States, packaging EPR laws have been enacted in states including Maine, Oregon, Colorado and California under SB 54, with Circular Action Alliance operating as the producer responsibility organisation in several of them. In the United Kingdom, packaging EPR data reporting obligations replaced the older recovery note arrangements. In the European Union, the Packaging and Packaging Waste Regulation continues to tighten requirements, and France applies eco-modulation and marking obligations under its AGEC framework. Canadian obligations run provincially. Fee rates and category definitions are revised on their own cycles. Take your specific obligations from a compliance advisor, since jurisdiction status changes faster than any article stays accurate.

The consequence for software is that the fee logic must be data, not code. A jurisdiction is a record holding material categories, rate per tonne or per unit by category, effective dates, thresholds below which a producer is exempt, and modulation adjustments. Adding a jurisdiction should be a configuration task for a compliance analyst, not a development ticket, because you will be adding them for years.

Eco-modulation is where this becomes strategic rather than administrative. Where fees are adjusted by recyclability, recycled content or design characteristics, the packaging decisions your product team makes have a direct annual cost. What a custom build does that no reporting tool does: model the fee impact of a proposed packaging change before it is made. A design team choosing between two closure types can see the annual fee difference across every jurisdiction at current and proposed volumes. That converts compliance from a cost centre into an input to product decisions, and it is usually the feature that gets the project approved.

Problem four: audit evidence you cannot reconstruct afterwards

An audit asks how you arrived at a submitted number. The answer must be reproducible: these SKUs, these components, these weights, from these sources, allocated to this jurisdiction by this rule, at these rates. If the submission came from a spreadsheet that has been edited 40 times since, you cannot reproduce it, and you will negotiate from a weak position.

What a custom build does: submissions are immutable snapshots. When you file, the system freezes the full calculation with every input value, every source reference and every rule version, and stores it against the filing. Later changes to a component weight create a new version and never alter a filed submission. Restating a prior period becomes a deliberate, documented act with a diff, which is what a regulator expects, rather than a spreadsheet whose history is gone.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A first release with the packaging component master, the supplier collection portal including document extraction, sales allocation by market of sale, and fee calculation with submission output for your main jurisdictions runs $55,000 to $120,000 and ships in 10 to 16 weeks. A full platform adding eco-modulation modelling and design comparison, multi-entity and multi-brand submissions, immutable audit packs, restatement workflow and integration into product lifecycle systems runs $140,000 to $320,000 phased over 6 to 12 months.

What drives cost up here: SKU count and packaging complexity, since a business with 12,000 SKUs and shared components across them is a different data problem from one with 400. The number of jurisdictions, though the second one costs far less than the first because the model is already right. ERP integration quality, because if your sales data cannot be joined to SKU-level packaging without manual mapping, that mapping is the project. And multi-entity structures where several legal entities in a group each have their own obligation.

What keeps cost down: starting with the jurisdictions representing most of your fee exposure and your top SKUs by volume, since packaging fees follow volume closely and a minority of SKUs will carry most of the liability.

When Lorax EPI, Ecoveritas or a consultancy is the right answer

Buy or outsource if you report in one or two jurisdictions, hold a few hundred SKUs, and your packaging is stable. Ecoveritas and Lorax EPI do this work competently, the regulatory content is maintained for you, and that maintenance is genuinely valuable given how often rules change. Reverse Logistics Group is a reasonable route if you want the obligation handled as a service rather than run in house.

Build when two or more of these are true. You report in more than three or four jurisdictions and each submission is assembled by hand. Your packaging data lives in supplier PDFs nobody has read. Your fee exposure is large enough that the difference between estimated and measured weights is worth six figures a year. You want packaging design decisions to be made with fee impact visible, which no reporting service will do for you. Or you have been audited once and found you could not reproduce a submitted number. That last one tends to settle the argument on its own.

How to choose a developer for EPR reporting software

Ask them to model packaging on a whiteboard. Components shared across SKUs, with material, weight, role and provenance on each, is the correct shape. A flat table of SKU with a total packaging weight is what a spreadsheet already does badly, and it will not survive your first eco-modulation calculation.

Ask how jurisdictions are configured. If adding one requires a code change, you are signing up for a development ticket every time a rate is revised, which is annually at best.

Ask how they will get data out of suppliers, since that is the real work. A credible answer includes a portal with validation at entry, document extraction from the specifications suppliers already send, and a provenance flag on every field so estimates are visible rather than hidden among measurements.

Ask who owns the code and the packaging data, and settle it before kickoff. Your component master is an asset that improves for years and feeds far more than compliance, including design decisions and customer sustainability questions. At Digital Heroes the client owns the repository from the first commit.