EPR Packaging Compliance Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the packaging data model get built on the SKU?

Because that is where packaging already lives in your systems: a note on a product record, a field on an item master, a line in a specification. So a developer models packaging as attributes of a finished good, and the first report comes out. Then somebody changes a bottle weight and the correction has to be applied in forty places.

Compliance is calculated on components, not on products. One finished good carries a primary container, a closure, a liner, a label, sometimes a sleeve, an inner carton, a shipping case, an interleave and stretch wrap. Each has its own material, weight, recycled content and, under several regimes, its own recyclability assessment. Many are shared across dozens of items, which is exactly why the SKU level model fails: a shared component correction should ripple through the portfolio and instead gets fixed in one row.

The model that works is a packaging component master as first class data, with a bill of packaging per SKU referencing components and quantities. Every weight carries a source, a date, a link to the evidence document it came from, and a verified flag that only a laboratory weighing or a signed supplier specification can set. The first benefit is not the report. It is that you finally know which of your weights are measured and which are somebody's estimate from four years ago, and in our experience that split surprises everyone in the room.

What goes wrong when you migrate component weights and prior submissions?

The spreadsheet migrates cleanly and that is the trap. What you inherit is a set of numbers with no provenance: nobody can say which weight came from a supplier specification, which was measured, and which was typed by a coordinator who has since left. Importing that as though it were verified data gives four year old guesses the authority of a system of record, and every downstream fee calculation carries the error forward silently.

Treat migration as a triage rather than a copy. Load the existing figures as unverified by default, then run a physical weighing programme against your highest volume components while the build proceeds. That programme is operations work rather than software work, it is the single largest determinant of how long the project takes, and it belongs on your plan rather than the developer's.

Prior submissions are the second layer and they should not be recomputed. A report filed two years ago was correct under the mappings, categories and volume rules in force then. Store it as an immutable snapshot capturing the component weights, the mapping version, the attribution rules and the volume data exactly as they stood at filing, and never let it be regenerated from today's data. If the historical detail is not recoverable, archive what you filed as a document alongside a note explaining the gap, which is a far better answer to a scheme query than a number that no longer reproduces.

Why do enterprise system and supplier document feeds break after launch?

The enterprise system feed breaks on meaning rather than mechanics. SAP, Oracle and Microsoft Dynamics all hold sales and item data differently, and the fields your attribution logic depends on are the ones most likely to be repurposed: a plant code reused after a site closes, a customer group redefined during a reorganisation, a new sales channel added without a corresponding rule. Nothing errors. Volume simply stops being attributed, or gets attributed to the wrong obligated entity, and you find out at the next reporting cycle.

Guard it by making the unattributed remainder visible rather than dropping it. Every reporting run should report how much volume could not be confidently placed, and that figure should be watched between cycles rather than discovered during one. On first runs it is normal to find several percent of volume nobody can place, and resolving it is usually worth more than every efficiency gain in the workflow.

Supplier document extraction breaks differently. Specification sheets arrive in every layout imaginable and suppliers change their templates without telling you, so an extraction that read a component weight reliably last quarter starts pulling a gross case weight instead. Never let a model write a value directly. Extract with a confidence score, flag where a new specification differs from the version you previously accepted, and route the difference for human review. A weight that quietly dropped from 24 grams to 21 grams matters in both directions, and catching the change is more valuable than the extraction itself.

What happens when volume attribution across group entities is not covered?

Most proposals in this category concentrate on material data because it demonstrates well, and skip attribution because it is unglamorous. That is backwards. The obligation attaches to the entity that first places packaging on a market, and that is often not the entity your sales report shows. Group companies sell to each other. An importing subsidiary may be obligated in one country while the brand owner is obligated in another. Private label changes who owes. Exports come out. Marketplace sales can shift obligation depending on the regime.

Returns and write offs are the quiet one. A credit note should reduce declared volume and almost never does, because nobody wired the finance event back to the packaging calculation. Over a year that is a permanent overpayment on goods you did not sell.

What works is an explicit attribution engine: rules that assign each movement to an obligated entity and a market, written so your regulatory lead can read and change them without a developer, with the unattributed remainder surfaced. Alongside it, hold your internal material taxonomy as the master and map to each scheme's categories per reporting year, versioned. That mapping layer is the difference between adding a jurisdiction as configuration and adding it as a project, and it is also what lets you produce a modelled fee delta when a technologist asks what a label change would cost across every market.

Should you build custom or configure what you already own?

If you sell in one or two markets with a few hundred SKUs and stable packaging, stay with a compliance scheme provider. Ecoveritas, Landbell Group and similar firms know the regimes, file on your behalf, and cost a fraction of a development budget. A build at that scale is a poor use of capital and you will not report better than they do.

Before commissioning software, exhaust what you already have. Source Intelligence and comparable platforms handle supplier document collection, which is a real part of the problem, and many enterprise systems can hold a component structure if somebody configures one rather than using a free text packaging note. The honest boundary of the provider model is scope rather than competence: they compute from the data you hand them, so unverified weights and unresolved attribution stay yours, and nobody owns the fix. Test whether your complaint sits inside or outside that boundary before you spend anything.

Build when two or more hold. You report into more than three jurisdictions. Your group has several obligated entities with intercompany flows. Packaging design changes often enough that eco modulation is a live commercial question rather than an annual one. You have been queried on a submission and could not reproduce the number quickly. Or your annual fee bill is large enough that a one percent data error costs more than the build.

How do hidden costs get into the quote?

Jurisdiction count is the first and it is routinely underpriced. Each regime brings its own categories, calendar, obligation rules and marking requirements, and none of it is a settings change. Get the markets named in scope with their reporting years, and add a maintenance line, because categories are revised and the revision is not a bug fix.

Enterprise integration is the second. A quote saying integration with your enterprise system usually covers reading a sales extract. What costs the weeks is the attribution logic sitting on top of it: intercompany flows, private label, exports, marketplace channels and credit notes. Price that as its own workstream.

Data readiness is the third and it lands on you rather than the developer. If half your component weights are estimates, the weighing programme is real cost in operations time and it gates the value of everything else. Fourth is group consolidation across obligated entities, which is genuinely intricate and is not a reporting filter. Fifth is the eco modulation engine, if you want scenario modelling rather than reporting, since it needs the fee rules held as data rather than as report logic. Sixth is the extraction review workflow, because somebody has to look at the flagged differences, and a build with no reviewer is a build with no controls.

What separates a build that works from one that fails here?

The ones that work take two markets and the top two hundred SKUs by volume for the first release, and finish them. That usually covers the large majority of fee exposure and surfaces every structural problem you have. The ones that fail attempt every jurisdiction, every SKU and supplier document capture at once, and spend a year producing a system that reports the same unverified numbers faster.

Ask a developer to draw the data model before you sign. The correct sketch has a packaging component separate from a SKU, a bill of packaging joining them, a canonical material taxonomy, and a scheme mapping table versioned by reporting year. If they propose putting a scheme's categories on the product record, every new jurisdiction will be a rebuild and you will pay for it twice.

Ask how they handle restatement. Someone who has built regulated reporting describes immutable snapshots and reason coded corrections without prompting. Someone who says the report is generated live has not been through an audit.

Keep the category decision with a human. Extraction is the right job for a model, category assignment is not, because it is a legal interpretation with money attached and it belongs in a mapping table your regulatory lead can point an auditor at.

Settle ownership in writing before kickoff: the repository, the cloud accounts and any extraction models trained on your supplier documents. At Digital Heroes the client owns all of it from the first commit. In a compliance system a dependency on your developer is a regulatory risk, not only a commercial one.