Written by: JJ Tan, Founder, Jelly

Key Takeaways

  • Amazon Textract AnalyzeExpense extracts vendor names, invoice numbers, dates and line items from supplier invoices. It acts as an extraction layer rather than a complete automation solution.
  • UK restaurant invoices create specific challenges including catch-weight items, mixed VAT rates and handwritten delivery notes. These require additional validation logic beyond basic OCR.
  • Building a production pipeline involves five stages: ingestion, triggering, extraction, parsing and routing. Most costs come from integration, validation and human review rather than the model itself.
  • Textract does not handle normalisation across suppliers, supplier price tracking, dish-level costing, recipe management or POS integration. Teams must build or purchase these functions separately.
  • Jelly automates the complete flow from invoice capture through dish-level costing and accounting integration at a flat rate of £129 per month per location.

See Jelly In Action For Your Invoices

What Amazon Textract AnalyzeExpense Actually Returns

AnalyzeExpense is a synchronous Amazon Textract operation that analyses an invoice or receipt and returns financially related fields as ExpenseDocument objects. Those objects split into two parts: SummaryFields for header data such as vendor name, invoice number, dates and totals, and LineItemGroups for line-level data such as item descriptions, quantities and prices.

For a real UK restaurant supplier invoice, the response maps as follows:

  • VENDOR_NAME — the supplier’s legal or trading name from the invoice header
  • INVOICE_RECEIPT_ID — the invoice number
  • INVOICE_RECEIPT_DATE — the invoice issue date
  • DUE_DATE — the payment due date
  • SUBTOTAL — net goods value before VAT
  • TOTAL — the amount payable including VAT
  • ITEM_DESCRIPTION — line-level product description
  • UNIT_PRICE — price per unit or per kilogram
  • QUANTITY — ordered or delivered quantity
  • PRICE — extended line amount

These labels are normalised names rather than guarantees of presence or accuracy. Output quality depends on the invoice image and Textract’s detection. The AWS SDK documentation is explicit: summaryFields() and lineItemGroups() never return null, so production code must use hasSummaryFields() and hasLineItemGroups() to distinguish “nothing found” from “empty collection”. Attempts to modify the returned collections throw an UnsupportedOperationException, so results must be copied into mutable structures before normalisation. For multi-document files, expenseIndex() identifies which invoice each ExpenseDocument belongs to, with the first document indexed as 1.

The amazon textract analyzeexpense operation runs synchronously for single-page images. For multi-page PDFs, which are standard in a production restaurant pipeline, the asynchronous startExpenseAnalysis and GetExpenseAnalysis pair is required.

How To Build A Textract Invoice Pipeline For A Restaurant

A production pipeline for restaurant supplier invoice OCR UK follows five stages:

  1. Ingestion — supplier PDFs and phone photos land in an Amazon S3 bucket.
  2. Trigger — an S3 event notification invokes an AWS Lambda function.
  3. Extraction — call startExpenseAnalysis for multi-page PDFs and reserve synchronous AnalyzeExpense for single-page images only.
  4. Parsing — parse the JSON with the Amazon Textract Response Parser, then pass through a normalisation layer.
  5. Routing — push validated output to accounting or POS, or route to exception review.

Synchronous calls accept only single-page images and small documents, and users will eventually upload a 60-page PDF to a single-page endpoint. Default to asynchronous for anything user-uploaded. The diagram below shows how the five stages connect end to end, including the exception path back to human review.

[Supplier PDF / phone photo] | v Amazon S3 bucket | (S3 event notification) | v AWS Lambda ---> startExpenseAnalysis ---> Amazon Textract | | | (job complete) v v Textract Response Parser <---- GetExpenseAnalysis ----+ | v Normalisation layer ---> Amazon Bedrock (low-confidence reconciliation) | v Validation layer (arithmetic, VAT, catch-weight) | +--> auto-approve --> Xero / POS | +--> exception queue --> human review

