How to set up a catch-weight item so the conversion doesn't drift

A cheese and dairy distributor running six vans added a new SKU: aged wheels bought from the vendor by the piece, sold to delis and restaurants by the kilo. Someone in purchasing set it up the way every other item in the system got set up — pick a unit, enter a price, done. For "unit," they used "wheel." For the conversion, they typed in the number off the vendor's spec sheet: 1 wheel = 4.2 kg. Clean, simple, one line in the item master.

It worked for exactly as long as every wheel actually weighed 4.2 kilos. None of them did. Real wheels ran anywhere from 3.8 to 4.6 depending on the batch, and the system had no way to know that, because nobody had told it there were two different numbers in play — a planning figure and a measured one. It only had the one the setup screen asked for, so that's the number it used everywhere: the pick list, the invoice, the margin report, the reorder point.

One field was doing the job of two

A catch-weight item needs two units and a conversion between them, not one unit and a fixed number. The stocking unit is what the warehouse counts and picks — in this case, wheels. The weight unit is what the customer is actually billed on — kilos. The conversion between them isn't a fixed rate like "1 case = 12 bottles"; it's an expected value, because the whole premise of catch weight is that the real number only exists once something gets weighed. That expected value has a name in most systems that model this correctly: nominal weight. It's a forecast, not a fact, and it's only supposed to be used for planning — sizing an order, estimating a load, projecting a reorder point — never for what actually goes on an invoice or hits the ledger.

The distributor's setup collapsed that distinction. Because the item master only carried one weight-per-unit figure, and nothing downstream distinguished "expected" from "measured," that 4.2 kg conversion was quietly doing double duty. It sized purchase orders, which is a reasonable use. But it also populated the sales order before a wheel had ever touched a scale, and in a few reports it never got corrected after the real weight came in, because the scale event and the nominal figure both wrote to the same field and whichever one landed last won.

The drift was invisible until the reports stopped agreeing

For two months nothing looked wrong, because the aggregate numbers were close enough on average — some wheels ran heavy, some light, and across a hundred wheels it mostly washed out. What didn't wash out was anything measured at the edges: a restaurant that ordered six wheels in one delivery got billed on six nominal weights if the driver's handheld hadn't synced the day's scale readings yet, and the invoice was wrong by however far that batch actually ran from 4.2. The margin report, which pulled cost against the nominal weight instead of the measured weight received, slowly diverged from the accounting ledger, which had the vendor's actual invoice. Nobody could say with confidence which number was the real one anymore, because by that point three different screens each had their own idea of what a wheel weighed.

The turning point was a customer who flagged a delivery as overbilled, pulled out their own receiving scale, and was right. That forced the question the item setup should have answered on day one: which weight is the planning number, and which one is the real one, and does every downstream process know the difference?

Fixing the setup, not patching the reports

The fix wasn't a new report reconciling the two numbers after the fact — that just institutionalizes having two numbers. It was setting the item up with the distinction built in from the start:

• Two units, explicitly. A stocking/transaction unit (wheel, case, each) and a weight unit (kg, lb) — never one field asked to be both.
• A conversion used only for planning. The nominal weight sizes purchase orders, projects a reorder point, and estimates a load — and is labeled clearly enough in the system that nobody mistakes it for a billed quantity.
• A real weight captured at every scale event, and that figure — not the nominal one — is what flows to the invoice, the ledger, and the margin report. Receiving and shipping are both scale events; each one should overwrite the planning figure with a measured one, not average against it.
• A variance that's visible, not silent. The gap between nominal and measured, per vendor and per SKU over time, is useful data — it tells you when a vendor's grading has shifted. It should show up somewhere a buyer looks, not get buried in a conversion field nobody rechecks.
• No retrofitting an existing item. Flagging a product catch-weight after it already has transaction history, or after it's tied into a batch/lot scheme built for fixed quantities, tends to create exactly the kind of mixed-signal field this distributor ended up with. Get the unit structure right before the first PO goes out on that SKU, not after.

Takeaway

If a catch-weight item in your system has one weight-per-unit field doing the job of both a forecast and a fact, that's the setup to fix before it shows up as a customer dispute. The checklist: separate stocking and weight units, keep the conversion labeled as a planning estimate only, let every scale event overwrite it with a real number downstream, and track the variance between the two instead of letting it disappear. iotoms models catch-weight items with that separation from the item master down — nominal weight sizes orders, but every receipt and every sale carries its own measured weight straight through to the invoice and the ledger, so there's never a question of which number was real.