Why catch-weight inventory keeps losing weight after it's already been received

A seafood and poultry distributor runs a single cold room behind the dock, feeding four vans and a small counter trade. Receiving is tight here — every case gets weighed in, expected weight against measured weight, tare netted out, variance logged per vendor. It's the kind of operation that already caught its vendor short-shipping months ago and fixed it. Receiving isn't the problem.

The problem shows up three weeks later, in a different report. A pallet of whole chickens that came in at 412 lb gets pulled for a van load-out, and the scale at pick says 401 lb. Nobody moved it in between. No line was voided, no case went out the back door, no driver's tally is off. The inventory system says 412 lb should still be sitting there, because nothing was ever recorded against it — no sale, no transfer, no adjustment. The scale disagrees by eleven pounds, and the manager's first instinct is the same one every distributor reaches for: someone's stealing, or someone miscounted at receiving.

The shrinkage that isn't theft and isn't a bad count

It's neither. It's moisture. Poultry, seafood, and fresh cheese lose weight simply by sitting in cold storage — ice crystals sublimate, moisture evaporates through the packaging, and a product that was accurately weighed on day one is a genuinely lighter object by day twenty-one. This isn't a measurement error at receiving and it isn't shrink in the loss-prevention sense of the word. The product that left is less product than the product that arrived, and no scale reading at either end was wrong.

The trouble is that most catch-weight systems only capture weight at two moments: when it comes in the door, and when it goes out. Everything in between is assumed static. So the system's book weight for that pallet never moves after receiving — it just sits at 412 lb until something forces a recount. When the pick finally happens and the real scale says 401, the system has no vocabulary for "the product changed while no one was looking." It logs a variance, and a variance with no transaction behind it reads exactly like theft or a counting error, because those are the only categories anyone's built a report for.

That's what makes this expensive in a specific way: it trains people to distrust the wrong signal. A manager who chases three of these "shrinkage" events back to nothing — no missing case, no bad count, no dishonest employee — starts assuming every catch-weight variance is just noise in the system. That's the moment real theft or a real receiving error gets waved through, because the alarm has cried wolf on moisture loss so many times nobody checks it anymore. The fix for moisture loss and the fix for theft are completely different, and treating them as the same problem means neither one gets solved.

Separating the two, in practice

The distributor's cold room manager eventually stopped trying to explain every variance as a single cause and split the problem in two.

Track expected loss by product, not as a universal shrink rate. A block of aged cheese loses moisture at a different rate than a case of ice-glazed fish, which loses weight differently than fresh poultry in a moisture-proof pack. A flat "assume 2% shrink on everything" number either hides real losses on high-loss items or falsely flags normal loss on low-loss ones. The rate has to be attached to the product, and ideally to how it's packed and stored, not applied as one company-wide constant.

Re-weigh on a cadence tied to how long product actually sits, not on a fixed calendar. Fast-moving SKUs that turn over in two days barely have time to lose measurable weight; slow movers sitting for three weeks are exactly where the gap compounds. A re-weigh cadence built around dwell time catches the loss where it's actually accruing instead of spot-checking uniformly across inventory that doesn't need it.

Log weight-loss variance as its own category, separate from the theft/count/damage buckets. Once a variance has a plausible expected-loss range for that product and that dwell time, a result inside that range should post as expected storage loss, not as an unexplained shrinkage exception. That keeps the unexplained variance list short enough that a real anomaly still stands out instead of drowning in expected moisture loss.

Feed the actual measured loss back into cost and pricing, not just inventory count. If a case genuinely weighs 3% less by the time it's sold, cost of goods sold on that case should reflect the weight that left the building, not the weight that arrived. Treating storage loss as pure shrinkage-to-write-off understates COGS on every sale from that batch; treating it as expected and pricing around it is what actually protects margin.

The takeaway

If catch-weight inventory keeps showing a gap between what was received and what's on hand — with no missing case, no bad line, and no obvious culprit — check dwell time and product type before assuming a count or a person is at fault:

• Attach an expected weight-loss rate per product, not a blanket shrink percentage.
• Re-weigh slow movers on a cadence tied to how long they actually sit, not a fixed calendar sweep.
• Give storage weight loss its own variance category so it stops masquerading as theft.
• Keep the unexplained-variance list narrow enough that a real anomaly is still visible.
• Roll measured loss into COGS for that batch instead of writing it off as generic shrinkage.

This is the piece iotoms' catch-weight inventory is built to carry: because every unit is tracked by measured weight rather than a static count, a pallet's weight can be re-checked against its own receiving record at any point it sits in inventory — so a moisture-loss pattern shows up as exactly that, on the product and vendor it belongs to, instead of landing in a shrinkage report as an accusation with no name attached.