The Python snippet below shows the startExpenseAnalysis call with the S3 event notification pattern, using the London region:

import boto3 textract = boto3.client("textract", region_name="eu-west-2") def lambda_handler(event, context): bucket = event["Records"][0]["s3"]["bucket"]["name"] key = event["Records"][0]["s3"]["object"]["key"] response = textract.start_expense_analysis( DocumentLocation={"S3Object": {"Bucket": bucket, "Name": key}}, NotificationChannel={ "SNSTopicArn": "arn:aws:sns:eu-west-2:123456789012:textract-jobs", "RoleArn": "arn:aws:iam::123456789012:role/TextractPublishRole", }, ) return {"JobId": response["JobId"]}

Textract Adapters allow fine-tuning for enhanced performance on user-provided documents such as a specific supplier’s invoice format. Amazon Bedrock foundation models handle the interpretation layer above Textract, such as reconciling values that do not match or deciding what to do with an exception. That includes the judgment call of deciding what a partially legible handwritten note says relative to the printed line it annotates.

OCR Invoice Scanning for UK Hospitality Businesses covers the generic OCR layer in detail and is not repeated here.

Accuracy of Data Extraction from Invoice Scanning covers field-level accuracy benchmarks across document types. With the pipeline in place, the next question is where it breaks on real UK invoices, and the failures rarely sit in extraction itself.

Explore A Working UK Invoice Pipeline

UK Failure Modes: Where Textract Stops

The three places a UK hospitality build stalls all sit in the layer that interprets what the extracted values mean. Textract reads the values correctly, and the failures happen after extraction.

Handling Catch-Weight Items In Textract Invoice Extraction

For catch-weight lines, QUANTITY × UNIT_PRICE does not equal PRICE. The invoice shows an ordered quantity, an actual delivered weight, a price per kilogram and an extended amount. Textract reads each value correctly without inferring their relationship.

Because catch-weight lines break the quantity-times-price rule, the validation layer has to recompute the expected line amount and compare it against the printed PRICE. Any variance above a 1p or 0.5% tolerance is flagged for review rather than corrected automatically, and the original value, the calculated value and the delta are all retained so the discrepancy stays auditable.

This matters for food costing because a misread weight silently corrupts dish GP. A correct description with the wrong pack conversion creates a larger food-cost error than a mistyped price. Neither failure becomes visible until the month-end variance report arrives too late to act on.

Validating UK VAT On Textract-Extracted Supplier Invoices

A single wholesaler delivery can carry zero-rated food and standard-rated alcohol on the same invoice. Alcoholic beverages are standard-rated at 20% VAT in the UK regardless of where or how they are sold, while most qualifying food is zero-rated. A single blended VAT percentage across a mixed invoice does not provide a reliable validation target.

Because a single invoice can carry both zero-rated food and standard-rated alcohol, the validation layer has to group lines by their extracted rate and sum net plus VAT within each group before comparing against SUBTOTAL and TOTAL. A 2p tolerance absorbs multi-line VAT rounding, and anything outside that tolerance should be stopped for review rather than auto-posted.

Textract extracts what is printed and does not know UK VAT rules. Store tax_rate, tax_type and tax_amount explicitly per line rather than inferring from a document-wide percentage. A mixed-rate invoice must be subtotalled separately by rate before the combined invoice total is validated. This prevents a zero-rated food line from incorrectly inheriting the 20% rate of an alcohol line.

Routing Low-Confidence Handwritten Delivery Notes

A delivery driver handwrites a shorted item and the printed total no longer matches. Textract supports handwriting, but handwritten fields receive meaningfully lower confidence than print, especially cursive and dense handwriting.

Three-banded confidence routing handles this scenario. Auto-accept values above a high threshold, apply extra validation between thresholds and send anything below the floor to human review. Calibrate thresholds on your own documents, not intuition. Run the first 500 invoices through the pipeline, manually verify correct output for each and set the auto-approve floor at the score where the false-positive rate drops below 0.5%.

