Catch weight is one of those terms that sounds like jargon until it wrecks an invoice. It describes any product where the quantity you order and the quantity you bill for are measured differently, because the actual weight varies unit to unit. You order a case of ribeye; the case weighs 38.6 pounds this time and 41.2 pounds next time. You sell it by the case but you invoice by the pound. Meat, seafood, poultry, and a lot of cheese work exactly this way — and it's where generic inventory systems quietly fall apart.
Two units of measure at once
The core of catch weight is that a single item carries two units that don't convert by a fixed factor. There's the ordering unit (a case, a piece) and the pricing unit (a pound, a kilogram), and the ratio between them changes with every physical unit. A normal system assumes one case always equals a fixed weight — so it can hold inventory in cases or in pounds, but it can't hold "12 cases that together weigh 487.3 pounds" and keep both numbers true. That's the whole problem in one sentence.
Where it actually hurts
The pain shows up at three points. At receiving, you take in a quantity of cases but need to record the actual weight, because that's what you paid the supplier for. At shipping, you pick cases but the customer is billed on the weight that physically left the dock — not an estimate. And at invoicing, the price has to be actual-weight times price-per-pound, or you're either overcharging customers or eating the difference yourself. Get the unit conversion wrong at any of those and the error is real money, every order, forever.
The workarounds that don't scale
Distributors on generic ERP usually cope in one of two ways, and both leak. The first is treating everything as an average weight — bill every case of ribeye as if it's exactly 40 pounds. That's simple and wrong; over thousands of cases the averaging error becomes a margin leak nobody can find. The second is capturing real weights in a spreadsheet alongside the ERP and reconciling by hand, which works until volume grows and the two records drift. Neither is a system so much as a standing tax on the finance team.
What handling it properly requires
Real catch-weight support means the item itself is flagged as catch weight, the system stores both the ordering-unit count and the actual weight on the same line, weight is captured at receiving and at shipping, and the invoice prices on the shipped weight automatically. Inventory value then reflects real pounds on hand, not a fiction. Done right, a picker scans a case, the caught weight is recorded, and everything downstream — the customer invoice, the inventory valuation, the cost of goods — uses the number that actually happened.
CDXAI treats catch weight as a first-class property of the product rather than a bolt-on, so ordering by case and billing by weight are the same transaction. If your meat, seafood, or cheese business is reconciling weights by hand, that's the gap to close — see the food distribution ERP and warehouse management pages for how the caught weight travels from the dock to the invoice.