Restaurant Invoice Matching for Accurate Stock Control

November 7, 2025

Written by: JJ Tan, Founder, Jelly | Last updated: 13 September 2026

Key Takeaways

Accurate invoice-to-inventory linking relies on a disciplined four-stage workflow: capture, extraction, matching and syncing. Human review focuses on exceptions instead of full manual processing.
Three-way matching against accepted delivery quantities prevents stock overstatements and protects gross profit margins from silent corruption.
Supplier SKU mapping and pack-size normalisation convert supplier descriptions into the receiving units used by recipes, which keeps costing consistent across every invoice.
Six mandatory fields per invoice line – quantity, receiving unit, net unit cost, extension cost, supplier item ID and barcode/PLU – must be captured and validated before posting to stock or COGS.
Jelly automates the routine elements of this workflow and surfaces exceptions for review, helping UK operators protect margins. See how the matching layer works on your own supplier invoices.

The Four-Stage Linking Workflow: Where Accuracy Is Won or Lost

Linking is only as accurate as the matching and validation layer. The winning model combines automated routine with human-reviewed exceptions. A pipeline extracting at 99% and booking unverified is worse than one extracting at 95% and routing the uncertain 5% to a human. Each of the four stages below is a point where accuracy is either protected or lost.

Capture

Invoices arriving as consolidated multi-site documents or poor-quality photos create ambiguity before extraction even begins. A single consolidated invoice covering three sites cannot be matched to site-level inventory without line-level splitting. A four-layer AP intake workflow begins at capture via email, scan, EDI feed, or vendor portal upload, and the quality of what enters the pipeline determines the ceiling for everything downstream.

Extraction

OCR misreads quantities, pack sizes or net unit cost on poorly formatted PDF layouts. Multi-page continuation tables, where line items span across page breaks with repeated, partial, or no headers on subsequent pages, consistently produce the lowest extraction accuracy rates across all extraction tiers. Line items such as description, quantity and unit price are extracted at only 75–85% accuracy on complex layouts, well below the headline figures vendors quote for header fields such as invoice total or supplier name.

Matching

Supplier item descriptions that do not correspond to any internal inventory item create unmatched lines that either post to the wrong SKU or sit in a queue nobody owns. Supplier SKU mapping and pack-size normalisation prevent that drift. Matching extracted invoice lines to an operator’s own item catalogue is harder than extraction, because distributors constantly rename items, substitute SKUs, and change pack sizes.

Syncing

Approved costs flowing into recipe costing and COGS before validation corrupt dish margins silently. Nothing should post to stock until the match is validated against accepted delivery quantities. Extracted invoice data should be written to Xero or QuickBooks as draft bills only, never authorised, so a finance team member must approve before any payment run. That approval step depends on one control doing its job: three-way matching.

How Do You Handle Discrepancies Between Purchase Orders, Invoices and Receiving Reports?

Three-way matching in accounts payable is an internal control that compares a supplier invoice against the purchase order and the goods receipt note (GRN), releasing payment only when all three documents agree within a pre-defined tolerance. This control gives invoice-to-inventory linking its credibility.

The five-step workflow for three-way matching in a restaurant or pub context is:

Raise the PO with agreed pack size and unit. The purchase order establishes quantity, unit price, line items, delivery terms, and a PO reference number.
Record goods received against accepted delivery quantities. Note shortages, substitutions and damaged goods at the point of delivery. The GRN is what gives three-way matching its credibility; without a confirmed record of receipt, matching becomes theoretical rather than practical.
Extract the invoice line data for quantity, receiving unit, net unit cost, extension cost, supplier item ID and barcode/PLU.
Match invoice line to PO line to goods-received line on quantity, receiving unit and net unit cost. This comparison shows what was ordered, what was accepted, and what is being billed.
Flag and route exceptions rather than posting them. Price changes, substitutions, shortages, damaged goods, credits and duplicate invoices each require a named owner and a resolution path before anything posts to stock.

The critical distinction is matching against accepted delivery quantities. When a supplier invoices 10 cases but only 8 are accepted, matching to the PO alone lets the invoice clear because the PO still shows open quantity; the system records 10 cases, overstating stock by 2 cases and inflating COGS by the value of those 2 cases when the inventory is sold. That overstatement flows silently into dish costs and gross profit until the next physical count exposes it.

