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

Key Takeaways

  • Automating invoice handling with OCI for restaurants uses Object Storage, Document Understanding, and Oracle Integration Cloud to ingest, extract, validate, and post supplier invoices without manual data entry.
  • The validation layer is critical. Approved-supplier checks, delivery-note matching, quantity variance, price-versus-history alerts, and duplicate detection protect gross profit and catch fraud.
  • UK VAT compliance depends on capturing supplier VAT numbers, per-line VAT rates, and all mandatory HMRC fields so finance teams can reclaim input tax and reduce compliance risk.
  • Extracted line items feed real-time food-cost percentage, gross-profit margin, supplier price movement, and invoice-processing KPIs. These metrics support faster decisions on repricing, renegotiation, and credit-note recovery.
  • For growing restaurants that want the outcome without a build, see how Jelly automates invoice scanning and price alerts from day one, with live dish costing and Xero integration.

Step 1: Ingest Supplier Invoices Into OCI Object Storage

The pipeline starts with a dedicated supplier invoice email address that forwards attachments directly into an OCI Object Storage bucket. Alongside email, SFTP drops and mobile photo uploads act as additional ingestion paths. An OCI Functions trigger or an OCI Events rule on the com.oraclecloud.objectstorage.createobject event type then fires the extraction pipeline automatically when a new file lands.

Restaurant supplier invoices are not clean corporate PDFs. They arrive as multi-page wholesaler documents, phone photos taken in a busy kitchen, handwritten delivery-note amendments, credit notes, and email attachments from a named sales rep rather than a finance mailbox. Because so many arrive as phone photos, the pipeline needs a consistent naming or metadata convention to tell a delivery note from a tax invoice before extraction begins.

Pro Tip: Set a lifecycle policy on the raw-invoice bucket to archive rather than delete documents. HMRC requires VAT records to be retained for at least six years, so deletion is not an option.

Step 2: Extract Line-Item Data With OCI Document Understanding

OCI Document Understanding is the extraction engine. It supports invoice parsing, extracting vendor details, totals, line items, and currencies from both digital and scanned documents via REST API. OCI Document Understanding’s built-in model can handle different invoice layouts without custom training. Oracle community experts advise trying it first and moving to a custom model only if extraction accuracy proves insufficient. As Oracle ACE Director Gianni Ceresa notes, the service uses an AI model rather than a template engine, so it does its best to extract required information from any document format.

For a restaurant pipeline to be useful, the extraction model must map every field that later validation and VAT reporting depend on. Miss any of these and the invoice cannot be matched or posted:

  • Supplier name, address, and VAT registration number
  • Invoice number and invoice date
  • Due date and tax point if different from invoice date
  • Purchase order or delivery note reference
  • Line-item description, SKU or supplier product code
  • Quantity and unit of measure
  • Unit price, line discount, line VAT rate, and VAT amount
  • Invoice subtotal, total VAT, and invoice total

For multi-page invoices, split at page level before extraction. Set confidence thresholds per field and route any document below the threshold to a human review queue. This prevents low-confidence invoices from posting automatically. OCI Generative AI can normalise messy supplier product descriptions. It can map entries such as “chicken breast 2.5kg” and “chkn brst 2.5kg” to the same ingredient record so line items can be matched to recipes downstream.

Step 3: Apply The Restaurant Validation Layer

Once the line items are extracted, they still need to be checked before they can post. This validation layer is where the project either protects gross profit or stalls. Five rules are non-negotiable for a restaurant deployment.

  1. Approved-supplier check. Reject or flag invoices from suppliers not on the approved list. Flag any bank detail change on a known supplier as a fraud risk. Deloitte’s 2025 AP Controls Benchmark found AI-assisted duplicate detection catches 98% of duplicate invoices versus 63% for manual review, and organisations with AI-powered AP controls experienced 48% fewer AP fraud incidents.
  2. Purchase order and delivery note matching. In restaurants the delivery note is often the only pre-invoice document, so the match is invoice-to-delivery rather than invoice-to-PO. A three-way match between PO, goods received note, and invoice is the ideal. A two-way invoice-to-delivery match is the practical minimum.
  3. Quantity variance tolerance. Flag any line where invoiced quantity exceeds delivered quantity beyond a set tolerance, and any line billed for goods never delivered. These discrepancies are a common margin leak: a restaurant may order 20 cases, receive 18, and be invoiced for 20.
  4. Price-versus-history alerts. Store every historical unit price per supplier and SKU. Flag any line where the unit price has risen since the last invoice. This rule often delivers the largest gross-profit protection. With USDA forecasting wholesale beef up 9.4% in 2026, a $1.15 burger patty drifts to about $1.26, which surrenders nearly a full food-cost percentage point on one commodity line.
  5. Duplicate invoice detection. Match on supplier plus invoice number plus total plus date window to catch re-submitted invoices and credit notes applied incorrectly. Between 0.8% and 2% of invoices are paid twice in organisations without robust duplicate controls.