Textract Adapters tune extraction to a specific supplier’s layout. Bedrock handles the judgment call of reconciling printed text against handwritten notes. The model is rarely the problem. The problem lives at the seams, including type classification, validation, locale normalisation and the human queue. Many DIY builds stall here because nobody staffed the review queue.

Amazon Textract Pricing UK: The GBP Cost Reality Check

The widely cited figure for AnalyzeExpense is $0.01 per page for the first one million pages per month, and that rate applies to US West (Oregon). AWS does not publish a UK or European AnalyzeExpense rate in GBP in its retrieved pricing content. For the rate applicable to your selected European region and billing currency, check the live AWS Textract pricing table and the AWS Pricing Calculator directly.

AnalyzeExpense includes OCR in its output and is priced per page. A four-page invoice costs four times the regional per-page rate. Every page is billed, including blank fax cover sheets, so pre-filtering junk pages before analysis pays for itself at volume.

The hidden costs that dominate the actual bill sit outside the model call:

  • S3 storage and request charges for ingestion, retention and retrieval, which grow with history length and image size
  • Lambda invocations per document and per retry, which scale with traffic spikes and error handling
  • Textract Response Parser compute, which increases with document complexity and post-processing
  • Engineering time to build and maintain the validation layer, including VAT logic and catch-weight handling
  • The human review queue, including a named owner, an SLA and a daily zero-out target

The model cost is almost never the dominant line item in a real invoice OCR deployment. The dominant costs are integration into the ERP or AP system, the human review queue, and ongoing maintenance of validation rules. For a full ROI calculation, see Invoice Automation ROI: Calculate Your Return.

Build Versus Buy: Gaps Textract Leaves Open

Textract gives you raw extraction of vendor, date, totals and line items. That capability is genuinely useful and genuinely cheap. The honest verdict on amazon textract alternatives for restaurant invoice automation starts with being clear about what the extraction layer does not include:

  • Normalisation Across Suppliers — the same ingredient described five different ways on five different invoices maps to five different SKUs unless you build the mapping layer
  • Supplier Price-Change Tracking — knowing which ingredient went up, by how much and from which supplier, flagged the week it happens
  • Dish-Level Costing — batch recipes, sub-recipes, yields, trim loss and portion logic cannot be inferred from invoice OCR
  • Recipe And Wastage Handling — the gap between what you buy and what reaches the plate
  • POS Integration — connecting sales data to cost data for live GP visibility
  • Accounting Integration — pushing digitised invoices into Xero with correct nominal codes

Jelly is designed to operate as the layer above extraction. It scans every line item of an invoice via photo or email and normalises it across suppliers, closing the SKU-mapping gap. Its Price Alert feature then tracks supplier price changes, flagging every increase or decrease with the hard data needed to negotiate credits.

Live dish costing in the Cookbook updates every time a new invoice lands, so the GP margin on every dish stays current. Digitised invoices push directly into Xero, producing a 90% reduction in bookkeeping time. Jelly integrates natively with Square, EPOS Now, Toast and Lightspeed as complementary tools, pulling item-level sales data in real time to power the Flash Report and Sales Mix views.

Jelly charges a flat rate of £129 per month per location with no variable charge per user or feature, and onboarding generates initial value in the first week. Customers report saving 10–20 hours of admin per month. In the first three months, they also report a 2 percentage point gross margin improvement and a 3% food cost reduction, alongside a 90% reduction in bookkeeping time. Costing a menu item drops from 28 minutes in a spreadsheet to 3 minutes in Jelly’s Cookbook.

Compare Jelly To Your Current Workflow

Decision Checklist: Build With Textract Or Buy A Platform

Use the points below to decide whether to extend Textract yourself or adopt a platform that already handles the layer above extraction.

Build with Textract if:

  • You have in-house engineering resource to build and maintain a validation layer
  • You have a small number of stable supplier layouts that do not change frequently
  • You have no requirement for dish-level costing, supplier price tracking or POS integration
  • You can staff a human review queue with a named owner and a defined SLA

