Packaging master data vs EPR spreadsheets

The spreadsheet is a snapshot, not a record

An EPR spreadsheet answers one question at one moment: what did we supply in this period. It is built by copying values out of supplier PDFs and emails, it is reconciled against sales, it is submitted, and then it stops being true. The next round starts by asking which rows are still accurate, which is the same as starting again.

Packaging master data answers a different question: what is each product packaged in, what was it packaged in last March, where did each fact come from and who confirmed it. Reporting becomes a query over that record. So does RAM assessment, fee forecasting and redesign modelling, which is why they stop disagreeing with each other.

Reusable architectures

Beauty ranges are combinatorial. One 30 ml dropper bottle architecture might carry twelve serums; one 24/410 pump appears on forty body products; one folding carton size covers a whole gifting range with different print. A spreadsheet stores those facts once per SKU, so a range of 600 SKUs holds perhaps 4,000 component rows, most of them duplicates of each other, each free to drift.

A pack architecture is defined once and shared by every product that uses it. Correcting the pump weight corrects it everywhere. Recording that the dropper bulb is a thermoset answers the RAM question for every serum at once. The effort of getting a fact right is paid once and reused, which is the only way supplier data collection ever finishes.

Revisions with effective dates

Packaging changes mid-year, and EPR reports periods. Those two facts are irreconcilable without versioning. A revision is a snapshot of an architecture that moves through draft, review and published states; publishing stamps an effective-from date and supersedes the previous revision.

That gives you the thing a spreadsheet cannot: a defensible split. If the closure changed from aluminium to PP in March, units supplied before that date carry one weight and one RAM rating and units after carry another. It also lets you model without risk, because a scenario is a version cloned for what-if work that can never be assigned to a live product.

Provenance

A number without a source is an opinion. Every fact worth reporting should carry where it came from, what evidence supports it and how far that evidence has been checked: from unreviewed, through supplier declared, to confirmed by your organisation or independently verified, with rejected and expired as real states rather than deletions.

Evidence types follow the same discipline. A supplier specification, a material statement, a wash-off test report, a recycled content certificate, a packaging drawing and take-back scheme evidence are different things with different weight, and a RAM assessment that rests entirely on unreviewed declarations should look different from one resting on test reports. The point is not paperwork for its own sake. It is being able to answer, quickly, why a pack was rated the way it was.

Why history matters

Regulators expect producers to be able to evidence what they reported, and to keep the underlying records for a period after submission. Check the current retention requirement for your obligations rather than assuming a number, and then build for it, because a retention requirement is only satisfiable if the record shows the state of the world at the time, not the state today.

A superseded revision is not clutter. It is the answer to a query about a period two years ago, and it is the difference between a query taking an hour and taking a fortnight of email archaeology.

Migrating without a big-bang project

Nobody has the appetite to model 900 SKUs before getting any value. Sequence it instead.

1. Start with tonnage. Rank SKUs by packaging weight supplied. The top fifty usually cover most of the fee exposure and most of the RAM risk.
2. Import the skeleton. Products first, then components, from the spreadsheets you already have. Accept that the imported data is unreviewed and label it that way.
3. Deduplicate into architectures. The same pump, jar and carton will appear repeatedly. Consolidating them is the step that reduces future work most.
4. Attach evidence to the shared parts. One supplier request now covers dozens of SKUs.
5. Run one reporting round in parallel. Keep the spreadsheet as the source of truth for a single cycle, reconcile the two, and investigate every difference. The differences are usually real errors in the spreadsheet.
6. Switch the source of truth, then backfill the tail. Long-tail SKUs can be added as they come up for artwork or specification change.

Checklist

• Rank by tonnage before you decide where to start.
• Model shared components once and share them, rather than per SKU.
• Publish revisions with effective dates instead of editing values in place.
• Record source, evidence and verification status for every fact that drives a rating.
• Confirm the retention period that applies to you, and keep superseded versions.
• Run one cycle in parallel before retiring the spreadsheet.

If you want to see the shape of the data before committing to a migration, start with one brand and a handful of architectures.