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.