From SKU-Level to Component-Level Reporting: A Migration Playbook
Most packaging compliance data starts at SKU level because that is what existing systems carry. Component-level reporting is required for accurate filings. Here is how to migrate from one to the other without rebuilding your data systems from scratch.
By Kevin Kai Wong, Managing Partner at gCurv Technologies
April 29, 2026
The starting point
Most producers' first compliance data extract looks the same: SKU-level rows with a single material category, a single weight, and a single recycled content number. That data shape is fine for procurement and inventory. It is not fine for filing.
EPR and PPWR fee schedules are component-level. UK PPT is component-level. PPWR recyclability grades are component-level. SKU-level data forces averaging that produces wrong numbers in both directions, over-paying on some categories, under-paying on others, in patterns that look defensible until they are audited.
The migration from SKU-level to component-level is doable in a quarter. Most of the work is decomposition logic, not new system implementation.
Why SKU-level fails
A typical consumer SKU contains 3 to 8 packaging components: primary container, closure, label, secondary carton, tray, shrink wrap, leaflet, dunnage. They are made of different materials, weigh different amounts, and have different recyclability characteristics.
SKU-level reporting forces the analyst to either:
- Pick a dominant component and report the SKU as that material (under-counts other materials).
- Average across components by weight (produces a category that does not exist, with a fee that matches no real schedule).
- Build component-level data offline in a spreadsheet (the de facto system-of-record problem).
None of these survives audit.
Migration path: four phases
Phase 1: Inventory existing data. For each SKU in scope, enumerate what data you have today. Common state: SKU-level total weight, a single material category, sometimes a recycled content number.
Output: a gap analysis showing what fraction of your SKUs have any component-level data and what fraction have none.
Phase 2: Decompose using design specs. For SKUs with packaging design specs (PLM records, supplier specs, brand books), decompose each SKU into its components based on the spec. Each component gets an estimated weight, material, and recycled content from the spec.
This phase covers the SKUs you can decompose without re-measuring. For most consumer brands, it covers the majority of in-scope volume.
Phase 3: Decompose using physical sampling. For SKUs without usable design specs, common for older products, contract-manufactured items, and acquired brands, pull physical units, disassemble, weigh components, and identify materials. Sampling can be scaled: a few units per SKU is sufficient for compliance accuracy on most components.
This phase covers the long tail. Plan it as a quarterly project, not a one-time blitz.
Phase 4: Operationalize. Build the component-level data into your system of record. Update PLM or ERP records. Define the change process for new SKUs and reformulations so future products are component-decomposed at design time, not retroactively.
Output: every in-scope SKU has component-level data on file, with clear provenance (design spec vs sample-based vs supplier-stated).
Practical decisions during migration
How many components per SKU? Capture every component that contributes meaningfully to packaging weight or carries a distinct material. Microscale items (a tiny tamper seal, a strip of glue) can roll up into the parent component if they would not change a category determination.
What materials to track? Every distinct material category in your jurisdictional taxonomies, plus sub-material composition where it matters for "predominantly plastic" determinations or for recyclability grading.
How to handle supplier variation? Where a component is sourced from multiple suppliers with different specs, treat each variant as a separate component record with effective dates and supplier references. Do not average across suppliers.
What level of accuracy? Compliance accuracy, not engineering accuracy. Weights to the nearest gram are usually sufficient; recycled content to the nearest percentage point. Higher precision than the regulator requires is wasted work.
Common pitfalls
Pitfall 1, Trying to migrate everything at once. Migrate by volume first. Top-volume SKUs deliver most of the compliance value. The long tail can be sample-based later.
Pitfall 2, Decomposing without keeping SKU-level totals. Reconciliation requires both. The component decomposition has to roll up to the SKU weight that finance and operations already use.
Pitfall 3, Skipping evidence references. A component's material classification needs a source, design spec ID, supplier letter ID, sample test ID. Without it, the decomposition is unverifiable.
Pitfall 4, Not updating the change process. New SKUs designed in PLM after migration should be born with component-level data. If the new-product process still produces SKU-level rows, the migration is one-time-only and the gap reopens.
What this means operationally
The migration is mostly project management, not technology. Once the data shape is right, existing tools can carry it. The hard part is governance: enforcing component-level capture going forward, refreshing it when designs change, and reconciling against SKU-level totals consistently.
What to do in 2026
- Inventory your SKUs by data shape (SKU-level only vs partial component-level vs full component-level).
- Sequence the migration by in-scope volume and by jurisdiction priority (UK and EU markets typically first because of PPT and PPWR pressure).
- Update your new-product introduction process before completing the migration, so the gap stops growing while you close it.
- Reconcile component sums to SKU weights as a standing data quality check.
How Packgine helps
Packgine ingests both SKU-level and component-level data, surfaces the gaps, and supports the migration phase by phase. Component decompositions captured during migration become reusable assets, once a component is on file, every SKU that uses it inherits the data automatically.
Related reading
Ready to automate your packaging compliance?
See how Packgine manages EPR, PPWR, and sustainability reporting from a single dashboard.