The Institute of Finance and Management reports that organisations without automated matching controls experience invoice exception rates above 20%. One in five invoices carries a problem such as a wrong quantity, wrong price, or a charge for goods never received.

Supplier SKU Mapping and Pack-Size Normalisation: The Layer No One Talks About

Supplier SKU mapping inventory maps a supplier’s item ID and description once to an internal inventory item, then reuses that mapping on every subsequent invoice from that supplier. The internal item becomes the single source of truth for stock, recipe costing and COGS, regardless of how the supplier describes it.

Vendor item numbers are particularly important when suppliers use different naming conventions, packaging units, catalogue structures or product codes, because they provide a common reference between internal purchasing records and supplier documentation. A supplier calling an item “Chicken Breast Bnls Sknls IQF 6oz” and your inventory system calling it “Chicken Breast — 6oz IQF” still refer to the same product. Without a mapped cross-reference, every invoice line from that supplier becomes an unmatched exception.

Pack-size normalisation converts the supplier’s invoiced unit into the receiving unit your recipes use. A worked example:

A supplier invoices “1 case” at £24.00
The case contains 12 × 1L bottles
The receiving unit is 1L at £2.00 net unit cost
That £2.00 per litre is the figure that must reach the recipe

A weight-based example: 1 case equals 6 × 2kg. The unit price is calculated as the total price divided by weight per item multiplied by number of items, so a case of 6 × 2kg normalises to 12kg, giving a per-kg cost of the case price divided by 12.

Without normalisation, a case price and a bottle price can both sit in the same recipe and produce a dish cost that is wrong by an order of magnitude. Receiving an item in cases, issuing it in bottles and counting it in pieces without a documented conversion is a common source of errors; records may show one case while the storekeeper sees twelve bottles. A recipe calling for 200ml of oil priced at the case rate rather than the litre rate can substantially understate the dish cost. Normalisation only works if the invoice line carries the right fields in the first place, which is why the data spec matters.

The Field-Level Data Spec: What Must Be Captured Per Invoice Line

Every invoice line must carry six fields before it can update stock and COGS accurately. Miss any one and the matching layer has nothing to validate against, so the line either posts unchecked or sits in a queue. Here is what each field does:

Quantity: The number of receiving units accepted, not the number ordered or the number invoiced. Quantity shipped versus quantity ordered is specifically identified as a useful field for detecting short deliveries and mismatches.
Receiving unit: The unit in which stock is counted and recipes are costed, such as each, kg, litre or case. Best practice is to define units of measure for how you buy, store, prep and count, and to lock in conversion factors based on reality rather than packaging guesses.
Net unit cost: The cost per receiving unit after pack-size normalisation, which is the figure that reaches the recipe. It is also the field OCR tools fail on most often, even when they read the invoice total correctly.
Extension cost: Quantity multiplied by net unit cost. This figure validates the line total against the invoice and catches extraction errors before they post.
Supplier item ID: The supplier’s own identifier. This field enables the SKU mapping to be reused on every subsequent invoice from that supplier without re-mapping.
Barcode/PLU: The scannable identifier. This field enables receiving to be recorded against the correct internal item at the point of delivery, before the driver leaves.

Where Accuracy Breaks, and the Review Loop That Catches It

Restaurant invoice OCR accuracy in UK operations is affected by seven recurring failure modes, from consolidated multi-site invoices to duplicate billing. Each one has a named control that catches it before it reaches stock:

Consolidated multi-site invoices: Line-level splitting by site. Each site’s stock and COGS update separately, so a single invoice covering three locations does not distort any one site’s counts.
Poorly formatted PDF layouts: A human review queue for low-confidence OCR lines. Nothing posts until the line is verified against the source document. A system with 95% field-level accuracy combined with a well-designed human review workflow can achieve 99.9% pipeline-level accuracy, whereas a system with 99% field-level accuracy and no review process cannot reach that level.
Substitutions: A substitution flag at receiving. The substitute is mapped to the correct internal item or flagged for review before posting. An unauthorized substitution can flow straight into COGS: if a product ordered at £62 per case is replaced by a substitute at £74 per case and nobody notices, the higher price is absorbed by the restaurant.
Shortages: Matching against accepted delivery quantities using the accepted-quantity rule described earlier. The shortage is recorded at the point of delivery and the invoice is matched to what was accepted.
Damaged goods: A damaged goods note at receiving. The line is held from stock and COGS until a credit note is matched back to the original invoice line.
Credits: A credit note matched back to the original invoice line. The credit reduces COGS only when it is matched, not when it is requested. A requested credit is not a received credit; if £186 of damaged product is noted as “credit requested” but no credit appears on the next invoice, the restaurant absorbs the £186 unless someone follows up.
Duplicate invoices: Duplicate detection comparing vendor plus invoice amount plus invoice date within a rolling window. The system flags the duplicate before payment. Naive duplicate detection compares invoice numbers character by character and misses almost every real-world duplicate; modern detection compares vendor plus invoice amount plus invoice date within a rolling window.

The review loop is exception-first: automation handles the routine lines, a named person reviews only the flagged exceptions, and nothing posts to stock until that person approves it. A review queue that grows without a named owner and a daily zero-out target becomes a black hole; the fix is a named owner, a clear SLA on high-risk documents, and a daily resolution target. That is the model Jelly is built around.

Jelly: The Platform Built For This Workflow

Jelly is built for the four-stage linking workflow described above. It automates the routine and surfaces the exceptions, so approved costs flow into live dish costing and menu margins without corrupting stock counts. Amber, a Mediterranean restaurant in East London, saved £3,000–£4,000 per month using Jelly. One operator moved gross profit from 65% to 72% within 12 weeks on approximately £500,000 in revenue.

Jelly maps its features directly onto the four stages, and each one acts at the point where accuracy is won or lost:

Automated invoice scanning: Digitises every line item such as quantity, SKU, price and tax from email or photo. Teams avoid manual data entry.
Supplier SKU mapping and automatic unit conversions: Pack sizes normalise without manual maths, so the receiving unit and net unit cost reach the recipe automatically.
Price Alert: Flags every ingredient price increase or decrease by supplier. Chefs gain concrete evidence to negotiate better rates and claim credit notes before the margin damage compounds.
Flash Report: Daily, weekly or monthly gross profit from invoice costs and POS sales. Operators see performance in near real time instead of waiting for the accountant.
One-click push to Xero: Digitised invoices push directly into Xero, with Sage integration coming soon. Finance teams see around a 90% reduction in bookkeeping time.
Kitchen section: Chefs build dishes by clicking ingredients already populated from scanned invoices. Approved costs flow straight into live dish costing and menu margins.

Jelly onboards and generates initial value in the first week. It integrates natively with Square, EPOS Now, Toast and Lightspeed as complementary POS partners, delivering item-level sales data the moment a transaction completes and powering the Flash Report and Sales Mix analysis. To see how that data combines with invoice matching on your own numbers, book a walkthrough.

Choosing Restaurant Inventory Software with Invoice Matching in the UK

For UK operators, Xero and Sage integration matters for the finance workflow and for Making Tax Digital compliance. Under HMRC’s Making Tax Digital requirements, VAT-registered UK businesses must maintain digital records of transactions, meaning both purchase orders and invoices need to be accurate and properly matched. Jelly, MarketMan, Nory and Fourth differ mainly on how they handle matching and exception review. Jelly focuses on simplicity, fast onboarding and an exception-led review loop, which generates initial value in the first week rather than after months of configuration.

Frequently Asked Questions

What Causes Invoice Data to Corrupt Restaurant Stock Counts?