A worked example helps show the impact. A supplier invoices 24 kg of beef at £11.40/kg when the last three invoices were £10.20/kg. The price-versus-history rule flags a £28.80 variance on that line. The invoice is held in the exception queue, and the operator raises a credit note request before payment runs.

Watch Price Alert catch a supplier price rise in real time.

Step 4: Orchestrate With Oracle Integration Cloud And Sync To ERP

With validation rules in place, the next step wires the extraction and validation calls into a single flow. Oracle Integration Cloud is the orchestration layer that does this. OIC Gen 3 includes a Document Understanding Adapter that connects directly to the OCI Document Understanding service, so the extraction call becomes a native action in the integration flow rather than a custom REST call.

The integration flow runs as follows. An OCI Events trigger fires on object creation in the invoice bucket. The first OIC integration reads the event payload and passes the file name to the second integration. The second integration calls OCI Document Understanding with Object Storage as the input source, maps the extracted fields, applies the validation service, and routes the result to either auto-post or an exception queue. This event-driven pattern eliminates polling and triggers processing automatically the moment a document lands.

For operators on Oracle ERP Cloud, the OIC ERP Cloud Adapter maps the supplier, invoice header, and invoice lines. It also routes the distribution to the correct cost-of-goods-sold account and maps the tax lines. For operators on Xero or Sage, the structured invoice payload is pushed via REST. Jelly integrates with Xero today, with Sage integration coming soon. This mapping step is where many DIY projects stall, because every accounting system expects a different payload shape.

Step 5: Capture The UK VAT Fields HMRC Requires

Before a validated invoice can post, the extraction model must capture the fields HMRC requires for input tax recovery. A full UK VAT invoice must contain 14 mandatory fields under HMRC rules, while a simplified VAT invoice for supplies of £250 or less requires only four core fields:

  • Supplier business name, address, and VAT registration number
  • A unique sequential invoice number
  • Invoice date and tax point (time of supply) if different from the invoice date
  • Customer name and address
  • Description of goods or services sufficient to identify the supply
  • Quantity and unit of measure per line
  • Unit price excluding VAT per line
  • VAT rate per line
  • Line total excluding VAT
  • Subtotal excluding VAT
  • Any cash discount rate offered
  • Total VAT in sterling, broken down by rate if multiple rates apply
  • Total amount payable including VAT
  • Currency of the invoice if not in sterling

The extraction model must capture the supplier VAT number and per-line VAT rate specifically, because these fields support VAT returns and input tax recovery. HMRC requires a valid VAT registration number on an invoice for the buyer to reclaim input tax, and it is the field HMRC inspects first. Restaurant meals are standard-rated at 20%, while most food ingredients and retail food are zero-rated for VAT in the UK, so a single wholesaler invoice may carry both rates on different lines.

Common Mistake: Treating a delivery note or a proforma as a VAT invoice. Neither satisfies HMRC’s requirements for input VAT recovery. A till receipt proves payment occurred; it is not a VAT invoice. The extraction pipeline must reject delivery notes routed to the invoice bucket rather than passing them to the posting queue.

Step 6: Report Food Cost And Invoice-Processing KPIs

Extracted and validated line items become the data foundation for two reporting layers: food-cost percentage and AP processing KPIs.

Food cost percentage for a period is calculated as (Beginning Inventory + Purchases − Ending Inventory) ÷ Food Sales × 100. Because every invoice line item is captured at the point of receipt, purchases are always current, which means this calculation can run at any time without a manual stock count. Each of these KPIs maps to a specific decision, such as repricing a dish, switching supplier, renegotiating a contract, or chasing a credit note before the payment run:

Build Vs Buy: Running This On OCI Or Buying The Outcome

