What Is Catch Weight? Why Fixed-Weight Billing Quietly Leaks Margin
No two legs of lamb weigh the same
Walk a protein cooler and pick up two boxes of the same product. Same SKU, same label, same price per pound — different weights. One bone-in leg is 7.8 lb, the next is 8.4. Salmon sides, primal cuts, cheese wheels, whole birds: anything that was recently an animal or a living thing varies, piece to piece, in a way a catalog can't predict.
The industry term for this is catch weight — the actual weight "caught" at the scale, as opposed to the nominal weight printed in the catalog. Customers order in pieces and cases because that's how product ships and stacks. But the price is per pound, so the invoice depends on numbers nobody knows until the cases are packed and weighed.
Where the money goes when you bill nominal
Plenty of operations bill from the average: the catalog says a leg averages 8 lb, so every leg invoices as 8 lb. It feels harmless. It isn't, for three reasons:
- The variance is systematic, not random. Packers naturally ship heavy pieces when supply is heavy and light pieces when it's tight. Whoever set the average two years ago wasn't pricing this week's lambs.
- The error compounds with volume. A quarter pound per case is invisible on one order and five figures a year on a route truck's worth of weekly deliveries.
- Sophisticated customers weigh their receipts. The ones who catch you billing heavy claim credits; the ones you bill light say nothing. The asymmetry only ever runs one direction — against you.
Billing actual weight isn't just fairer; it converts an invisible leak into revenue you were already earning.
What honest catch weight billing requires
Doing this properly is more than adding a weight column to an invoice. The pieces that have to exist:
- Dual units on the same line. The order is 3 pieces; the bill is 24.3 lb x $8.50. Both numbers are true at once and the system has to carry both.
- An estimate before actuals exist. Sales needs a dollar figure at quotation time — pieces times average weight — that gracefully trues-up later without anyone re-keying.
- Per-case capture, not a lump sum. One total weight for the order can't answer a customer dispute about case 3. Gross, tare, and net per physical case can.
- Tolerance checking at capture time. If a "leg" weighs 13.5 lb, someone grabbed the wrong product or fat-fingered the scale. The moment to catch that is at the dock, where it's a do-over — not on the invoice, where it's a credit memo and an awkward call.
- Money math that survives audit. Fractional pounds times fractional dollars, thousands of times a month — rounding has to be deliberate, consistent, and to the cent.
Why ERPs historically punt on this
Most ERP data models assume one quantity per line. Catch weight breaks that assumption, so it's usually handled with bolted-on "secondary unit" fields that convert on a fixed factor — which is just the nominal-average problem wearing a nicer shirt. A fixed conversion factor is exactly what catch weight products don't have. The whole point is that the factor is different for every case, and only the scale knows it.
How we do it in Odoo
We built WeightSheet — Catch Weight, an Odoo addon (18 and 19) that implements the full loop natively: tolerance bands on the product, piece-based ordering with estimated weights, per-case gross/tare/net capture on the delivery with validation that refuses out-of-band cases, and automatic invoice true-up from actuals — all without touching Odoo's core tax and accounting pipeline. Weights come from a keyed entry or straight off a bench scale via the companion WeightSheet terminal.
If your products are priced per pound but shipped in pieces, the question isn't whether the variance exists — it's who's currently paying for it. We can help you find out.
