Catch-weight pricing is the single most technically complex feature that separates purpose-built food distribution platforms from generic B2B commerce tools. This guide covers the full order lifecycle, accounting implications, and what a correct implementation actually requires.
Definition and Industry Context
Catch-weight refers to products where the commercial unit (a case, a piece, a wheel) has variable weight that cannot be predetermined at the time of ordering. The transaction is priced per pound (or per kilogram), but ordered by unit count. The price at invoice is calculated against the actual weight measured at pick or delivery, not an estimated weight used at order time.
The term “catch-weight” originates from seafood — a “catch” of fish is naturally variable in size and weight. The concept extends to any agricultural or animal product where individual units vary in a way that is commercially significant.
Why food has this problem and industrial supply does not: A steel bolt is manufactured to a specification. It is 3 inches long, 0.5 inches in diameter, weighs approximately 0.12 oz. The 1,000th bolt is the same as the first. A chicken breast is a biological product. The 1,000th breast from a processing line may weigh 6.2 oz; the 1,001st may weigh 7.8 oz. You can specify a weight range in your purchasing spec (6-8 oz chicken breasts), but within that range, every unit varies. Industrial supply’s uniform product problem is easy for standard ecommerce platforms to model. Food distribution’s variable product problem is not.
The Order Lifecycle: From Quote to Credit
Understanding catch-weight requires following a specific product through the complete order cycle.
Quote / Price sheet. A distributor publishes a contracted price for boneless ribeyes: $15.40/lb, minimum 8 oz portions, estimated average case weight 18 lbs, estimated case price $277.20. The buyer knows what they are committing to per pound and roughly what a case will cost.
Order placement. The buyer orders 15 cases. The order confirmation shows 15 cases x $277.20 estimated = $4,158.00 estimated total. Both parties understand this is an estimate, not a commitment. The actual invoice will reflect actual weights.
Pick and weigh. In the warehouse, an order selector picks 15 cases of ribeyes, places each on a scale, and records the actual weight. Case 1: 17.4 lbs. Case 2: 19.1 lbs. Case 3: 18.6 lbs. And so on. The WMS or scale system captures actual weights against the order.
Delivery. The driver delivers 15 cases. Actual total weight: 272.8 lbs.
Invoice. Invoice calculates: 272.8 lbs x $15.40/lb = $4,201.12. The buyer receives an invoice for $43.12 more than the estimated total on their order confirmation. Within a normal variance range, this is expected. The buyer’s accounts payable process must accommodate this variance as a normal feature of catch-weight ordering.
Credit scenarios. If a case was damaged in delivery and the buyer receives partial credit, or if the actual weight of a case differs significantly from what was recorded on the delivery ticket, a credit memo is issued. Credit memos on catch-weight products must specify whether they are crediting by case (regardless of weight) or by weight (actual pounds credited).
Accounting and Reconciliation Challenges
Catch-weight products create specific accounting challenges that businesses managing food purchasing must accommodate.
Estimated vs. actual revenue. For the distributor, a catch-weight order creates a revenue variance between the estimated order value and the actual invoiced amount. On commodity proteins with daily price changes and significant weight variability, this variance can be substantial across a month’s orders. Margin calculations on catch-weight products require tracking actual weight delivered rather than ordered quantity.
Budget vs. actual for buyers. A hotel food and beverage department that budgets $25,000/month for proteins will find their actual spend varies from that budget even if they order the same quantity of cases each week. Budget management for catch-weight-heavy categories requires either conservative estimation buffers or acceptance of month-to-month variance.
Margin variance by product. A distributor selling boneless salmon at a fixed price-per-pound does not control the weight of each piece. If the pieces run heavier than average, they sell more pounds per case than average — good for revenue, but the cost also runs higher. If pieces run light, the opposite. Catch-weight margin management requires weight-level tracking to understand actual margin per case, not just margin per pound.
Invoice reconciliation. For buyers using procurement systems with three-way matching (PO, goods receipt, invoice must match within tolerance), catch-weight invoices require either: (a) acceptance of weight variance as a systematic exception, (b) receiving-scale integration that updates the goods receipt with actual weight, or (c) manual reconciliation of every catch-weight line. Option (b) is the cleanest but requires integration investment. Option (a) is the most common practical accommodation.
Technology Requirements
A platform that correctly handles catch-weight must address each of the following:
Data model. The product record must support a price-per-pound field, an estimated average weight, a unit of measure for ordering (cases), and a separate unit of measure for pricing (pounds). These are distinct fields, not variants on a single price field.
Ordering UI. The buyer sees price-per-pound, estimated case weight, and an estimated line total — with a clear indication that the final invoice will reflect actual weight. A buyer who orders 15 cases and is surprised by an invoice variance did not have their expectations properly set during ordering.
Order confirmation. The order confirmation email and order history view must distinguish between estimated totals and committed totals. Displaying an estimated total without labeling it as estimated creates confusion and erodes trust.
Weight capture integration. The platform should be able to receive actual weight data from the WMS or scale system and update the order record accordingly, so that the invoice total is calculated from actual weights rather than estimates.
Invoice variance handling. The system should calculate the variance between estimated and actual invoice total, flag variances above a configurable threshold, and present the variance clearly on the buyer-facing invoice.
Credit memo handling. Credits on catch-weight products should specify whether the credit is by unit or by weight, with consistent handling through the accounting integration.
Common Mistakes Platforms Make
Treating catch-weight as a product attribute rather than a data model feature. Adding a “catch weight: yes/no” flag to a product does not change the underlying pricing or invoicing logic. The data model must support variable-quantity invoicing from the ground up.
Showing only estimated prices without labeling them. Buyers who see $4,158 on their order confirmation and $4,201 on their invoice believe they were charged incorrectly. The distinction between estimated and actual must be explicit and consistent.
No tolerance handling. An invoice that differs from the estimate by $0.40 should not generate an exception workflow. A platform that flags every catch-weight variance — rather than only meaningful variances outside a configurable tolerance — creates operational noise that buries genuine issues.
No audit trail. Disputes about catch-weight invoices require an audit trail: what weight was recorded at pick, what was recorded at delivery, what was the calculated invoice total at each step. Platforms that do not maintain this trail make dispute resolution impossible.
Confinus catalog and pricing capabilities include native catch-weight product support covering the full order lifecycle — from estimated pricing at order time through actual-weight invoice calculation. See how it works in the context of a complete digital ordering platform for food distributors.