How to calculate cost of goods sold when your inventory is catch weight

A cheese and charcuterie distributor supplying delis and small grocers out of a single cold-storage depot closes its books the way most growing distributors do: monthly, by hand, from whatever the ERP hands the accountant. Wheels of cheese come in by the case at a nominal weight the vendor prints on the box — say 18 kg a case — and the purchase price is quoted per kilogram against that nominal number. The accountant posts cost of goods sold the same way every month: cases shipped times nominal weight times standard cost per kilogram. It is a clean formula, it runs in seconds, and it is wrong on every single case, because no wheel of cheese actually weighs 18.00 kg.

Where the number quietly drifts

The gap starts at receiving. A vendor's cases of aged cheddar run anywhere from 17.1 kg to 19.4 kg once they hit the dock scale, but the goods-receipt entry books the nominal 18 kg regardless, because that is the only number in the PO. Cost per case gets fixed at receiving; weight never gets corrected against what was actually measured. Multiply that by 40 cases a week and the distributor is posting a cost of goods sold figure that has never once matched the kilograms that physically left the cold room.

It compounds on the sales side too. The counter sells cheese by the gram — a customer wants 2.3 kg of the aged cheddar, not a whole case — so revenue is booked against real, measured weight. Now the mismatch is structural: revenue is weight-accurate, cost is not. Margin, which is just revenue minus cost, absorbs the entire error. Some months it overstates margin, some months it understates it, and there is no pattern to it because the drift is random case-to-case variance, not a fixed bias anyone could adjust for after the fact.

For a while this doesn't matter enough to notice. The numbers are close enough for a gut check, and nobody reconciles cost of goods sold against a physical weight count line by line. It surfaces at the moments when the number actually gets used for something: a bank renewing a line of credit and asking for a gross margin trend, an accountant preparing year-end and needing inventory valuation to tie to a physical count, a new item that turns out to be far less profitable than the reports ever showed once someone finally checks it against real weight.

The turning point

That's roughly what happens here. The distributor's year-end physical count comes in meaningfully under what the ledger says should be in the cold room, and the accountant can't explain the gap with shrinkage or theft — there's no missing product, just missing kilograms that were never posted correctly in the first place. Reconstructing months of receiving tickets by hand to find where nominal weight diverged from scale weight takes a week and still doesn't fully close the gap, because the paper tickets weren't kept with that level of precision. The distributor ends the exercise with a hard rule: cost has to be tracked by measured weight, at the point it's measured, or the number is fiction dressed up as accounting.

How costing by measured weight actually works

The fix isn't a spreadsheet adjustment — it's changing which number the system treats as real at each step:

• Receiving books the scale reading, not the PO number. Each case crosses the dock scale, tare is netted out, and the measured net weight — not the nominal weight on the box — is what posts to stock and what the landed cost per kilogram is calculated against.
• Cost is a weighted average of measured weight, updated on every receipt. When a new delivery comes in at a different price or weight than what's already in stock, the average cost per kilogram recalculates against the combined measured weight on hand, not the case count.
• Every sale draws against that same measured pool. Whether the counter sells 2.3 kg loose or a shop takes a full case, the cost posted to that sale is the current weighted-average cost per kilogram times the actual weight sold — the same unit the revenue side is already using.
• Inventory valuation and cost of goods sold reconcile to the same measured numbers, so a year-end physical count checks against a ledger that was never fed a nominal-weight fiction to begin with.

Once cost and revenue are both keyed to measured weight, margin stops absorbing the receiving error, and it stops drifting in a direction nobody can predict or explain at close.

Practical takeaway

If you distribute anything sold by weight, check these before your next close:

1. Does your system record scale weight at receiving, or does it carry the PO's nominal weight forward? If it's the latter, your cost basis was wrong before the product even reached the shelf.
2. Is cost of goods sold calculated from the same weight unit as revenue? Costing by case while billing by kilogram guarantees a mismatch that shows up as unexplained margin swings.
3. Does your average cost recalculate on every receipt, or only periodically? Stale average cost understates or overstates COGS for every sale until the next update.
4. Can your year-end physical count tie back to ledger weight, not just ledger case count? If it can't, you have no way to tell shrinkage from a costing error.
5. Do vendor price changes and weight variance hit the ledger at the same event — the goods receipt — or does one lag the other and create a reconciliation gap every month?

In iotoms, catch weight is the costing model, not a report run after the fact: goods receipt captures measured weight per case, average cost per kilogram recalculates on that same event, and every sale — case or loose gram — draws cost from the identical measured pool that revenue is billed against. Cost of goods sold and inventory valuation come out of the same numbers the scale actually read, so a physical count has something real to reconcile against.