← All postsCatch weight

Catch weight vs fixed weight: how to decide which items actually need it

iotoms team · October 13, 2026 · 5 min read

A specialty foods distributor carried about 600 SKUs: canned goods, jarred sauces, dry pasta, and a growing cheese and charcuterie line it had added two years earlier to chase higher-margin accounts. Every item in the system was set up the same way — ordered by the case, sold by the case, costed by the case. It was the setup the business had always used, and for the dry goods it was fine, because a case of canned tomatoes weighs the same whether it was packed in January or June.

The cheese line didn't work that way, and nobody had changed how it was set up to account for that.

One system, two kinds of product

A case of aged cheddar wedges wasn't a fixed quantity. Each wedge was cut and wrapped by hand at the creamery, and a "10 lb case" might actually hold 9.4 lbs or 10.7 lbs depending on how the cuts fell that day. The distributor bought it by the case, at a per-case price, and resold it the same way — one case price, regardless of what the scale would have said.

For a while this looked like a rounding error too small to matter. It wasn't. Over a full year of cases that ran consistently light, the distributor was paying its vendor for weight it never received, and reselling cases that sometimes weighed less than what the customer thought they were paying for. When a restaurant account started weighing incoming cases against the invoice and found a repeatable shortfall, they didn't frame it as a shipping variance — they framed it as being overcharged, and said so to their rep.

Why the fix for one line broke on the next

The sales team's first instinct was to catch-weight everything — put every case-based item on the scale at receiving and billing, the same way the warehouse had started doing, informally, for the cheese line after the complaint. That lasted about three weeks. Receiving a pallet of canned tomatoes took twice as long because someone was now weighing cases that were already uniform by design. The dry goods buyer pointed out, correctly, that a canned good has a fixed fill weight set by the cannery — weighing it told them nothing a case count didn't already tell them, and it slowed down a receiving dock that didn't need slowing down.

The real problem wasn't that catch weight was wrong. It was that nobody had ever drawn a line for which items it applied to, so it got applied to everything or nothing, both of which were mistakes.

The test that actually holds up

The variable isn't the product category — it's whether individual units of the same SKU differ enough in weight to matter financially. Three questions settled it for every SKU on the list:

Does the unit weight vary between individual pieces? A canned good, a bottled sauce, a shrink-wrapped multipack — these come off a line built to hit a fixed fill weight, and the variance is small enough to be noise. A hand-cut cheese wedge, a whole fish, a primal cut of meat, a crate of produce — these vary by nature, because nothing upstream is forcing uniformity.

Is the per-unit value high enough that the variance is real money? A few grams of variance on a $2 can of beans is nothing. The same few percent of variance on a $40 cheese case, repeated across hundreds of cases a month, is a margin leak worth chasing.

Does a customer or vendor contract price it by weight anyway? Some buyers — especially foodservice accounts — price certain lines strictly by the pound regardless of how the product is packed. If the contract already prices by weight, the system has to track by weight, independent of how small the per-unit variance looks.

An item that fails any one of those tests is a catch weight candidate. An item that passes all three — uniform, low enough value that variance doesn't matter, priced by the pack — stays fixed weight, and weighing it only adds a step at receiving and the counter that buys nothing.

What changed once the line was drawn

The distributor went through its catalog once, not case by case on instinct, but against those three questions. Cheese, charcuterie, and a handful of bulk produce items it had added for a catering customer got flagged as catch weight: ordered by the case, stocked and priced by the measured weight at receiving, with tare netted out and expected-versus-measured variance tracked per vendor. Everything else — cans, jars, dry goods, shrink-wrapped packs — stayed exactly as it was, case-in, case-out, no scale involved.

The restaurant account that had complained got its invoices switched to measured weight on the cheese line the next billing cycle. The dispute closed itself, because the invoice now matched what the scale on their own dock said. On the vendor side, the variance report surfaced something nobody had been tracking before: one creamery's cases were running 5% light on average, consistently, across six months of receipts — a pattern invisible when every case was costed identically regardless of what it actually weighed.

Practical checklist

  • Flag a SKU for catch weight only if individual units vary enough in weight to matter — not because the product category "sounds" like it should be catch weight.
  • Weigh the dollar exposure, not just the percentage: small variance on low-value items isn't worth tracking; the same variance on high-value items is.
  • Check customer and vendor contracts for weight-based pricing terms before deciding — a contract that prices by the pound overrides how small the physical variance looks.
  • Leave uniform, fixed-fill products (canned, jarred, shrink-wrapped) on case-based ordering and pricing; weighing them adds receiving time without adding accuracy.
  • Re-run the test when a supplier or packaging process changes — a line that used to be uniform can start varying once a vendor changes who packs it.

iotoms lets a SKU be catch weight or fixed weight independently, item by item, on the same price list — so a distributor can run cheese by measured weight and canned goods by the case, without forcing one inventory model onto a catalog that doesn't need it.

See your own routes running on iotoms

Book a demo