Written by: JJ Tan, Founder, Jelly
Key Takeaways
- SAP invoice automation for multi-site restaurants depends on correct site hierarchy mapping to company codes, profit centres and cost centres before automation starts.
- Supplier master data needs central governance with duplicate detection, validated bank details and consistent payment terms across all locations.
- Three-way matching works best with category-specific tolerance bands, especially for fresh produce and catch-weight items, and clear exception routing to buyers or site managers.
- Non-PO invoices need AI-suggested GL coding and approval routing by spend threshold while maintaining UK VAT compliance and six-year record retention.
- For fast, accurate site-level invoice data, book a demo with Jelly to see automated capture, price alerts and real-time dish costing alongside SAP.
Mapping Restaurant Sites to SAP Company Codes, Profit Centres and Cost Centres
The site-first profitability model in SAP uses a three-level hierarchy: the legal entity sits at company code level, sites and brands sit at profit centre level, and site departments and functions sit at cost centre level. For a restaurant group, the limited company that trades a site is the company code, the individual restaurant or pub is the profit centre, and the kitchen or bar function within that site is the cost centre.
In SAP S/4HANA, every cost centre must be linked to exactly one profit centre, which is now mandatory. Every cost posted at site level flows automatically into the assigned profit centre in CO-PCA, and the account-based CO-PA framework creates a CO-PA line item with the profit centre populated. Because every posting inherits the profit centre from the cost centre, the site hierarchy must be correct before a single invoice is posted.
Every profit centre must belong to the standard hierarchy as a leaf node. Hierarchy nodes act purely as grouping folders and cannot hold postings themselves. The standard hierarchy name is set during initial configuration and cannot be changed once profit centres exist beneath it, so this decision comes before any master data load.
SAP recommends a naming convention of the form <CompanyCode>_PC_H, for example 1000_PC_H, using uppercase, no spaces and a maximum of 12 characters. Cost centre IDs should follow a structured convention that supports range-based grouping in reports, with a company or site prefix distinguishing same-function cost centres across locations.
A worked example clarifies this. A fresh produce invoice for a specific London site uses the legal entity that trades the site as the company code. The profit centre is the London restaurant. The cost centre is the kitchen function at that site. The GL account is food cost of sales. Automated capture determines each element from the invoice header and delivery address.
Changing a cost centre’s profit centre assignment mid-year splits cost history across two profit centres and complicates year-over-year P&L comparison. Organisational changes work better when modelled as a new cost centre, which preserves the integrity of historical management reporting.
Supplier Master Data Governance Across Sites
The same supplier often appears under different names at different locations in a multi-site group, such as “Fresh Direct Ltd” at one site, “Fresh Direct” at another and “FD Produce” at a third. The consequences are concrete: fragmented spend that understates total supplier exposure, weakened negotiating leverage, broken three-way matching and duplicate payment risk. SAP Help Portal guidance on business partner and supplier master data sets out the correct structure, but governance starts as an organisational responsibility.
Duplicate detection works most reliably in tiers. The first tier uses exact VAT number matches. The second tier uses normalised name plus address. The third tier uses shared bank account or remit-to address across different vendor names. The last tier doubles as a fraud check, because a fraudulent near-duplicate vendor can hide among legitimate supplier clutter and collect payments that appear valid.
Bank detail validation deserves separate treatment. Outdated bank accounts are a primary vector for accounts payable fraud via business email compromise. Bank account changes should use a separate, more restricted change request type that requires dual approval by both the AP manager and treasury, independent of the standard vendor master change workflow.
Payment terms that differ across company codes for the same supplier create disputes, which scale badly in multi-entity SAP landscapes. A single supplier maintained under multiple company code views with inconsistent terms produces reconciliation failures and damages supplier relationships.
In SAP S/4HANA, direct vendor creation via transaction XK01 is obsolete. All vendors are now business partners created via the BP transaction or SAP Master Data Governance. Writing directly to LFA1 bypasses business partner validation, breaks MDG audit trails and can cause data inconsistency between the business partner object and the shadow vendor tables.
Best practice assigns a single named owner for vendor master quality, enforces mandatory field validation at entry, and runs a quarterly review of inactive vendors and recently created records. Mandatory fields include VAT number and bank account details before a record can be saved. HMRC’s VAT number checker provides a free service to confirm whether a number is valid and returns the registered business name and address, which supports the first tier of duplicate detection.
Three-Way Matching and Approval Routing in a Restaurant Context
Three-way matching in SAP compares the purchase order, the goods receipt and the supplier invoice during invoice verification. If both quantity and price checks pass, the invoice is released for payment. If either fails, the invoice is blocked and must be cleared manually via transaction MRBR.
The GR/IR clearing account is the balance-sheet liability that absorbs the timing difference between goods receipt and invoice posting. When a match is clean, the GR/IR account nets to zero per line. Open items surface in the GR/IR balance report for resolution.
A price-variance example helps. A purchase order exists for 100kg of chicken at an agreed rate, a delivery note confirms receipt, and an invoice shows a price increase. The variance is flagged before posting rather than paid automatically. Price variances route to the buyer or category manager who negotiated the price. Quantity variances route to the site that recorded the goods receipt.
Fresh produce and seafood legitimately vary in price and weight, so category-specific tolerance bands are necessary. Applying the same tight tolerance to wild salmon and bottled water produces an unmanageable exception queue. Tolerance-aware matching classifies invoice lines into three buckets: matched within a tight band and auto-posted, matched within a wider category-specific band and auto-posted or routed for outlet manager review, and outside tolerance, flagged as an error. Typical bands after live operation converge around ±10–20% price and ±5% quantity for fresh produce. Fresh seafood tolerates ±15–25% price, while frozen and dry goods sit at ±3–5%.
Catch-weight goods such as whole fish and primal cuts need invoiced weight multiplied by contract unit price rather than a simple quantity check. Ten whole snapper ordered at an expected 800g each, delivered at a combined weight of 8,020g, requires the platform to read the invoiced weight, multiply by the contract unit price and compare the result against the PO expected total within tolerance.
Approval workflows should reflect the group’s delegation of authority by site, brand and spend threshold. A workable model uses three bands: under £500, site manager; £500–£5,000, site manager plus operations manager; over £5,000, regional director plus finance. Routing should be configurable by supplier contract, site or approver role so that a price variance on a produce invoice reaches the category buyer rather than a central AP queue.
Handling Non-PO Invoices and UK Compliance
Non-PO invoices such as rent, utilities, marketing, repairs and professional fees cannot be three-way matched. They need AI-suggested GL coding based on vendor patterns and historical postings, with approval routing by spend threshold and site. SAP Ariba Invoicing uses embedded machine learning trained on the company’s invoice history to assign accounting on non-PO invoices, improving accuracy over time as the model learns from corrections.
UK VAT treatment on mixed food and non-food invoices is a persistent source of error in hospitality. Restaurant meals are standard-rated at 20%, while most food is zero-rated at 0%. Bundled supplies where part is standard-rated and part is zero-rated are frequently invoiced as a single line at one rate. Cold sandwiches are zero-rated while hot food is standard-rated, so a bundled meal-deal invoice often takes a single rate incorrectly. Automated line-item extraction must preserve the tax code at line level, not just at invoice header level, to support accurate VAT reclaim.
HMRC requires VAT-registered businesses to retain VAT records and supporting documents for six years, including sales and purchase invoices, credit notes, VAT returns and the VAT account. Digital copies are acceptable provided they are clear, accurate and legible. Limited companies keep records for six years from the end of the last financial year they relate to.
Under Making Tax Digital, VAT-registered businesses must keep digital records in functional compatible software and file through MTD-compatible software. Data transfers between systems must use a digital link, such as API transfers, XML or CSV import and export, or linked spreadsheet cells. Only digital links qualify; cut-and-paste and manual re-keying do not. Any AP workflow that involves re-keying data from one system into another breaks the digital link requirement.
On e-invoicing readiness, SAP Ariba Invoicing supports Peppol networks and compliant e-invoice processing in countries with mandates, and skips OCR entirely for structured Peppol and SAP Business Network invoices. UK groups monitoring the direction of travel on e-invoicing mandates should factor this capability into platform decisions now.
SAP-Native Tools and Specialist AP Layers: How They Differ
SAP Ariba Invoicing, renamed from SAP Ariba Central Invoice Management in February 2026, is a cloud-native solution on SAP Business Technology Platform that centralises invoice processing across multiple connected SAP systems from a single launchpad. It supports four capture channels: file upload, email extraction, structured data inbound API and SAP Business Network integration. It runs background matching against purchase orders and goods receipts and routes exceptions by configurable business rules. It is priced in blocks of 1,000 documents per year with contract durations from 3 to 36 months. Extraction results for an average invoice return in approximately 30 seconds, but fields with a confidence score below 50% are not saved to the draft invoice, which requires manual correction by AP teams.
SAP Document AI is SAP’s intelligent document processing service. SAP states it can save up to 70% of time on document processing. It operates as an extraction service rather than a complete AP workflow or posting engine, orchestration typically requires SAP BTP or Integration Suite, it does not translate documents, and extraction accuracy degrades with poor scan quality.
InvoiceIQ by Decision Engines Inc is listed on SAP’s partner pages as an intelligent global accounts payable automation solution that works alongside SAP rather than replacing it, although the InvoiceIQ name is also used by other, unrelated AP automation products.
SAP-native tools offer deep integration, centralised visibility across company codes and a single vendor relationship. The trade-offs are real. They are priced per document block and require BTP configuration and SAP Basis involvement. They are also not built around restaurant-specific coding across many sites or dish-level margin output. A multi-site restaurant group processing invoices across 15 sites needs cost centre coding, price alert logic and real-time dish costing, which SAP-native tools do not deliver out of the box.
For the operational layer that SAP-native tools do not cover, a specialist AP layer can sit alongside SAP. This layer handles site-level invoice capture, price alerts and dish costing, then feeds structured data into the wider stack. Jelly is one such layer. It automates invoice capture, digitises line items, raises price alerts and provides real-time dish costing while integrating with accounting tools such as Xero.
How To Assess Readiness Before You Automate
Automation readiness spans five dimensions: people, process, data quality, supplier coordination and system integration. A staged capability model across these dimensions reveals where the foundations need work before any automation layer is switched on.
A practical readiness checklist:
- Confirm the site hierarchy is already defined in SAP, with each site mapped to a company code, profit centre and cost centre.
- Confirm the vendor master is clean, with duplicates resolved and bank details validated.
- Confirm approval thresholds are documented and mapped to the delegation of authority by site, brand and spend level.
- Check whether invoices arrive as structured PDFs or mixed batch scans.
- Check whether the POS feeds item-level sales data into your costing.
POS integration should feel straightforward. Connecting a supported POS typically takes about five minutes and follows the same flow across systems. Open Jelly, click Integrations, sign in to the POS, grant permissions and select which categories to sync. POS-to-dish linking only surfaces items sold since the integration was connected, which keeps mapping clean and free of legacy menu clutter. Connecting a POS automates 2–5 hours of weekly work and delivers real-time margins and sales mix data.
Implementation Structure: A Four-Phase Sequence
- Phase 1 — Fix the Foundations: define the site hierarchy, map company codes and cost centres, govern the supplier master and agree the approval model. Nothing downstream works if this is wrong, and groups that skip this phase simply automate bad data faster.
- Phase 2 — Automate Intake and Capture: set up dedicated invoice email addresses per site, enable photo or email capture and apply AI line-item extraction of quantity, SKU, price and tax. Jelly generates price alerts and spending insights once suppliers send invoices to a dedicated email address or within 24 hours of photographing invoices into Jelly.
- Phase 3 — Automate Coding, Matching and Approval: code line items to the right site and cost centre, apply three-way matching with category-appropriate tolerances, route exceptions to the right owner and enforce delegation of authority by threshold.
- Phase 4 — Post to SAP and Connect the Wider Stack: push digitised invoices into accounting software such as Xero, integrate POS data and generate real-time margin reporting. Jelly reduces bookkeeping time significantly by automating these posting and reconciliation steps.
Cross-functional alignment between kitchen, finance and operations teams underpins each phase. When these teams agree the model upfront, each implementation step lands faster and with fewer rework cycles.
Common Challenges and Pitfalls
The most common failure modes in multi-site restaurant invoice automation are organisational before they are technical:
- Inconsistent data capture across sites, so the same supplier and the same ingredient are recorded differently at each location.
- Delayed reporting, where monthly accountant reports arrive too late to react to supplier price changes or low-margin performance.
- Overreliance on spreadsheets, where dish costing takes 28 minutes per menu item and drifts out of date the moment a supplier changes a price.
- Poor adoption by busy chefs who are not tech-savvy and will not spend time on paperwork.
- Fragmented systems, with POS, accounting and invoice data living in separate places with no digital link between them.
- Duplicate supplier records that fragment spend and break three-way matching.
- Unclear approval ownership, so invoices sit unresolved and supplier relationships suffer.
- Automating before the site hierarchy and supplier master are fixed, which processes bad data faster rather than better.
Best-Practice Characteristics for SAP Invoice Automation
Effective SAP invoice processing automation for multi-site restaurant groups shares a consistent set of characteristics: a single source of truth across sites, real-time gross profit visibility, automated price alerts, clean supplier data and approval routing that matches the group’s delegation of authority. The system stays simple enough for a busy chef to use without training and accurate enough for a finance director to trust without waiting for a monthly report.
These characteristics show up in practice as faster reporting and fewer manual corrections. One operator improved gross profit from 65% to 72% within 12 weeks on approximately £500,000 in revenue. Populu lifted GP from 68% to 72% across 16 locations. Amber restaurant saves £3,000–£4,000 per month, with Chef-Owner Murat Kilic stating: “Jelly keeps my business alive.”
Frequently Asked Questions
How Do You Automate Invoice Processing in SAP?
Automating invoice processing in SAP for a multi-site restaurant group follows a seven-step sequence:
- Step 1 defines the site hierarchy and maps company codes, profit centres and cost centres so every invoice posts to the correct management unit.
- Step 2 cleans and governs the vendor master, resolving duplicates, validating bank details and enforcing mandatory field completion at entry.
- Step 3 documents approval thresholds and delegation of authority by site, brand and spend level.
- Step 4 sets up a central intake channel per site, such as a dedicated email address or photo capture workflow, so invoices arrive in a structured, traceable way.
- Step 5 applies AI OCR and line-item extraction to capture quantity, SKU, price and tax at line level, not just invoice header level.
- Step 6 configures three-way matching with category-appropriate tolerances, distinguishing fresh produce from frozen goods and catch-weight items from standard quantity goods.
- Step 7 routes exceptions to the right owner, such as price variances to the buyer and quantity variances to the site, then posts matched invoices to SAP.
What Is Three-Way Matching in Restaurant AP?
Three-way matching compares three independently generated documents before releasing an invoice for payment: the purchase order, the goods receipt and the supplier invoice. In a restaurant context, a practical example is a purchase order for 100kg of chicken at an agreed rate, a delivery note confirming receipt at the site and an invoice from the supplier showing a price increase. The three documents are compared during invoice verification. The price variance is flagged before posting rather than paid automatically, and the exception is routed to the buyer who negotiated the original price. If both quantity and price checks pass within configured tolerance, the invoice posts and is scheduled for payment. If either fails, the invoice is blocked until the exception is resolved.
What Is the Six-Year Invoice Rule for UK Restaurants?
HMRC requires VAT-registered businesses to retain VAT records and supporting documents for six years. The records in scope include sales and purchase invoices, credit notes, VAT returns and the VAT account. Digital copies are acceptable provided they are clear, accurate and legible. Limited companies keep records for six years from the end of the last financial year they relate to. Longer retention is required if transactions span multiple accounting periods, if a Company Tax Return was filed late or if HMRC opens a compliance check. HMRC can audit records going back up to six years for careless errors, and up to 20 years if fraud or deliberate tax avoidance is suspected. Under Making Tax Digital, paper records alone are insufficient, because records must be kept in functional compatible software and data transfers between systems must use a digital link.
How Do You Code Invoices to Multiple Cost Centres in SAP?
The coding logic follows the three-level hierarchy: the company code is the legal entity, the profit centre is the site or brand and the cost centre is the site function such as kitchen, bar or front-of-house. A single invoice from a supplier who serves more than one site can be split across cost centres at line-item level, with each line coded to the relevant site function. Each cost centre rolls into its assigned profit centre automatically, so every split posting flows into the correct site-level P&L for management reporting. The GL account classifies the nature of the spend, such as food cost of sales, beverage cost or utilities, and is determined from the vendor pattern and the line-item description during automated capture. Accurate cost centre coding at invoice level forms the foundation of site-level margin visibility.
What Is a KPI for Invoice Processing?
The most commonly tracked KPIs for invoice processing in a multi-site restaurant context are:
- Touchless processing rate: the percentage of invoices that move from receipt to posting with no manual intervention, which measures how much of the AP process runs without human touch.
- Exception rate: the percentage of invoices that fail matching and require manual resolution, which indicates the quality of tolerance configuration and supplier data.
- First-pass yield: the percentage of invoices that pass matching on the first attempt, without rework or resubmission.
- Cycle time: the average time from invoice receipt to final approval and posting, which affects cash flow visibility and supplier payment timing.
- Cost per invoice: the total AP processing cost divided by invoice volume, which captures the efficiency of the end-to-end process including exception handling time.
- Duplicate payment rate: the percentage of spend affected by duplicate payments, which reflects the quality of vendor master governance and duplicate detection controls.
How Do You Handle Non-PO Invoices in a Multi-Site Restaurant SAP Setup?
Non-PO invoices such as rent, utilities, marketing, repairs and professional fees cannot be three-way matched because no purchase order or goods receipt exists to compare against. They follow a different processing path. AI-suggested GL coding uses vendor patterns and historical postings, and the system learns from corrections over time to improve accuracy. Approval routing follows spend thresholds and site, using the same delegation of authority model as PO-backed invoices. The key risk with non-PO invoices is incorrect GL coding, which distorts site-level cost reporting. Mandatory review by a named approver at each site, combined with vendor-pattern learning, reduces coding errors without requiring manual coding of every line.
How Does Jelly Fit Alongside SAP for a Multi-Site Restaurant Group?
Jelly complements SAP rather than replacing it. SAP handles the financial system of record, including the general ledger, accounts payable and management reporting. Jelly handles the operational layer that SAP-native tools do not address: automated invoice capture via photo or email, line-item digitisation at quantity, SKU, price and tax level, real-time price alerts when a supplier changes a price and live dish costing that updates every time a new invoice arrives. Jelly integrates with accounting tools such as Xero, pushing digitised invoices directly and reducing bookkeeping time by 90%. It integrates with POS systems to deliver real-time sales mix and gross profit margin data by dish. Jelly onboards and generates initial value in the first week and charges £129 per month per location, giving multi-site groups a fast route to accurate, site-level invoice data that feeds real-time menu profitability.
Conclusion: Fix the Foundations, Then Automate
SAP invoice processing automation is an operational priority for any UK multi-site restaurant, pub or boutique hotel group running on SAP Business One or S/4HANA. The technology to automate capture, matching and approval is mature. Most implementations underdeliver because the organisational foundations were not in place before automation was switched on.
Fix the site hierarchy first. Map every site to a company code, profit centre and cost centre. Clean the vendor master. Document approval thresholds. Then automate intake, coding, matching and posting. The sequence matters because every downstream process depends on the accuracy of the data upstream.
For multi-site groups that want a fast route to accurate, site-level invoice data and real-time menu profitability, Jelly provides a focused operational layer. It handles invoice capture, price alerts, dish costing and POS integration that SAP-native tools leave to manual processes, and it generates value in the first week rather than after months of BTP configuration.
Book a demo with Jelly to explore your SAP invoice automation roadmap.