Three root causes account for most stock count corruption in restaurant inventory systems. First, mis-mapped SKUs: when a supplier’s item ID is not mapped to the correct internal inventory item, invoice lines post to the wrong stock record. The error stays invisible until a physical count reveals a discrepancy between the system and the shelf. Second, unvalidated OCR lines: when an extracted quantity, pack size or net unit cost is accepted without human review of low-confidence fields, the wrong figure posts to stock and COGS. Misreading “1 case of 12” – meaning one case containing twelve units, as in Pfizer’s “Unit of Sale size: 1 Case of 12 Containers” – as “12 cases” overstates stock by a factor of twelve. Third, matching against ordered quantities rather than the accepted-quantity control described earlier: when the system matches the invoice to the purchase order rather than the goods received note, shortages and substitutions are invisible. The system posts what was ordered, not what arrived, and stock is overstated by the value of every undelivered unit.

How Do You Standardise Units and Pack Sizes on Supplier Invoices?

Map each supplier item ID to an internal inventory item once, then normalise every invoice line to the receiving unit. The 1L bottle example above shows how this works in practice: the case price normalises to a per-litre cost, and that per-litre figure is what reaches the recipe. For weight-based items, the unit price is calculated as the total price divided by weight per item multiplied by number of items, so a case of 6 × 2kg normalises to 12kg, giving a per-kg cost of the case price divided by 12. The mapping is stored against the supplier item ID and reused on every subsequent invoice from that supplier, so the normalisation happens automatically rather than requiring manual calculation on each delivery. The internal item, with its receiving unit and net unit cost, becomes the single source of truth for stock, recipe costing and COGS, regardless of how the supplier describes or packages the product.

Do I Still Need to Check Invoices If They Are Automated?

Teams still need to check invoices, but only the exceptions. Automation handles the routine lines where the extracted data matches the PO, the goods received note and the internal SKU mapping within tolerance. A named person reviews only the flagged exceptions such as price changes, substitutions, shortages, damaged goods, credits and duplicate invoices. Nothing posts to stock until it is approved. The review loop is exception-first, so a finance manager or operations manager spends minutes reviewing flagged lines rather than hours processing every invoice manually. Human judgement applies where it adds value, on genuine discrepancies, rather than on routine data entry that automation handles more accurately.

What Is the Difference Between Two-Way and Three-Way Matching in a Restaurant Context?

Two-way matching compares only the purchase order and the supplier invoice and checks whether the price and quantity billed match what was agreed. It can catch overbilling on price but cannot verify whether the goods actually arrived, because there is no receiving document in the comparison. Three-way matching adds the goods received note, which records what was physically accepted at delivery. For a restaurant or pub receiving physical goods such as food, beverage and packaging, three-way matching is the appropriate control because it catches shortages, substitutions and damaged goods that a two-way match would miss entirely. Two-way matching is appropriate for services, subscriptions and recurring fixed-fee charges where there is no physical delivery to record.

How Does Mixed VAT Treatment Affect Invoice Matching in the UK?

UK supplier invoices in hospitality frequently carry both standard-rated and zero-rated goods on the same document, for example alcoholic beverages at 20% VAT alongside basic foodstuffs at 0%. HMRC requires that a full VAT invoice state, for each description of goods or services, the rate of VAT and the amount payable excluding VAT, although less detailed or modified VAT invoices may be issued in certain circumstances such as where the consideration for the supply does not exceed £250, so the matching system must capture the tax rate per line rather than applying a single rate to the invoice total. A line-level VAT mismatch, where a zero-rated item is coded as standard-rated by the supplier or in the stock master, creates a VAT variance that must be resolved before the invoice is posted. Failing to capture and validate VAT at line level affects the accuracy of the COGS posting and the operator’s ability to reclaim input VAT. That creates both a margin problem and a compliance risk.

Conclusion

Linking supplier invoices to restaurant inventory software is only as accurate as the matching and validation layer. A single mis-mapped SKU or unvalidated OCR line silently corrupts stock counts, dish costs and gross profit, and by the time the accountant’s report arrives, the damage already sits in the margin. The four-stage workflow of Capture, Extraction, Matching and Syncing is where accuracy is won or lost, and three-way matching against accepted delivery quantities is what protects margin.

Jelly automates the routine and surfaces the exceptions, so approved costs flow into live dish costing and menu margins without corrupting stock counts. The capabilities described above come together in a single platform that supports operators who want accurate numbers without heavy implementation.

Ready to make the link between supplier invoices and your inventory genuinely accurate? Book a demo or schedule a chat with Jelly today.