Catch Weight Order Entry: Ordered by Piece, Invoiced by Kilo

A customer orders six salmon sides. You pick six salmon sides. They weigh 14.2 kilos. You invoice 14.2 kilos. The order, the pick and the invoice are three different numbers describing the same thing, and every system between them has to agree.

What is catch weight?

Catch weight is a way of selling products whose weight varies from one unit to the next. The customer orders a count — six salmon sides, four whole chickens, two wheels of cheese — but pays for the actual weight that goes out, at a price per kilo or per pound. The weight is “caught” when the product is weighed at picking or packing, and that caught weight, not the ordered count, is what goes on the invoice.

It is the normal way to sell meat, poultry, seafood, cheese and many deli and fresh lines, because no two natural products weigh exactly the same. It is also almost entirely absent from the marketing of order-automation products — which is a useful signal about which trades they were built for.

Catch weight vs fixed weight

A fixed-weight product — also called standard weight — is packed to a declared weight: a 500g pack of butter weighs 500g, so it can be ordered, picked and invoiced in the same unit at a fixed unit price. A catch-weight product — also called variable weight or variable measure — cannot, so it lives in two units at once:

• An ordering unit — the piece, side, case or box the customer asks for and the warehouse picks.
• A pricing unit — the kilo or pound the customer is invoiced by.

Everything difficult about catch weight comes from keeping those two units connected, accurately, from the moment the order arrives to the moment the invoice goes out.

How catch weight works, from order to invoice

• The order is taken by count: six sides, ten portions, two cases. Some customers add a target weight or a weight range as part of the specification.
• An expected weight stands in until the real one is known — usually a nominal or average weight per piece — so the order can be valued and checked.
• At picking or packing, each piece or case is weighed. On a labelled case the actual net weight usually travels in a GS1-128 barcode: a variable-measure product code plus a net-weight application identifier such as (3102), kilograms to two decimal places.
• The invoice is raised on the caught weight multiplied by the price per kilo or pound, not on the ordered count.
• Differences between the expected and the actual weight are reconciled, ideally automatically, within the tolerances you set.

Tolerances matter more than they look. Systems that support catch weight usually let you set a minimum and maximum acceptable weight per piece, so a side that is far too light or too heavy is caught at the scale rather than argued about after the invoice.

Pricing catch-weight products

Catch-weight items are priced per unit of weight — per kilo or per pound — and the line value is only final once the weight is known. That creates a practical problem before anything ships: the order still has to be valued. Distributors handle it with an estimate, typically the item's nominal or average weight multiplied by the ordered count, which the actual weight replaces at invoicing.

The estimate is not a formality. It is what the order is checked against before anything is weighed — the customer's minimum order value, their credit limit, the threshold for a delivery charge. Get the average weight wrong in the item master and every one of those checks is wrong in the same direction, on every order, without anyone noticing.

Why catch weight breaks ordinary order entry

Most order tools assume quantity times price equals line value. Catch weight breaks that at the first step. The ordered quantity is a count. The invoiced quantity is a weight. The price is per kilo. And the actual weight is not known until someone puts the product on a scale.

So the order desk holds it together by hand: capture the count, let the picker record the weight, reconcile at invoice. The most common failure is not in the reconciliation. It is that the number going into it was retyped by a person from a WhatsApp message at seven in the morning — six sides keyed as six kilos, or a case count entered against the per-kilo item.

How ERPs handle catch weight

Support varies more than most buyers expect, so it is worth checking rather than assuming:

• Microsoft Dynamics 365 Supply Chain Management supports catch-weight items natively, including capturing the weight at picking or packing and checking it against minimum and maximum tolerances.
• SAP S/4HANA supports catch-weight management, largely through Extended Warehouse Management, keeping separate units for stock and for sales.
• Business Central and NetSuite generally rely on add-ons or partner solutions for catch weight rather than a standard feature.
• QuickBooks has no native catch-weight handling, so weight-priced lines need a workaround.

Food-specific distribution ERPs often include catch weight as standard. Whichever system you run, the question to ask is the same: does it keep the ordered count and the invoiced weight as separate fields from the sales order onward, and does it price on the weight?

The specification is the other half

Catch weight rarely travels alone. It arrives with a spec: “denuded, 220g portions, cryovac”. “Skin on, pin-boned, 2-3kg.” That is not a field on a form. It is free text, written by someone who assumes you know what they mean, and it has to survive all the way to the packing bench.

When it does not survive, you do not get a small error. You get the whole delivery back.

What automation should and should not claim here

It should not claim to solve catch weight. Weighing, labelling and reconciliation belong to your scales, your warehouse and your ERP or its add-on, and a vendor who says otherwise has not understood the problem.

What it should do is stop feeding the reconciliation bad data. Capture the ordered count exactly as the customer sent it. Match the spec to the product code that means precisely that. Keep the original message attached, so when there is an argument about what was asked for, the answer is what the customer actually sent rather than someone's memory.

Clean input into a reconciliation that already works is a smaller promise than “we handle catch weight”. It is also the true one — and it is how ManualOut treats catch-weight orders for meat and seafood distributors: the count and the spec are captured as the customer sent them and matched to the right product, and the weight is left to the systems that actually weigh things.