Buy a platform such as Jelly if:

  • You need normalisation across multiple suppliers with inconsistent invoice formats
  • You need UK VAT validation before pushing to Xero
  • You need catch-weight line handling without building the arithmetic and exception logic yourself
  • You need supplier price-change tracking with actionable alerts
  • You need dish-level GP that updates automatically as invoices land
  • You need POS and Xero integration without building and maintaining the connectors

Frequently Asked Questions

Is OCR 100% Accurate On Restaurant Supplier Invoices?

OCR never reaches 100% accuracy across all document types. Accuracy is high on clean, well-formatted digital documents and drops on poor scans, unusual layouts and handwriting. Independent 2026 benchmarks put field accuracy for cloud document intelligence tools in the mid-90s on clean documents, with meaningful degradation on phone photos, faxes and old photocopies.

Production pipelines route low-confidence results to human review rather than assuming a single accuracy figure applies across all document types. The relevant metric is the straight-through processing rate on your actual supplier corpus, measured after calibrating confidence thresholds on ground-truth data.

Can Amazon Textract Handle Multi-Page Supplier Invoices?

Textract handles multi-page supplier invoices through the asynchronous path. Synchronous AnalyzeExpense accepts single-page images and small documents. Multi-page PDFs, which are standard for a wholesaler invoice covering a full delivery, require startExpenseAnalysis, with results retrieved via GetExpenseAnalysis once the job completes. A synchronous-only pipeline often works in testing on single-page samples and fails in production when a 60-page PDF arrives.

Does Amazon Textract Validate UK VAT?

Textract does not validate UK VAT. It extracts what is printed on the document and does not know that most qualifying food is zero-rated under HMRC rules, that alcohol is standard-rated at 20% regardless of how it is sold, or that a mixed-rate invoice must be subtotalled separately by rate before the combined total is validated. That validation logic is the operator’s responsibility to build.

Storing tax_rate, tax_type and tax_amount explicitly per line, rather than inferring from a document-wide percentage, is the correct approach. A 2p tolerance handles multi-line VAT rounding on standard-rate UK invoices, and anything outside tolerance should be stopped for review rather than auto-posted.

What Happens After Textract Extracts The Data?

Extraction is the first stage of a five-stage pipeline: ingestion, triggering, extraction, parsing and routing. Most off-the-shelf OCR delivers ingestion and extraction and leaves parsing, validation and routing, where the financial risk lives, to manual work.

The validation stage covers arithmetic reconciliation, VAT rate checking, catch-weight line handling, confidence routing and duplicate detection. The routing stage covers nominal ledger code classification, idempotent write logic and accounting platform compatibility. The gap between extraction and a trustworthy posted invoice forms the core build-versus-buy decision.

How Does Jelly Handle The Layer Above Extraction?

Jelly handles the layer above extraction by normalising line items across suppliers, tracking price changes through Price Alert and updating dish GP in the Cookbook as invoices land. It also pushes digitised invoices to Xero and connects cost data to POS sales data for a live GP view. The Build Versus Buy section above covers the full feature set and commercial model.

Conclusion: Extraction Is The Easy 20%

Amazon Textract AnalyzeExpense provides a well-engineered extraction layer. It reads vendor names, invoice numbers, dates, totals and line items from supplier invoices reliably on clean documents and does so at a per-page cost that keeps the model itself as a minor line item in the total build cost.

The hard 80% sits above extraction. Teams must normalise ingredient descriptions across suppliers, validate UK VAT on mixed-rate invoices before posting to Xero, handle catch-weight arithmetic without silently corrupting dish GP, track supplier price changes with enough speed to act on them and connect all of it to dish-level costing and POS sales data. All of that sits above extraction, where AnalyzeExpense does not reach.

The next step is to assess where your build stops being worth it relative to a purpose-built platform that already runs that layer.

See How Jelly Replaces A DIY Validation Layer