How to calculate packaging weight for EPR from Shopify order data

This picks up after you have established that you owe EPR somewhere. If you are not there yet, start with do you need to register for EPR, because the answer changes which countries you have to do any of this for.

What a declaration actually asks for

Start with what Germany actually asks for, because it is the clearest published example and it is not what people expect. A LUCID data report has no SKU column. It consists of the reporting period, the name of the system you signed a participation agreement with, and then the material types with the mass placed on the market per material type, expressed in kilograms to three decimal places.

That is the whole shape of it. Paper, paperboard and cardboard; plastics; ferrous metals; glass; and so on, each with one number beside it. There is no product name, no SKU column, no order id.

Do not read that as the universal format. Other schemes structure declarations differently, and France's Citeo, for instance, works partly from consumer sales units and sector rather than mass alone. Treat weight by material as the underlying dataset every scheme is built on, then map it to whatever each country's form actually asks for.

There is a scope limit here that trips people. LUCID's data reporting covers packaging that is subject to system participation, which is retail, grouped and shipment packaging that typically ends up as waste with private consumers. Not everything in those categories qualifies, and transport packaging and reusable packaging are handled separately. The pallet your stock arrived on is not part of this number.

Why Shopify's weights are the wrong number

Shopify does hold weights, which is exactly why this trips people. It holds a weight on the product or variant, and separately a weight on the packages you define for shipping. For weight-based shipping rates it adds them together: Shopify's own example is 4.9 kg of products in a default package weighing 0.1825 kg, giving 5.0825 kg and pushing the order into a higher rate band.

That is a perfectly good shipping calculation and a useless EPR one, for three reasons:

1. Product weight is a single undecomposed number. Whether it includes retail packaging depends entirely on how whoever entered it was thinking that day, and Shopify cannot tell you which part is product and which is wrapper.
2. A package is one total weight, with no material breakdown. A package record carries a name, a type, dimensions and a weight. There is no field for cardboard versus plastic, and EPR is settled per material.
3. The package chosen at checkout is not proof of what shipped. It feeds a rate calculation. If you buy labels through Shopify the Shipping labels by order report does preserve the package name, type, dimensions and total weight per order, which is genuinely useful; buy labels anywhere else and that record lives with your carrier or 3PL, not in Shopify.

So the material breakdown does not exist in the store and cannot be derived from it. It has to be authored once, then joined to data the store does have.

Build a packaging bill of materials

The unit of work is a packaging profile: a named, reusable spec made of components, each with a material and a weight. Not a weight per product, a profile shared by every product packed the same way. That reuse is what makes the job tractable, because a catalogue of hundreds of SKUs may pack into only a handful of distinct ways. Count your actual box and mailer types before assuming the work is proportional to your catalogue. Watch for variants here too: if the large size ships in a different box from the small, they need different profiles even though they are one product.

Two rules make the difference between a dataset that survives a query and one that does not. Never merge materials into one row, however small the plastic component is, because the whole declaration is organised by material. And weigh, do not estimate, wherever weighing is possible. A kitchen scale accurate to the gram costs less than an hour of anyone's time, and estimates are the first thing challenged.

Where you genuinely cannot weigh something, for example stock already shipped in a period you are now reporting, write down the basis of the estimate next to the number: supplier spec sheet, weight of an identical current item, or a measured sample of ten averaged. The estimate is not the problem. An estimate nobody can trace back is much harder to defend.

Product packaging and shipment packaging are different layers

This is where double counting creeps in. Two distinct things get called packaging and they attach to different quantities:

• Product packaging travels with the item. Every unit sold carries it, whether it went out alone or with five other things. Multiply by units sold.
• Shipment packaging is the outer parcel, and there is one per shipment, not one per unit. Multiply by shipments, never by units.

Join it to orders, and to the country that actually received them

Now the arithmetic. Three steps, and the third is the one people get wrong:

1. Product packaging: for each SKU, units sold in the period multiplied by each component weight in its profile.
2. Shipment packaging: shipments in the period multiplied by each component weight of the parcel profile used.
3. Group by destination country, then by material. Not billing country, not the customer's account country. EPR follows where the goods physically went.

Shopify gives you the first quantity cleanly. The Orders export carries line items with quantities and a shipping address, so units sold per SKU per destination country falls straight out of it.

The other thing Shopify cannot tell you is which parcel profile a given shipment used. If you run more than one box size, that mapping has to come from somewhere: a rule based on order size, your 3PL's records, or a note kept at packing time. Decide the rule before the period starts, not after.

A worked example

Take one quarter, Germany only, one SKU packed in the Boxed item profile above, 500 units sold across 400 shipments, all shipped from outside the EU into Germany.

Aggregate that to what a report wants, and the whole quarter for that SKU collapses to two numbers: paper and cardboard 99.500 kg, plastic 3.000 kg. Note the three decimals, which is the precision LUCID asks for. Note also what one wrong multiplier costs: bill the box against 500 units instead of 400 shipments and it becomes 105.000 kg instead of 84.000 kg, so you declare and pay for 21 kg of cardboard that was never placed on any market, from a single SKU in a single quarter.

Validate the totals before anyone else does

• Every component has a material, and no row mixes two materials
• Shipment packaging multiplied by shipments, product packaging by units
• Grouped by destination country, not billing country
• Totals in kilograms, to three decimals where the scheme asks for it
• Every weight traceable to a scale reading or a written basis of estimate
• The period matches the one in your system participation agreement
• Products added mid-period have a packaging profile assigned

One sanity check catches most errors in one move: total your declared packaging mass and compare it to the total shipped weight of the same orders. Packaging should be a plausible fraction of it. If your packaging total approaches or exceeds the shipped weight, something is multiplied by the wrong quantity.

Keeping it true after the first time

The dataset decays in a specific way: new products arrive with no packaging profile, and there is no error when that happens. They simply contribute zero, so the declaration quietly understates. The same applies when you switch mailer supplier and the new bag is 4 grams heavier.

This is the part Assuro models directly, and it is worth describing plainly because it is the shape any solution needs, spreadsheet or otherwise. Packaging profiles are made of components, each with a material and a weight in grams. Products link to a profile with a quantity. A declaration is scoped to one country and one period, and its lines carry units placed on the market, so the per-unit grams by material are derived from the profile rather than retyped.

The limits matter as much as the shape. That model computes the product layer, units multiplied by component weight. There is no separate shipment object, so parcel packaging is not automatically billed against shipments rather than units, and that layer is still yours to handle deliberately. Packaging attaches at product level, not variant, so a product whose sizes ship in different boxes cannot be represented as two profiles. Assuro does not submit anything to a scheme, and it cannot know that your supplier quietly changed the mailer.

Whatever you use, the discipline is the same: assign a profile at the moment a product is created, re-weigh when packaging changes, and keep the derivation, not just the answer. The GPSR side of the same catalogue, where the data goes onto the product page rather than into a return, is covered in how to bulk add GPSR information to Shopify.