The daily rhythm.
From PO to invoice.
Five steps between the retailer PO and the accurate invoice. Built for catch-weight food where 100 kg ordered never leaves the factory as exactly 100 kg.
Five steps. Monday morning to Friday invoice.
The daily rhythm of a food manufacturer, PO in the door, produced on the floor, dispatched to the retailer, invoiced through your accounts. Keystone is the layer that connects those five moments without spreadsheets in between.
Why food producers need an operations layer that records more than the invoice shows.
A 100 kg cheese PO ships as 104 kg, 108 kg or 96 kg. Not sloppy, that’s variable-weight food. The industry calls the actual weight catch weight. Handling it properly is where generic ERPs fail.
Two invoicing modes, both standard. Per-kg trade (wholesale, foodservice, export): invoice the actual catch weight. Fixed-price retail SKUs: invoice the PO quantity within tolerance, the retailer’s AP matches on PO. Get it wrong and either your traceability breaks or the retailer short-pays every invoice.
Keystone: one workflow, mode-aware invoicing.Operations layer records the real 108 kg, your traceability spine. The invoice, pushed to AccountsIQ / Xero / Sage over API, follows each customer’s terms: PO quantity for retail SKUs, catch weight for per-kg. The 8 kg variance stays a first-class number, filterable, reportable, visible in margin.
The questions producers actually ask.
Why doesn't my invoice match my delivery weight?
It depends on how that customer trades. For fixed-price SKU supply to retail multiples, the invoice carries the PO quantity within an agreed tolerance, an off-PO invoice triggers short-pays and AP query queues, so matching the PO is what gets you paid on time. For per-kg trade, the invoice carries the actual catch weight recorded at dispatch. Keystone knows which mode each customer is on and raises the right invoice automatically, while the operations ledger records the actual weights and batches in both cases.
What is catch weight invoicing?
Catch weight is the actual weight of a variable-weight product recorded at dispatch, a wheel of cheese, a meat primal, a box of fish. Catch weight invoicing bills the customer for that actual weight, and it's the standard for per-kg trade. Keystone captures catch weights per batch at dispatch and invoices per-kg customers at actual weight; fixed-price retail SKUs are invoiced at PO quantity instead, with the weight variance recorded and reportable.
How do I invoice when I dispatched more than the PO quantity?
Check the customer's trading terms, Keystone applies them automatically. Per-kg customer: invoice the actual dispatched weight, e.g. 108kg. Fixed-price PO from a retail multiple: invoice the 100kg PO quantity within the agreed tolerance, with the +8kg variance recorded as a first-class number in the operations layer, reportable, filterable and visible in your margin numbers, never silently lost.
Do I lose traceability if the invoice doesn't show the real weight?
No, the opposite. Traceability lives in Keystone's operations layer, which records every gram, unit and batch you actually dispatched. That is your BRCGS §5.4 / EU food safety evidence. The invoice is a commercial document that follows the customer's trading terms; the trace evidence is operational. Keeping the two aligned but separate is standard practice, Keystone just automates it.
Which accounting packages does this work with?
AccountsIQ out of the box, with Xero, Sage and QuickBooks available as scoped integrations. Invoices go across the API at the quantity each customer trades on, no CSV exports, no manual re-keying, no Monday-morning reconciliation spreadsheet.