Hong Kong Restaurant Three-Way Match: PO, Delivery Note, Invoice

Hong Kong's restaurant sector buys a lot of food and drink. The Census and Statistics Department puts HK$8.8 billion in restaurant sector purchases in Q2 2025 — a 2.7% increase on the same quarter the year before — and that volume runs through tens of thousands of supplier deliveries every week. On a flow that size, even a single-digit-percentage rate of supplier billing leakage represents real money quietly draining out of P&Ls that nobody is reconciling. A Hong Kong restaurant three-way match compares the purchase order, the delivery note signed at the kitchen, and the supplier invoice line by line before payment is released. The chains that take procurement discipline seriously catch the leakage. Most don't, because catching it requires the workflow nobody is doing in their head: matching all three documents, line by line, every week.

In HK F&B that means comparing the purchase order (採購單), the delivery note (送貨單) or goods received note signed at the kitchen, and the supplier invoice (供應商發票) before payment is released. The discipline catches four classes of error that no single document on its own can prove: short deliveries (短送) where the driver leaves fewer boxes than the invoice charges for; unauthorised price increases (加價) where the supplier raises a unit price without notice; substitutions where the kitchen accepts a different SKU at the door but the invoice charges the original price (or worse, a higher one); and missing credit notes (貸項通知單) the supplier promised verbally for a short-delivery and never actually issued. Any one of the three documents on its own is just a story. The three of them together are the truth.

How a chain runs the match in practice depends on supplier discipline. Some operations match only the supplier's invoice header total against the sum of POs for the period — fast, but blind to anything that nets to zero across lines. Others match line-by-line on supplier item code where the codes are reliable, and fall back to fuzzy matching on item descriptions where they aren't. The mode mix follows the supplier mix, and the article walks each option in turn.

The HK F&B procurement document chain is messier than the textbook ERP version that generic AP-automation content describes. POs go out as formal PDFs to international foodservice suppliers like Angliss and DCH, as WhatsApp messages to the produce sales rep, and as phone calls to the bakery. Delivery notes come back Chinese-script-signed at the kitchen door, sometimes bilingual on the head-office copy, and sometimes handwritten Chinese-only from a wet-market supplier. Invoices arrive weekly or fortnightly aggregating a dozen deliveries across half-a-dozen outlets in formats that vary by supplier. The matching workflow has to be designed for that environment, not imported wholesale from a NetSuite training video.

The same logic applies whether the operation is a thirty-outlet chain, a hotel F&B kitchen, or an independent cafe with one supplier delivery a day. Scale changes the volume of documents and the consequences of getting it wrong, not the workflow. A cafe owner catching a HK$200 short-delivery a week recovers a meaningful fraction of their food cost; a chain procurement manager catching the same proportion across thirty outlets recovers six figures a year. The discipline is identical.

For staff who work primarily in Chinese, there is also a Cantonese-language guide to the same restaurant procurement reconciliation workflow on this site, treating the same ground for kitchen and bookkeeping staff who think about these documents in Cantonese. This article walks the workflow in English, for the procurement, AP, and finance staff at HK F&B chains and hotel F&B kitchens who own the matching discipline at head office.

The Hong Kong F&B procurement document chain

The chain starts with the purchase order. In HK F&B that runs across a wide spectrum and pretending otherwise leads to a workflow that doesn't survive contact with the kitchen. A formal PDF PO sent by email to the supplier's order desk is typical for international foodservice suppliers — Angliss, DCH, Foodgears, Wismettac, the larger HK-headquartered distributors — where the supplier's order team is set up to acknowledge and process structured POs. A WhatsApp message from the chef or outlet manager to the sales rep ("send me 5 boxes of Australian beef tenderloin Wednesday morning, plus the usual produce") is the daily reality for most produce, dairy, bakery, and fresh-protein orders, especially at single-outlet operations and small chains. A phone call to the sales rep with no written confirmation back still happens at the wet-market end of the supplier base. A clean PO carries the supplier name and account, the requested delivery date and outlet, the item code, the item description, the quantity in the unit of measure (UoM, 計量單位) the supplier prices in, the agreed unit price and line total, and the staff member raising the order. Most HK F&B POs in the wild carry some subset of those fields and skip the rest.