The architecture described above is achievable, but it is not the only route. An OCI DIY build makes sense for operators with in-house integration resource, a multi-site estate with bespoke ERP requirements, or a technology team already running Oracle. The architecture above provides a solid pattern, and Oracle’s documentation covers the extraction and orchestration layers in detail.

For most growing restaurants, pubs, and boutique hotels, the integration project is the wrong use of time. The validation layer, VAT compliance mapping, and food-cost reporting described above represent weeks of configuration work. Every accounting system change or new supplier format then adds ongoing maintenance.

Jelly delivers the same outcome without the build:

  • Automated invoice scanning via email or photo, with every line item digitised
  • Price Alert for supplier price increases, using the same price-versus-history rule described in Step 3 and surfacing changes the same week they occur
  • Live dish costing that updates automatically as new invoices arrive
  • Flash Report for daily, weekly, or monthly gross profit margin
  • One-click push into Xero, with Sage integration coming soon
  • Native POS integration with Square, EPOS Now, Toast, and Lightspeed for live sales data and margin reporting

Jelly onboards and generates initial value in the first week. Users save 10–20 hours of admin per month, cut food costs by 3% on average in the first three months, and add 2 percentage points to gross margins. Pricing is a flat £129 per month per location with no per-user charge.

Amber, a Mediterranean restaurant in East London run by Chef-Owner Murat Kilic, saves £3,000–£4,000 per month through invoice automation, price-change alerts, and real-time costing. “Jelly keeps my business alive.” One operator moved gross profit from 65% to 72% within 12 weeks on approximately £500,000 in revenue.

See the validation layer OCI’s documentation leaves out.

Frequently Asked Questions

What Are The Steps Involved In Processing A Restaurant Invoice?

A restaurant invoice moves through five stages: receipt and ingestion (email, photo, or SFTP), line-item extraction (capturing supplier details, quantities, unit prices, and VAT rates), validation (approved-supplier check, delivery-note matching, quantity variance, price-versus-history, and duplicate detection), posting to the accounting system or ERP, and reporting into food-cost and gross-profit dashboards. The validation stage is the step that generic invoice-automation tools often omit and the step that most directly protects gross profit in a restaurant operation.

How Do You Validate A Supplier Invoice Against A Purchase Order?

In a standard three-way match, the system compares the purchase order, the goods received note or delivery note, and the supplier invoice. It flags any line where invoiced quantity, unit price, or total deviates beyond a set tolerance. In many restaurant operations, a formal purchase order does not exist, so the match becomes a two-way comparison between the delivery note signed at the kitchen door and the invoice that follows. Any line where the invoiced quantity exceeds the delivered quantity, or where the unit price has risen since the last invoice from that supplier, is held for review before payment.

What Is A Good KPI For Invoice Processing?

For a restaurant operation, the most actionable invoice-processing KPIs are food cost percentage by site, supplier price movement by ingredient, invoice cycle time from receipt to payment-ready, exception rate, and credit-note recovery value. As the benchmarks above show, best-in-class teams process invoices far faster and hold far fewer exceptions than the average organisation. For restaurants specifically, the credit-note recovery value, or cash recovered from flagged price variances and quantity discrepancies, is often the single highest-return metric to track.

What Is The Difference Between An Invoice And A VAT Invoice?

A commercial invoice records a transaction and may satisfy a contractual obligation, but it does not necessarily contain the information HMRC requires for input VAT recovery. A VAT invoice is a legally defined document under UK VAT regulations (SI 1995/2518) that must include the mandatory fields listed above, including the supplier’s VAT registration number, a per-line VAT rate, and the total VAT in sterling. It is the only document that entitles the recipient to reclaim input tax on a VAT return. A delivery note and a proforma invoice are neither, and treating them as VAT invoices breaks input VAT recovery and creates an HMRC compliance risk.

Conclusion: From Extraction To Gross Profit

OCI gives restaurants a capable extraction engine. The engine alone does not handle an invoice. The approved-supplier check, delivery-note matching, price-versus-history alerting, UK VAT compliance mapping, and food-cost reporting described in this guide form the layer that determines whether the project protects gross profit or stalls in a queue of unmatched exceptions.

For operators with the integration resource to build and maintain that layer, the OCI architecture above is a sound foundation. For growing restaurants, pubs, and boutique hotels that need the outcome without the project, Jelly delivers every step, from invoice scanning to live gross profit margin, without the integration project.

Turn supplier invoices into gross profit intelligence.