The Packaging Data Model: What Fields You Actually Need at SKU and Component Level
Most packaging data systems were designed for procurement, not for compliance. Here is the field-level schema you need at SKU and component level to file across UK PPT, EU PPWR, and US state EPR without re-mapping every period.
By Kevin Kai Wong, Managing Partner at gCurv Technologies
May 8, 2026
Table of Contents
Why the data model matters more than the tool
Compliance teams often start a tooling search before they have a data model. The result is predictable: whichever tool they pick, the next quarter is spent hand-building data flows because the source systems do not carry the fields the tool expects.
Defining the data model first, what you need at SKU level, what you need at component level, and how the two relate, is what makes the tooling decision boring. With the model in place, ingestion becomes a mapping exercise, not a redesign.
The two-tier structure: SKU and component
A SKU (or stock-keeping unit) is the saleable item, a 500ml bottle of shampoo, a 12-pack of beverage cans, a single shipper of a consumer electronic. A SKU is composed of one or more components, a bottle, a closure, a label, an in-box leaflet, a corrugated case.
EPR/PPWR fees are levied on packaging. Packaging is composed of components. Filing accurately requires component-level data with traceability up to the SKU and down to the supplier batch.
A SKU-only data model cannot file accurately. A component-only data model cannot reconcile to sales volumes. You need both layers, with a clean parent-child relationship between them.
SKU-level fields
At the SKU level, the model needs:
- SKU identifier. A stable internal ID, usable as a join key across systems.
- Brand and product family. For producer-determination logic and reporting roll-ups.
- Legal entity owning the SKU. The entity that is the producer in each jurisdiction. Not always the same as the brand, common divergence in private label and licensee scenarios.
- Sales channel. Retail, ecommerce, wholesale, B2B, foodservice, marketplace. Drives household vs non-household stream allocation and producer-determination logic.
- Countries of sale, with volume splits. Per period, per country. Drives jurisdictional allocation of tonnage. "Sold in EU" is not enough; you need member-state-level splits.
- Period volumes. Units shipped, units placed on market, by period and by country.
- Lifecycle status. Active, discontinued, reformulated, regional variant. Affects whether old data still applies.
- Producer determination, per jurisdiction. Whether your legal entity is the producer in California, Oregon, the UK, Germany, France. Cached, with the rule that produced the answer.
Component-level fields
At the component level, the model needs:
- Component identifier. Stable internal ID, joinable to BOM data.
- Parent SKU(s) and quantity per SKU. A component can serve multiple SKUs; the BOM relationship has to carry quantity.
- Component type. Bottle, closure, label, sleeve, liner, carton, tray, divider, dunnage, etc.
- Material category, mapped to each jurisdiction's taxonomy. Internal "PET bottle" mapped to UK pEPR "rigid plastic", to PPWR "rigid plastic packaging", to CA SB 54 category, to Maine category. The mapping is the most error-prone field; record the rule, not just the answer.
- Sub-material composition. For composites: layer-by-layer or fraction-by-fraction breakdown. A "predominantly plastic" determination depends on this.
- Component weight. Per-unit weight in grams or kilograms, with measurement methodology (designed weight vs measured weight vs supplier-stated weight).
- Recycled content percentage. With evidence reference, post-consumer vs pre-consumer split, and methodology (mass balance vs segregated).
- Recyclability attributes. Color, label coverage, closure compatibility, additives that affect recyclability, the inputs to PPWR A/B/C grades and UK RAM scoring.
- Reusable / refillable status. For PPWR sectoral targets.
- Supplier and supplier-site reference. For evidence chain traceability.
Cross-cutting fields
Several fields sit across both layers or attach to relationships rather than to a single record:
- Effective dates. Every spec change, weight, recycled content, supplier, needs an effective date, not an "as of last update" timestamp.
- Evidence references. Pointers to supplier declarations, certificates, test reports. The evidence belongs in document storage; the reference belongs in the data model.
- Audit history. Who changed what, when. Required for regulator response.
Common gaps in existing data systems
Producers usually find their existing systems are missing:
- Component-level breakdown (most BOM systems have it; most procurement and finance systems do not).
- Country-of-sale at the SKU-period level (sales systems usually have it; it does not always make it to the compliance system).
- Recycled content evidence references (treated as supplier correspondence, not as structured data).
- Mapping of internal material categories to jurisdiction-specific taxonomies (often hardcoded in spreadsheets, not in a system).
- Effective dates on spec changes (often overwritten in place).
What this means operationally
Building the data model is not a documentation exercise. It is a system design that determines which compliance questions you can answer in 24 hours and which take six weeks of supplier email.
The model should be:
- Source-system agnostic. It describes what you need, not where it currently lives.
- Jurisdiction-extensible. New states and new countries should slot in as additional taxonomy mappings, not as new schemas.
- Evidence-aware. Every claim that can be challenged should have a reference to its evidence.
What to do in 2026
- Define the SKU and component fields you need before evaluating tools.
- Audit your existing source systems against the model. The gaps tell you the integration work required.
- Treat material-category mapping as a first-class data asset, not a one-off mapping exercise.
- Stop overwriting spec history. Effective dates are how you defend prior-period filings.
How Packgine helps
Packgine implements this data model out of the box, with jurisdiction-specific taxonomy mappings already defined, effective-dated spec history, and evidence references attached at the component level. You bring your source-system extracts; Packgine produces the filing artifacts each jurisdiction wants.
Related reading
Ready to automate your packaging compliance?
See how Packgine manages EPR, PPWR, and sustainability reporting from a single dashboard.