The supplier delivers, and the driver leaves a delivery note (送貨單) at the outlet door. Receiving staff or the kitchen manager checks the boxes against the delivery note, signs the kitchen copy, and the driver takes the head-office copy back. That is the sequence in theory. In service-time practice the kitchen manager is mid-prep, signs without counting the cases properly, and discovers the discrepancy later when the cold room inventory doesn't add up. The delivery note is often Chinese-script-signed at the kitchen door even when the head-office copy is bilingual or English-primary; some wet-market and small-supplier delivery notes are handwritten Chinese-only. The fields a delivery note carries — supplier name, delivery date, item code, item description, quantity actually delivered, UoM, kitchen signature — are the ground truth on what physically arrived, and the kitchen-door annotation when receiving spots a problem (count discrepancy noted in pen, damaged stock refused, substitution flagged) is what gives AP a fighting chance to dispute the invoice later. A delivery note signed cleanly is treated as receipt agreed; a delivery note annotated by the kitchen is the start of a credit conversation.

The supplier invoice (供應商發票) arrives later — usually weekly, sometimes fortnightly, occasionally monthly — and aggregates multiple deliveries across the period into a single document that head-office AP receives. Format depends on the supplier. International foodservice suppliers issue English-primary or bilingual invoices on structured templates with item codes and consistent layouts. HK-headquartered distributors usually issue bilingual. Local fresh-produce suppliers and wet-market vendors often issue Chinese-primary invoices, sometimes handwritten. The supplier invoice carries the supplier name and BR Number (BRN, 商業登記號碼), the invoice number, the invoice period or list of delivery dates covered, the line items with item code, item description, quantity invoiced, unit price, line total, and the period total with payment terms. The invoice is the document AP sees first, and without a matching discipline the invoice is also the document AP pays — taking the supplier's word for what was ordered and what was delivered.

That is where the chain hands off. AP at head office matches the supplier invoice against the corresponding POs and signed delivery notes for the period covered, and the work the rest of this article walks through is the work that happens in that match. The same set of supplier documents — the PO that authorised the order, the delivery note that recorded what arrived at the kitchen, and the invoice that asks for payment — is also what HK F&B operations are obliged to keep as part of FEHD food traceability records that ride on the same supplier documents. Running the matching discipline well means the food-safety record-keeping discipline gets done at the same time, on the same files.

Five divergence patterns — short delivery, over-delivery, price variance, substitution, packaging UoM mismatch

The three documents tell the truth together; any one of them alone is just a story. The truth, when the documents agree, is unremarkable. When they diverge, the divergence usually takes one of five shapes. Naming the shapes is what turns "this delivery doesn't reconcile" from a single ad-hoc exception into a diagnosable workflow.

