Ordered by piece, invoiced by kilo
Catch weight is why meat and seafood order desks cannot use ordinary tools. Nobody in this market talks about it, which tells you who they were built for.
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.
That is catch weight, and it is ordinary in meat, seafood, cheese and produce. 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.
Why it 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. Your ERP probably handles this well — most of the serious ones do. The weakness is not the ERP. It is that the number going into it was retyped by a human from a WhatsApp message at seven in the morning.
The specification is the other half
Tideway Fish Co.
Morning — for tomorrow: 6 salmon sides, skin on, pin-boned, 2-3kg 4 x cod loin 200g portions 2 boxes hake, whatever's landed 10kg mussels 3 x seabass whole, 400-600g Same as last week otherwise
The original message stays attached to the order — permanently.
| Product | Unit | Qty | Line |
|---|---|---|---|
| Salmon Side — skin on, pin-boned, 2-3kgCatch weight — invoiced on actual kg at pick | PCE | 6 | $255.00 |
| Cod Loin — 200g portion | PCE | 4 | $27.20 |
| Mussels — rope grown | KG | 10 | $49.00 |
| Seabass — whole, 400-600gCatch weight | PCE | 3 | $33.60 |
| Hake — grade not stated"whatever's landed" — needs today's landing to price | BOX | 2 | — |
- Order value
- $364.80
- Minimum
- $250.00
- Status
- Minimum met
Ordered by piece, invoiced by kilo. The catch-weight lines are captured as sent, so your ERP reconciles from clean data rather than a retyped guess — and the one line that depends on the landing is flagged, not guessed.
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. Your ERP already does that, 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 a recording rather than a memory.
Clean input into a reconciliation that already works is a smaller promise than "we handle catch weight". It is also the true one.
Frequently asked questions
What is catch weight in food distribution?
Catch weight means a product is ordered by piece but priced and invoiced by actual weight — six salmon sides ordered, invoiced by the kilo they weigh. Meat, seafood and deli lines usually work this way.
Why does catch weight break ordinary order-entry tools?
Most tools assume one unit and one price per line. Catch weight needs the order captured by piece, the weight captured or estimated, and pricing applied by weight — three things generic tools flatten into a single quantity.
How should catch-weight order entry be automated?
The system has to keep the piece count and the weight basis separate, carry both to the ERP sales order, and apply weight-based pricing rather than forcing everything into one field.