How to do a physical inventory count on catch-weight items

A seafood and protein distributor closes its warehouse for two days every January to do the annual count. Staff walk the cold room with clipboards, count cases shelf by shelf, and key the totals in against the book quantity. For most of the warehouse this works fine — a case is a case, the count either matches or it doesn't.

Then they get to the salmon and the bone-in chicken thighs, and the clipboard method stops meaning anything. The book says 340 cases. The floor has 340 cases. On paper, that's a perfect count. But the book also says those 340 cases weigh 6,800 kg, and nobody on the floor is weighing anything — they're counting boxes. If the actual cases average 19.4 kg instead of the nominal 20 kg, the real weight on the shelf is closer to 6,596 kg. The count says "matched." The inventory is short by over 200 kg, and the sheet has no way to show it.

Why counting units doesn't count the inventory

This is the trap specific to catch weight. The inventory system already tracks two numbers for every catch-weight item — how many physical units are on hand, and what those units actually weigh, measured at the scale, not assumed from the label. A physical count that only re-verifies the unit number is re-verifying the half of the record that was never in question. The half that drifts — the weight — is the half a clipboard count can't touch unless someone actually puts the product back on a scale.

The drift is real and it's not theoretical. Moisture loss in cold storage, trim loss on product that got repacked, a vendor whose cases run consistently light, a receiving clerk who keyed the nominal case weight instead of the scaled weight six months ago and nobody caught it since — all of it compounds silently because the unit count never flags it. You can run a flawless annual count, every box accounted for, and still be sitting on a cost-per-kilogram number that's been wrong since spring.

The cost of that shows up in two places. First, margin reporting on catch-weight lines is quietly fiction — if the system thinks you're holding more weight than you actually have, your cost per kilogram is understated and every sale against that stock looks more profitable than it is. Second, the eventual correction is ugly: when someone finally re-scales a pallet and finds the gap, it lands as a single large write-off with no paper trail back to when it actually happened, because a unit-only count had no way to catch it along the way.

The turning point: counting the weight, not just the box

The fix isn't a harder count — it's counting the right thing. A physical inventory count on catch-weight stock needs to produce two numbers per lot, not one: the unit count and the measured weight, and the second one has to come off a scale, not out of a catalog.

In practice that means:

• Count and weigh by lot, not by case. Where product shares a lot or batch number, weigh the batch as a whole and divide, rather than weighing every individual case — it's close enough for reconciliation and far faster than weighing piece by piece.
• Record the counted weight separately from the counted quantity. The count sheet (or the handheld scanner screen) needs a field for "weight" next to the field for "units," not a formula that multiplies units by a nominal weight and calls it done.
• Reconcile against measured book weight, not nominal book weight. If the book value was built from scaled receiving weights all along, the comparison is apples to apples. If it was ever built from nominal case weights, the count will surface that gap for the first time — which is the point.
• Flag variance by lot and by vendor, not just in aggregate. A 2% shrink spread evenly across the warehouse is a rounding question. A 6% shrink concentrated in product from one vendor, or one storage zone, is an answer waiting to be found.
• Decide your tolerance before you count, not after. Catch-weight product will never reconcile to zero variance — moisture loss and scale tolerance guarantee some drift. Set a threshold (by weight percentage, not by unit count) above which a variance gets investigated instead of just booked.

None of this requires shutting the floor for extra days. A cycle-count rhythm — a rotating subset of catch-weight SKUs re-weighed every week instead of the whole warehouse once a year — catches the same drift while it's still small enough to explain, instead of waiting for the annual count to hand you a number nobody can reconstruct.

What this changes

Once the count produces measured weight instead of assumed weight, three things follow immediately. The margin report on catch-weight items stops drifting from reality, because cost per kilogram is based on what's actually in the building. Vendor variance becomes visible at the shelf, not just at receiving — if a vendor's product keeps running light after it's already been accepted, that's a storage or handling question, not a receiving one. And the eventual write-off disappears, because small variances get caught and explained lot by lot instead of accumulating into one number nobody can trace.

Takeaway checklist for your next catch-weight count:

1. Every count line for a catch-weight item records both a unit count and a scaled weight — never one derived from the other.
2. Weigh by lot/batch where products share a lot, to keep the count fast without losing accuracy.
3. Compare against measured (not nominal) book weight, so the variance you see is real.
4. Set a weight-based variance tolerance in advance, and route anything above it to investigation by vendor and by zone.
5. Replace (or supplement) the annual full count with a rolling cycle count on catch-weight SKUs, so drift gets caught in weeks, not a year.

In iotoms, every catch-weight item already carries its measured weight from the scale at receiving through to the shelf, so a cycle count compares scanned weight against that same measured book figure — not a nominal one — and any gap shows up immediately, by lot and by vendor, instead of waiting for January to find it.