Short delivery (短送). The PO ordered 5 boxes of Australian beef tenderloin; the delivery note shows 4 boxes (the driver short-delivered, often because the supplier ran short on the morning's pick); the invoice charges for 5 boxes. The supplier owes a credit. This is the single largest source of leakage when receiving discipline is loose, because the discrepancy is invisible without a line-by-line match — the kitchen swallowed the missing case the moment the kitchen manager signed the delivery note without counting, and head-office AP has no way to reconstruct the count after the fact. A chain that catches short deliveries reliably can recover meaningful supplier credits every month.

Over-delivery. The PO ordered 5 boxes; the delivery note shows 6 boxes; the invoice charges for 6. The outlet has stock it did not order, working capital is tied up in inventory that wasn't planned for, and where perishables are involved (dairy, fish, fresh protein) the waste risk rises sharply. Some chains return the surplus on the next driver visit; others accept it and credit internally to the outlet that took it. Either way the matching layer needs to surface the event, because over-deliveries that go unflagged become silent additions to inventory that distort theoretical-vs-actual food cost reporting downstream.

Price variance (加價). The PO went out at HK$120/kg; the delivery note shows HK$120/kg or no price at all; the invoice charges HK$135/kg. The supplier raised the price without notice. This pattern is common with international foodservice suppliers when a contracted price list lapses and the new rate kicks in without a renegotiation conversation, with produce when the wet-market reference price moves and the supplier passes the increase through, and with imported items when foreign-exchange or freight surcharges land on the invoice without warning. Price variance is the second-largest leakage category after short delivery in most HK F&B operations, and it compounds quickly because it applies across every line item the supplier provides until someone catches it.

Substitution with price impact. The PO ordered Angus tenderloin; the delivery note shows Wagyu (the supplier ran out of Angus that morning and the driver brought Wagyu instead); the invoice charges Wagyu price. The kitchen accepted the substitution at the door, often correctly — service was about to start and a different cut beat no protein at all — but no one priced the change. Even where the substitution is benign in service terms, the matching layer needs to surface it so the chain decides whether to absorb the price difference, return the substituted item on the next visit, or call the supplier to renegotiate. The pattern also runs in the other direction: the kitchen takes a cheaper substitute and the invoice still charges the higher original price, which is recoverable as a credit if the substitution is documented.

Packaging UoM mismatch. The PO ordered 50 single-unit cases; the delivery note shows 25 double-unit cases (the supplier's warehouse repacked); the invoice prices in single-unit cases. Total quantity of product is identical — 50 single units are 25 double units — but an AP clerk reading the documents on different lines reads them as a discrepancy, or the matching layer flags a false positive on a quantity mismatch that is really a UoM mismatch. The same pattern shows up in reverse when the invoice prices in kilograms and the delivery note quantifies in cases without a kg conversion. UoM (計量單位) normalisation has to be a core matching primitive — kept as a lookup against the item master that knows how many single units are in a case, how many kilograms are in a standard fish box — rather than an afterthought, because UoM-driven false positives erode trust in the matching report faster than any other class of noise.

A real delivery rarely shows one pattern cleanly. A weekly invoice from a mid-size foodservice supplier might show short-delivery on one line, price variance on three, a substitution on a fourth, and clean matches on the rest. Naming each pattern individually is what lets the matching layer report them as distinct findings — credit owed for the short, dispute opened on the price variance, decision needed on the substitution — rather than a single undifferentiated "this invoice has exceptions" message that nobody knows how to action.

Cross-language matching — Cantonese at the dock, English at head office

The PO line that reads "Australian beef tenderloin" at head office is the same kitchen line that reads "澳洲牛柳" on the Chinese-script-signed delivery note and the same invoice line that reads "Australian beef tenderloin / 澳洲牛柳" on the bilingual supplier invoice that comes in a week later. Three documents, one item, three surface forms — and a matching layer that has to recognise them as one logical line before any quantity, UoM, or price comparison can run.

That cross-script alignment is the working environment most HK F&B chains operate in every week, not a translation footnote. International foodservice suppliers (Angliss, DCH, Foodgears, Wismettac) issue English-primary or bilingual invoices on structured templates. HK-headquartered distributors usually issue bilingual. Local fresh-produce suppliers and wet-market vendors often issue Chinese-primary invoices, and a meaningful share of those are handwritten Chinese-only on a carbon-copy book the driver fills in at the back of the truck. The PO is usually English at head office, because head office runs in English and the procurement system is set up that way. The kitchen-signed delivery note is usually Chinese-script at the kitchen door, because kitchen staff read and sign in Chinese — even when the head-office copy of the same delivery note is English-primary or bilingual. None of this is a problem to fix; it is the document environment to design the matching layer around.

What the matching layer has to do operationally is normalise the three item descriptions to a single canonical line, so the quantity, UoM, and price comparisons can run against a stable identity. Two routes do that work. Where supplier item codes (貨號) are reliable across the three documents, item-code matching does the heavy lifting and the description language barely matters — the codes are language-neutral, and the descriptions are decoration. Where the codes are not reliable, or do not exist, description-level fuzzy matching across English and Chinese is the only route that closes the loop. That is the harder route, and it is where AI extraction earns its place over rule-based parsing: AI extraction can read both scripts, recognise that "澳洲牛柳", "Australian beef tenderloin", and "Aust beef tenderloin (澳洲)" are the same kitchen line item, and align them on the same row of a structured dataset without a hand-built translation table.

The operational consequence for a chain is straightforward. Building an item master keyed by supplier item code where available, and by canonical description (with both English and Chinese forms) where not, is what makes the matching workflow runnable weekly rather than only at month-end. It is also the layer that makes onboarding new suppliers manageable — a new wet-market vendor with handwritten Chinese-only delivery notes can be added to the matching workflow as soon as their delivery notes are extracted into the same structured shape as everything else, with their items mapped onto the existing item master. The bilingual document handling is a layer of the same problem as bilingual invoice extraction generally; the toolchain that can extract bilingual Hong Kong invoices into structured Excel rows is the toolchain that can extract the matching delivery notes and POs into the same structured shape.

Three match modes — header-only, line-by-item-code, line-by-description

A chain choosing how to run the match is choosing how strict the matching layer is. The three modes below are the realistic options, and the choice is governed by the supplier mix more than by ambition. Most HK F&B operations end up running a layered combination rather than picking one.

Header-only match. The supplier's invoice total for the period equals the sum of PO totals or signed delivery note totals for the same period. Within a tolerance — usually 1–2% to absorb rounding and FX noise — the invoice passes; outside the tolerance it gets queued for review. The mode is fast, mechanically simple, and catches the loud failures: an entire missing invoice that the supplier never sent, a duplicated invoice the chain might pay twice, a delivery that was charged at quadruple the agreed rate. It catches none of the quiet failures. A short-delivery on one line that nets against an over-delivery on another, or a price variance on three lines that's offset by a credit applied to a fourth, vanishes inside the header total. Header-only is the lazy default many HK F&B chains run by inertia, and it is best understood as a triage layer — the first pass that filters out the worst surprises — rather than a substitute for line matching. A chain running only header-only matching is, in practice, running no real matching discipline at all.

Line-by-item-code match. Supplier item code on the PO equals supplier item code on the delivery note equals supplier item code on the invoice. Tightest match, fastest to run programmatically, and mechanically clean when it works. The catch is supplier discipline. Many HK suppliers use inconsistent item codes between their internal systems and the documents they actually issue to customers — the warehouse system codes the case, the sales system codes the SKU, and the invoice prints whichever the operator's screen showed that morning. Item codes drift when products are reformulated, repackaged, or rebranded, with no notice to the customer. Smaller suppliers may not assign codes at all. The mode works as well as the worst-disciplined supplier in the mix, and a chain whose supplier base mixes one or two well-coded international foodservice suppliers with four or five locally-coded distributors and a handful of code-less wet-market vendors cannot rely on item-code matching alone. Where the codes are good, item-code matching is the right primary mode; where they aren't, it produces noisy false negatives that the AP team learns to ignore — at which point the matching report stops being trusted.

Line-by-description match. Fuzzy match item descriptions across the three documents against a canonical item master that holds both English and Chinese forms of each line. Looser than item-code matching by definition, but immune to supplier code drift, and the only mode that works on Chinese-only handwritten delivery notes paired with English-primary invoices. Description matching is the pragmatic mode for a HK F&B mixed supplier base, and it is the mode AI extraction unlocks at scale because a model that reads both scripts and normalises across surface variation can do in seconds what a hand-built rules engine would take a quarter to maintain. The trade-off is that fuzzy matching produces a confidence score rather than a binary match, and a low-confidence match has to drop into a review queue rather than auto-passing — but a chain that handles the review queue weekly recovers far more than the queue costs to run.

The practical answer for most HK F&B chains is a layered combination. Header-only runs as a fast triage at the gross-total level. Item-code matching runs against the suppliers whose codes are reliable. Description matching runs as the fallback that catches what the other two miss — and in a HK F&B mixed supplier base it ends up catching most of the line-level work, because most of the line-level errors live with the suppliers whose codes aren't tight. The mode mix should follow the supplier mix, and the mix is worth re-examining as the supplier base evolves.

---

The credit-note tracker — recovering what the supplier promised verbally

When the kitchen catches a short-delivery at the door, the driver almost always promises a credit will appear on the next invoice. Sometimes the kitchen manager annotates the delivery note in pen — "short 1 case, driver to credit" — and signs the kitchen copy. More often the promise is verbal, made over the noise of an active service, in Cantonese, and not written down anywhere. "我哋下次落single到" — we'll credit you on the next one — is the line every HK F&B kitchen has heard. Without a tracker on the chain's side, that promise has no record. The credit either never lands on a subsequent invoice, or it lands as an undetailed adjustment line that nobody reconciles back to the specific delivery that was short. The chain absorbs the loss either way.

The matched-variance dataset that the three-way match produces is the natural input to a promised-credit register. Every variance the matching layer surfaces — short-delivery, over-delivery, price variance, substitution, missing item — generates a row in the register: supplier name, delivery date, invoice number where the variance was detected, item, quantity owed or amount owed in HKD, the kitchen sign-off where the discrepancy was annotated (or a flag if it wasn't), the driver name where it was captured, and a status field that starts at "open" and moves through "credit promised", "credit received", "written off", or "disputed". A structured spreadsheet is enough for the register itself; the value is in keeping it current and acted on.

The ageing discipline is what turns the register into recovered cash. AP runs the open list weekly. Open credits older than 14 days get a chase email to the supplier sales rep with the originating delivery note attached as evidence. Open credits older than 30 days escalate to procurement, who carry the conversation as part of the supplier relationship rather than as a one-off complaint. Credits older than 60 days get written off with a note in the register, because chasing past that point usually costs more than it recovers — but the write-off is recorded, which means at the next supplier review the procurement manager has the data on which suppliers honour their promises and which don't. The matching layer feeds the register and the chasing is human work; the discipline lives in running the cycle weekly rather than in the tooling.

Closing the loop matters as much as opening it. When a credit note (貸項通知單) finally arrives from the supplier, AP matches it back to the originating delivery in the register before applying it. Two things fall out of that step. First, the same credit cannot be claimed twice — once against the open register row, and again as an unmatched credit applied to a later invoice — which is a real risk when the supplier issues credit notes weeks after the originating delivery and the AP team rotates. Second, the chain accumulates a record over time of which suppliers honour their verbal promises, how long they typically take to issue the credit, and how much of what was promised actually arrives. That record is a quiet but powerful data asset for procurement: supplier reliability stops being a vibe held by the procurement manager and becomes a roll-up that survives staff turnover.

Small chains often try to track promised credits informally — in a WhatsApp group between the kitchen and AP, or in an email chain that drifts off the bottom of the inbox after a week. Both fail at scale, and they fail in the same way: the promise is captured but not actioned, and the credits that don't arrive don't get chased. The fix is one place, fed automatically from the matched-variance dataset, that AP looks at every week.

Supplier-statement reconciliation as the month-end safety net

Per-delivery three-way matching and monthly supplier-statement reconciliation operate at different altitudes, and a HK F&B chain serious about supplier accuracy needs both. The three-way match works per delivery and catches line-level errors as they happen — short-delivery, price variance, substitution, missing credit. Supplier-statement reconciliation works per supplier per month and catches aggregate errors that line-level work cannot see — invoices the supplier issued but the chain never received, credit notes the supplier issued but the chain never recorded against the originating delivery, invoices the chain paid twice in error, and paid invoices the supplier statement still shows as open. Each layer catches what the other misses; neither replaces the other.

The workflow at month-end is straightforward in shape. AP receives the supplier's monthly statement (月結單) listing every invoice and credit note the supplier has issued that month with current status (open, paid, partially paid). AP cross-checks the statement against the chain's payable ledger for that supplier. Three categories of finding fall out of the cross-check. An invoice on the statement that's absent from the ledger is a missing invoice — most often misrouted at outlet level (the head-office mailroom never received it), or sitting in the wrong department's queue. The chain has to recover the invoice from the supplier and post it before anyone considers payment. A credit note on the statement that's absent from both the ledger and the promised-credit register is a credit the kitchen never recorded as promised but the supplier issued anyway — often because the supplier's own warehouse spotted the short-delivery on the way out and credited proactively. A paid invoice the statement still shows as open suggests a payment-application error on either side: the chain paid the wrong invoice number, the supplier applied the payment to a different invoice, or the chain genuinely owes the money and thought it had paid.

A chain that already runs per-delivery three-way matching has a substantial head start at the month-end altitude. The matched-and-validated invoice register that the three-way work produces is already keyed by supplier, period, and invoice number. Reconciling that register against the supplier statement is a structured join, not a re-keying exercise from scratch. Chains that move from manual statement reconciliation to a workflow fed by the three-way match dataset typically find that month-end reconciliation collapses from days of work down to hours, which has its own knock-on effect: month-end velocity stops being the constraint that pushes statement reconciliation off the schedule when the calendar tightens.

For staff who run this workflow primarily in Cantonese, the equivalent treatment in Chinese sits in our Cantonese-language month-end supplier statement reconciliation guide. The two pieces are deliberately complementary rather than substitutes: the en-HK treatment here serves the controllers, AP supervisors, and outsourced bookkeeping firms whose working language is English; the zh-HK piece serves the same workflow for Cantonese-working staff. A chain whose finance team mixes both should expect both pieces to be useful to different team members.

---

Tooling routes — Excel, restaurant procurement software, AI extraction of all three documents

A HK F&B operation deciding how to actually run the three-way match has three realistic routes, and each has a different point at which it stops scaling. Pick the route that fits the operation's current size and supplier discipline, and expect to migrate as the chain grows.

Manual reconciliation in Excel. An AP clerk opens a workbook with three tabs — POs for the period, signed delivery notes, supplier invoices — and pivots, sorts, and matches by hand. Sustainable up to about five outlets and a small supplier list, particularly where most of the matching is happening with two or three large suppliers whose documents follow consistent layouts. Cheap to set up and well-understood by anyone with intermediate Excel; the tooling is already on every laptop. Where it caps out is volume. A weekly invoice run from a five-outlet chain with twelve suppliers represents hundreds of line items to compare against POs and signed delivery notes, and the per-delivery work becomes too slow to finish inside a working week. At that point the matching workflow either gets compressed to header-only checks (and stops catching most of the leakage) or gets pushed to month-end (and stops catching anything in time to dispute it). Many independent operators and small chains run this mode well, and they should. They should also know it has a ceiling.

Cafe-scale and single-outlet operators are the cleanest fit for the Excel route. A Hong Kong cafe procurement three-way match workflow at one delivery a day from three or four suppliers fits comfortably in a weekly Excel session that the owner-operator runs alongside their other admin. The matching discipline still pays for itself — short deliveries and price variance hurt a cafe's food cost percentage proportionally more than they hurt a chain's, because the cafe's margin against rent is tighter and there is less room to absorb leakage. The workflow shape is identical to a chain's; what changes is who runs it. At cafe scale the chef-owner often does the matching themselves, with the kitchen-signed delivery notes and supplier invoices both passing through their hands in the same week.

Restaurant-procurement software with built-in matching. The category is well-populated. Food Market Hub serves the Asia-region restaurant procurement space, including HK; Marketman, MarketBoy, and Crunchtime are widely deployed across the region; US-shaped equivalents like Restaurant365, MarginEdge, and Plate IQ have their own customer bases. Each has genuine strengths: PO discipline against a structured supplier catalogue, inventory tracking, and built-in matching against the suppliers whose catalogues are loaded into the platform. Where they typically stop is the supplier-side document. A chain running one of these platforms still receives invoices as PDFs, scanned images, or printed copies from suppliers that fall outside the platform's catalogue — local distributors, wet-market vendors, irregular suppliers — and from those suppliers the matching workflow stalls at the document boundary. The procurement platform knows what was ordered; it doesn't know what the supplier's invoice actually says, because the supplier's invoice arrived as a PDF the platform doesn't ingest. A chain whose entire supplier base sits inside a procurement platform's catalogue can run end-to-end matching inside the platform; very few HK F&B chains have that supplier mix.

AI extraction of all three documents into structured form. This is where we sit. The route is straightforward in shape: extract the PO into a structured row set (whether it arrived as a formal PDF, a WhatsApp screenshot, or a forwarded email); extract the delivery note into a structured row set (PDF, image, English, Chinese, or bilingual, including kitchen-signed copies photographed at the outlet); extract the supplier invoice into a structured row set (any format any supplier issues). Three datasets out of one platform, with the same data shape, ready to reconcile against each other in whatever environment the chain's reporting already lives — a spreadsheet, the chain's accounting tool (Xero, QBO, MYOB), or a BI layer. The AI extraction route is what makes per-delivery matching cheap enough to do every week instead of every month-end, because the bottleneck stops being document handling and starts being the matching logic itself, which is the part the chain wants to spend cycles on. The practical workflow every section above assumes is the ability to extract POs, delivery notes, and supplier invoices into structured spreadsheets in a single pass, with one platform handling the document layer across all three document types and across English, Chinese, and bilingual supplier documents — leaving the matching, the variance register, and the supplier-statement reconciliation as work the chain runs against clean structured data rather than against PDFs.

In practice the route works the way most prompt-driven workflows work on the platform: the user uploads the documents (any mix of PDF and image, in any of the three document types), describes what they need with a goal-oriented prompt — the example "I'm reconciling supplier invoices against purchase orders and delivery notes" is a real prompt the system handles directly — and downloads structured Excel, CSV, or JSON output ready to reconcile. The same low-quality scan handling that lets the platform read mobile-phone photos of kitchen-signed delivery notes is what lets the matching workflow include the documents that actually get signed at the kitchen door, rather than only the clean head-office copies. Saved prompts handle the recurring weekly run, so once the prompt for a chain's supplier mix is dialled in, the same prompt drives the same structured output every week.

What AI extraction does not do is fix supplier-side document discipline, and being honest about that is the only credible way to talk about the route. If a supplier issues handwritten delivery notes in Chinese with no item codes, the extraction layer reads them and structures them — it does not retroactively assign codes the supplier never put on the document, and it does not cause the supplier to start using codes. If the PO chain is informal because procurement runs over WhatsApp, the extraction can structure a screenshot of the WhatsApp thread, but it cannot make the supplier's order desk acknowledge receipt of the order. The value the AI extraction route delivers is making the chain's side rigorous: every document that comes in gets structured, every variance gets surfaced, every dispute is documented with the underlying records attached. The supplier-side discipline is still a relationship the procurement manager has to manage. That honesty is the article's position, not a caveat tacked on at the end — a matching workflow that pretends supplier discipline is solved is a matching workflow that breaks the first time a wet-market supplier shows up.

After the match — outlet allocation, USALI coding, and Section 51C retention

A chain with the matching discipline running well already has the structured datasets it needs for everything downstream of validation. Per-delivery line-by-line matching catches errors as they happen, the matched-variance dataset feeds a promised-credit register that ages and chases, the same dataset reconciles to the supplier statement at month-end, and the structured record set drives whatever cost-coding the operating model requires while quietly satisfying retention obligations along the way. Two short signposts on where the validated invoice goes from here, depending on the operating model.

For a multi-outlet chain operator, the validated invoice gets coded back to the outlet that consumed the inventory — outlet-level cost-of-goods-sold reporting, recipe costing, and outlet P&L all depend on the allocation. The matched line items already carry the outlet destination from the originating PO, the validated quantities and prices from the matching pass, and the variance flags from the credit register, so the downstream step to code each validated invoice to the outlet that consumed it rides on the same structured datasets. A chain doing matching without allocation is leaving outlet-level visibility on the table; a chain doing allocation without matching is allocating leaky data to outlet P&Ls.

For a hotel F&B kitchen, the receiving and matching workflow at the kitchen door is identical to a chain restaurant's, but the cost coding downstream is shaped by the hotel's reporting framework rather than by outlets. Hotels and serviced apartments running F&B in-house apply USALI department coding for hotel F&B supplier invoices to the validated invoice, splitting the cost across banquet, all-day-dining, in-room dining, minibar, and employee canteen so the F&B departmental P&Ls roll up cleanly into the property's USALI reporting. A Hong Kong hotel F&B kitchen receiving invoice match works on identical primitives to a chain restaurant's, with the USALI layer added on top.

Whichever shape the operation takes, the matched-and-validated documents are themselves the records HK F&B operators are obliged to keep for seven years — the PO, the kitchen-signed delivery note (or the photograph of it), the supplier invoice, the credit notes, and the variance trail are all supporting documentation behind the AP postings, and the IRD Section 51C seven-year retention for the matched documents is the rule that governs them. The structured datasets the matching workflow produces are, by construction, the searchable record set the chain needs if a Section 51C request ever lands. A chain that has built the matching discipline has built most of the retention discipline along with it.