Catch weight inventory for NZ food distributors: how the software actually works

If you distribute meat, seafood, whole poultry, bulk produce or certain dairy lines, you already know the problem: a customer orders two cases of lamb shoulders, but no two cases weigh the same. One comes in at 19.4 kg, the other at 22.1 kg. You invoice on actual weight — so the amount the customer pays is different every time. Standard inventory software was not designed for this.

This is catch weight inventory, and getting it right in software is more involved than most off-the-shelf systems acknowledge.

What catch weight actually means

Catch weight (also called variable weight or random weight) describes products where the ordering unit and the pricing unit are different — and where the pricing unit varies with every batch or individual piece.

The typical pattern for NZ food distributors:

• Order unit: cases, cartons, trays, bags
• Price unit: kilograms (per kg agreed with the customer)
• Variable: the actual weight of every case that leaves the coolstore

Classic catch weight products include whole fish and seafood, primal meat cuts, whole poultry, wheels of cheese, and loose-packed produce. What they share: the customer orders by the box, but they expect to pay for exactly what arrives on their loading dock — not a rounded nominal weight.

Why standard inventory software fails

Standard inventory systems — including the tracked inventory modules inside Xero, MYOB AccountRight and most SaaS warehouse tools — assume a fixed relationship between unit count and value. A case of product X has a unit cost of $Y, is sold at $Z per case, and is deducted from stock as one unit. Simple and fast for ambient grocery. Completely wrong for catch weight.

Distributors working around this limitation typically do one of the following:

• Set a nominal weight per case and invoice at that — which means the customer always pays either too much or too little, and disputes accumulate.
• Manually adjust invoices after despatch — the order goes through at the estimated weight, someone weighs the actual boxes, someone else edits the invoice. Slow, error-prone, and breaks at volume.
• Maintain a spreadsheet alongside the inventory system — a classic sign that the system isn't doing its job.

None of these scale. For a distributor running hundreds of catch weight lines and thousands of orders per week, the margin leakage and labour cost of manual correction is significant.

How a purpose-built system handles catch weight

The core design requirement is dual unit-of-measure (UoM) tracking maintained consistently through every step of the order cycle.

1. Order entry in cases, stock reserved in cases

The customer places an order through the trade portal — "4 cases of whole snapper." The system reserves 4 cases from stock on hand (in cases), confirms availability based on the cases physically in the coolstore, and generates a pick instruction for 4 cases. Nothing unusual yet.

2. Scales integration at pick and despatch

This is the critical step. At the packing bench or despatch dock, the picker places each case on integrated scales — either a bench scale connected directly to the warehouse system, or a barcode-scan-and-weigh workflow on a handheld device. The actual weight of each case is captured electronically and written back to the order line. No manual data entry, no transcription.

A proper system will also flag variance: if a case comes up significantly outside the expected weight range for that SKU (say, more than 20% lighter or heavier than nominal), it alerts the operator before the box leaves the building — a useful catch for damaged product, incorrect packaging or mislabelled stock.

3. Invoice generated on actual weight

Once the order is despatched and actual weights are recorded, the invoice is generated automatically: 4 cases × actual total weight × agreed price per kg = invoice total. The customer sees the actual weights per case on the invoice, not an estimate. Your accounting system — whether that's Xero, MYOB or a custom accounting layer — receives the correct amount directly.

4. Stock on hand updated in both units

Stock is decremented in cases (for future order fulfilment checks) and in total kilograms (for cost-of-goods, margin analysis and inventory valuation). Your buyers know how many cases are left in the coolstore; your accountant knows the value of stock on hand by weight, not just by case count.

Reporting that actually makes sense

Good catch weight reporting runs in parallel across both units:

• Sales reports show revenue by kg sold alongside cases shipped — so you can spot when margins are being eroded by heavier-than-expected cases that inflate COGS without a matching price increase.
• Variance reports compare nominal weights to actual weights by SKU and supplier — useful for negotiating with suppliers who consistently pack heavy or light.
• Stock valuation is calculated on actual kg in the coolstore, not cases × nominal weight, which gives a more accurate picture for month-end and cost reporting.

Catch weight and MPI traceability

Catch weight products are typically fresh or chilled — exactly the products the Ministry for Primary Industries focuses on for traceability requirements. A well-designed system links catch weight records (which case, which weight, which despatch) to batch and lot tracking so that if a recall is triggered, you can identify every affected case by weight lot, who it was sold to, and when it was despatched. The scales integration data becomes part of the traceability record, not a separate system.

This is why catch weight handling and batch lot tracking are often designed together in a distribution platform, rather than bolted on separately.

What to look for when evaluating catch weight software

When you're assessing a platform for catch weight distribution, the questions that matter:

1. Is dual UoM native throughout the system — in stock, in orders, in invoicing, in reporting — or is it a workaround applied only at the invoice stage?
2. How does scales integration work? Direct serial/USB connection to bench scales, Bluetooth handheld, or manual entry? Manual entry is not scales integration.
3. Does the pick instruction show expected nominal weight so the picker knows what range is normal?
4. Are variance alerts configurable per SKU? A 10% variance on lamb is fine; on fresh fish it might mean the wrong product was packed.
5. How does accounting integration handle the difference between the ordered value and the despatched value? The integration must send the actual weight invoice amount, not the estimated order amount.
6. Is catch weight linked to lot/batch traceability?

Where it fits in a full distribution platform

Catch weight inventory is one part of a broader set of requirements that distinguish food distribution software from generic inventory management. Others in the same category: customer-specific pricing across hundreds of SKUs, AI-assisted ordering for customers who place orders by text or email, and the B2B portal that lets trade customers order at any hour against their current credit and stock.

The Provender platform is built for exactly this stack — catch weight, dual UoM, scales integration, batch traceability and a B2B trade portal, connected to accounting via 25+ integrations including Xero, MYOB and Accredo. If you're working around catch weight with spreadsheets or manual invoice corrections, talk to us about what a purpose-built approach looks like for your operation.