Restaurant report examples by market: read the basis before comparing the totals

What these report examples represent

A familiar report name does not establish a familiar meaning. Sales, payment details, settlement and invoice can describe different populations in different markets or provider versions. This guide provides original fictional worksheets for India, the United States and Canada, the United Kingdom, Australia, New Zealand, Ireland, Singapore and the United Arab Emirates. They teach questions to ask of an actual report, rather than reproduce a portal that we have not accessed.

Every sample amount, business identifier and worksheet label below was invented. None is a native merchant export, a screenshot, a fee quotation or evidence of authenticated account access. Currency codes identify separate examples; they do not convert money. The common teaching basis excludes tax and tips from every monetary field. That lets the arithmetic stay understandable without pretending to establish the applicable tax treatment for an actual restaurant.

Each sample starts with defined sales before the separately listed model refunds and funded promotions. Fees, promotions and refunds are positive deductions; the adjustment is a positive addition. Actual reports may use signed values or already-net starting amounts. Check their definitions before applying any formula. Subtracting a refund that is already included in a net figure would count its effect twice.

The main exporter and settlement analyser retain their documented Zomato and Swiggy support boundaries. These overseas worksheets do not add overseas importers or account integrations. Use unsupported reports in a clearly mapped manual worksheet, keeping native headers intact and private source records under appropriate business access controls.

Annotate a real report before calculating

Record provider, market, outlet scope, report name, generation date, selected period, currency, grain and date basis. Explain whether one row represents an item, an order, an adjustment or a payout. Keep the exact source label beside your interpretation. The report dictionary explains the terms, but the provider's current definition controls what its particular field means.

Add a statement of coverage. Does the authorised account include all the selected locations? Does the report contain completed activity only, or several statuses? Were any modules unavailable? A generated archive or available download button is not proof that the business population is complete. Keep limitations attached to the affected calculation rather than hiding them in a general note nobody reads.

Separate activity date, payment date, payout initiation date and bank posting date. An order near a period boundary can appear in different views without an error. Keep opening and closing amounts due when matching period activity to period cash. A correct payout calculation does not by itself prove the bank receipt, and a bank receipt does not explain every underlying sale or deduction.

Use an annotation sheet rather than editing the source into a preferred format. For every mapped field, record the source, unit, sign rule and unresolved question. If a provider changes a label, preserve the old mapping with its effective period. A comparison is useful when the definitions remain explainable, not merely when every column has a short tidy name.

India: distinguish exported item detail from order finance

Start with the implemented module, not the platform name alone. Our field reference distinguishes recovered Zomato item lines from Swiggy order-level finance. Item lines can support quantities when the relevant detail is available and complete. Swiggy finance responses used by this version do not supply a dish, variant and add-on sales list. Money values cannot reliably manufacture that missing product detail.

For a fictional INR worksheet, defined starting sales are INR 100,000, total selected fees INR 25,000 and a supported model adjustment INR 500. There is no separate funded promotion or refund in this particular exercise. Expected net entitlement is INR 75,500. The adjustment is an invented assumed addition, not a claim that a real merchant receives a credit of this size or category.

The useful question is which source establishes each amount. A supported order-finance table can describe returned customer-paid or payout amounts under its fields. It is not a complete restaurant income statement and not proof of bank receipt. A settlement summary and its breakdown should not both be counted as independent payout money. Inspect the index and diagnostics to establish what was actually retrieved.

Keep a current menu snapshot separate from sales history. The menu might show today's products or opening information, while an order dataset describes selected activity. Applying today's price to all historical quantities can misstate sales. A similarly named item can also have a different variant or portion. Retain the supported identifiers and original detail rather than replacing evidence with a neat but unsupported reconstruction.

Zomato's public daily-payout announcement is historical context, not proof of a current universal entitlement, fee or arrival schedule. Use the actual account and agreement for those questions. For the fictional INR 75,500 entitlement, matching cash would still require appropriate references and bank evidence. If an amount remains due, carry the supported balance rather than deciding that a difference automatically means a provider error.

United States: distinguish order activity from payout initiation

Uber's public payment-detail reference has an explicitly United States glossary as well as a separate Canadian section. It distinguishes order-related information, fee components, payout references and payout initiation. Its broader Reports Tab explanation distinguishes payment details from payment summary purposes. These references support a source-aware review; they are not evidence that every American merchant account has identical controls or every restaurant uses the same tax treatment.

Our original USD worksheet starts with USD 10,000 defined sales, before the separately stated USD 200 model refund. Selected fees are USD 2,000 and an assumed confirmed adjustment adds USD 50. There is no separate promotion deduction. The expected amount is USD 7,850. Tax and tips are excluded throughout the worksheet, so no marketplace-tax calculation or remittance conclusion is hidden in that amount.

Suppose a reviewer sees the original order date beside a refund-related row. They should check the report definition and other event dates rather than assume the refund happened on the original sale date. The financial question might concern current payout activity, while the operational question concerns the service that produced the complaint. Those analyses can legitimately use different date views.

Do not describe a payout initiation field as a guaranteed bank-arrival date. Preserve reference, amount, status and the actual posted receipt. A provider may send a transfer that the bank has not yet posted or has rejected. The bank question requires bank evidence. A pending report field cannot substitute for a received transfer merely because it appears in a financial export.

DoorDash's United States financial guide describes report-building and authorised location scope, but exact account permissions and current interfaces still need confirmation. Use the correct report purpose and retain the selected stores. The fictional USD bridge can be practised manually without claiming that either provider exports our teaching labels. Keep native schemas separate from the worksheet aliases used to explain the calculation.

Canada: keep CAD and the Canadian dictionary distinct

Do not treat the United States and Canada as one interchangeable report schema. Uber's public reference presents country-specific definitions, including Canadian tax-related fields and invoice relationships. The existence of those labels does not determine an individual restaurant's registration, province-specific treatment or recoverability. Preserve the actual source fields and obtain the appropriate local classification rather than inserting a standard tax rate into every row.

The fictional CAD worksheet has CAD 8,000 starting sales, CAD 1,400 selected fees and CAD 200 funded promotions, with a CAD 30 supported model addition. There is no separate refund in this exercise. The result is CAD 6,430 expected entitlement. All amounts are invented on the stated tax-exclusive basis. The CAD 1,400 is an assumed charge amount, not a universal Canadian platform commission.

Ask whether the promotion is outside the selected sales figure. In this worksheet it is explicitly outside and must be subtracted. In a real report, it may already affect the starting amount or appear under a source-specific funding category. Check a known order and the report explanation. A column's position beside fees does not establish whether it is an additional deduction or merely detail explaining an included total.

Keep CAD separate from USD in combined files. A common dollar symbol or a shared provider does not justify adding the amounts without an appropriate conversion policy. Even after conversion, sales bases and component meanings must be compatible. For an actual group reporting question, retain local schedules and document the chosen translation method with the responsible reviewer.

Use invoice links and payout references for their actual purpose. A document link identifies supporting evidence; it does not mean another invoice amount should be added to cash. A payout reference can connect records while remaining private business information. Keep those references in authorised storage and use fictional aliases for public questions. Confirm amount, date, outlet and status as well as the reference before calling a match established.

United Kingdom: separate invoice detail from the Credit Note column

Deliveroo's public invoice explanation distinguishes summary PDF information from detailed CSV information and describes a particular Credit Note column. It states that this column concerns refund commission adjustments and does not itself affect payout. Apply that explanation to the named provider field, not to every document called a credit note anywhere in accounting. An actual local account still needs its current statement and agreement checked.

Our original GBP worksheet uses GBP 6,000 starting sales, GBP 1,200 fees, GBP 300 funded promotions and GBP 100 refunds. A separate confirmed model adjustment adds GBP 50. The expected amount is GBP 4,450. The GBP 50 is an independently assumed payout adjustment for teaching; it is not generated by adding Deliveroo's named Credit Note column.

The main lesson is document-to-money mapping. A summary can show a final amount while detail explains the components. Count the financial effect once, retaining both as evidence. If an invoice documents a fee withheld in settlement, do not automatically enter another bank payment for the same fee. Conversely, identify a genuinely separate invoice balance rather than assuming every document has already been settled.

Track dispute status separately. A submitted request is not an approved adjustment, and an approval still needs to be linked to its statement treatment. Use the actual provider process for a current case rather than importing a deadline from another market or an older article. The new worksheet does not need a universal dispute window to teach that difference between requested, approved and received.

HMRC's self-employed record guidance describes sales, expenses and supporting evidence, with additional unpaid-amount and stock records under traditional accounting. That scope does not automatically establish the method for a company or every restaurant. Just Eat's referenced dynamic invoice page yielded no readable article text in our review, so we do not invent its current columns, report formats, buttons or payout schedule.

Australia: a localised URL is not proof of feature availability

DoorDash's Australian-localised financial article explicitly says that downloading a Payouts summary CSV using its report builder is limited to United States merchants. That is a useful warning about scope: an Australian URL can contain a feature boundary. Do not promise an Australian export simply because the page loads in an Australian locale. Confirm what the actual authorised account and current local guidance provide.

The fictional AUD worksheet starts with AUD 7,000 sales before separately stated reductions. It deducts AUD 1,300 selected fees, AUD 200 funded promotions and AUD 150 refunds, then adds AUD 40 confirmed model adjustment. Expected entitlement is AUD 5,390. These are original worksheet amounts, not a DoorDash export, an Uber statement or a quoted Australian fee schedule.

Australia's useful review question here is report availability and purpose. If the particular payout report is unavailable, identify the evidence the account actually supplies. A manual schedule can use authorised summaries, statements and bank evidence with clear limitations. Do not tell the owner to access an unsupported feature or rename another report into the missing schema.

Uber's Australian academy distinguishes Manager, Menu Maker and Order Manager roles. A tool used to accept live orders does not automatically provide the financial detail needed for a month-end question. Likewise, a menu-editing tool does not establish historical item sales. Start with the task and appropriate evidence rather than assuming every application under one provider has the same report controls.

Keep local employment, tax and accounting questions separate from the payout arithmetic. A defined AUD deduction does not determine which tax treatment applies or whether a cost is recoverable. No hourly wage, commission percentage or statutory deadline is prescribed by this sample. Use the actual official local source when one of those classifications becomes relevant to the business decision.

New Zealand: build an evidence trail without guessing the schema

This example is a generic NZD teaching ledger. It does not claim that we inspected a New Zealand merchant account or verified a current platform export's exact headers. Inland Revenue's public record guidance supports keeping cash and non-cash sales, expenses and bank evidence in usable records. That supports the evidence discipline, not an invented provider interface or file format.

The original NZD worksheet has NZD 5,000 starting sales, NZD 1,000 fees, NZD 100 funded promotions, NZD 50 refunds and a NZD 20 confirmed model addition. The resulting expected entitlement is NZD 3,870. Tax and tips are outside the model. The charge amounts are fictional assumptions, and the worksheet does not assign an actual GST status, filing method or platform contract.

Use the sample to practise source annotations. For every amount, identify which real document would be needed and whether it has been obtained. A sales total needs a defined population; a fee needs actual charge evidence; a refund needs its event link; an adjustment needs status and settlement treatment. A missing source should remain visible as a gap rather than be replaced with a convenient default.

Keep actual date conventions and currencies explicit when combining files. A locally familiar date can be interpreted differently by software configured for another locale. Preserve raw date text and use a checked conversion. A bank-period comparison should retain opening and closing amounts due, because current sales and current receipts need not describe the same activity.

Inland Revenue's record guidance also contains local language, storage and retention conditions. This article does not turn them into one worldwide rule or advise a particular cloud storage arrangement. For actual record compliance, follow the current local guidance for the business. For the teaching calculation, keep a private trace from the assumed NZD inputs to the expected amount and then identify the bank evidence still needed.

Ireland: use EUR linking documents and local scope

Ireland is not a GBP extension of a UK reporting example. Keep EUR, the actual Irish outlet and local business context explicit. Revenue's business record guidance explains linking documents such as receipts, purchases, sales invoices and ledgers, with records showing the accounting process. Those principles support a traceable manual review while leaving the actual tax and accounting classifications to the relevant current guidance.

Our fictional EUR worksheet has EUR 6,500 starting sales, EUR 1,200 selected fees, EUR 200 funded promotions, EUR 100 refunds and EUR 30 confirmed adjustment. Expected entitlement is EUR 5,030. The starting sales are before those separate reductions under the teaching definition. There is no assertion that a particular Irish provider uses those labels or charges those amounts.

The useful question is how documents connect. A sales report can support the activity, an invoice the charge and a bank statement the receipt. Do not add their totals merely because each contains money. Match the same transaction or cost through its evidence. A fee invoice that explains an already-withheld deduction should not automatically create a second cash payment in the worksheet.

Keep restaurant-service and takeaway tax questions outside this arithmetic unless the actual transaction is properly classified. The example's tax-exclusive basis is a teaching convention, not a ruling that every menu item has the same rate or that every tax paid can be recovered. Refer to current Revenue material and appropriate advice for real decisions. A report label cannot decide the legal classification.

Where a platform's common help article is used, retain the local account caveat. A provider description can explain document categories without proving every local button or contract term. No authenticated Irish merchant portal was inspected for this guide. The EUR sample is valuable because its assumptions are visible and its arithmetic is checkable, not because it resembles an unverified portal screen.

Singapore: distinguish Grab report categories from verified columns

Grab's Singapore payment-report page identifies categories including order history, payments, settlements and invoices. The public text supports their broad purposes, but it does not supply enough detail to verify every exact exported column, file format or button sequence. We therefore use original worksheet aliases and avoid presenting an invented screen walkthrough as if it had been tested in a merchant account.

The fictional SGD worksheet starts with SGD 9,000 sales before the model reductions. Selected fees are SGD 1,800, funded promotions SGD 300 and refunds SGD 200. A confirmed model adjustment adds SGD 100. The expected amount is SGD 6,800. These are arbitrary learning amounts on the stated tax-exclusive basis, not Grab's standard fees or a claim about a real Singapore restaurant.

Use the categories to identify the evidence needed. Order history concerns activity; settlement information helps explain entitlement; an invoice supports a charge; bank evidence establishes actual receipt. Their relationships still need checking. Do not treat a payment report's revenue-like amount as final restaurant profit, because ingredients, staffing, occupancy and other relevant costs can remain outside it.

IRAS's record guidance supports retaining invoices, receipts, vouchers and related evidence. Its GST record guide also discusses why bank statements and business records can differ through charges and other movements. Those are scoped official references. They do not make this sample an approved accounting system or determine the restaurant's GST registration and tax treatment.

Keep any service charge and tax handling explicit when working with real records. The sample excludes them to avoid mixing a pricing or tax question into a payout lesson. If a real starting amount includes such components, map them from the actual source rather than automatically removing a guessed percentage. Preserve the private evidence and resolve the applicable treatment before using the result for a filing or contractual claim.

United Arab Emirates: recurring fees need their own category

Deliveroo's UAE help describes a monthly platform fee introduced in February 2026 as an invoice deduction. It does not supply a universal fee amount. A recurring platform charge should not automatically be interpreted as another order-level commission or copied into every transaction row. Read the actual agreement and invoice to establish the amount, period and method of settlement.

The fictional AED worksheet uses AED 30,000 starting sales, AED 6,000 total selected fees, AED 1,000 funded promotions, AED 500 refunds and AED 200 confirmed adjustment. Expected entitlement is AED 22,700. The AED 6,000 is an invented combined fee assumption. It does not quote the monthly charge, a commission rate or any particular platform's standard package.

If a recurring fee is already included in the selected settlement deduction, count it once. Do not add it again merely because a separate invoice is available. Equally, do not assume a separate unpaid invoice is included when the statement does not support that. Link the actual documents and classify the settlement method. The comparison should establish the relationship rather than rely on the word fee in several headings.

The FTA's corporate-tax record reminder concerns relevant transaction, asset and liability records under its stated scope. It is not a universal VAT retention rule for every UAE document. This guide uses it to reinforce the need for supporting evidence while avoiding a single legal checklist for all businesses. Keep actual tax and licensing questions with the appropriate current official sources and qualified advice.

AED entitlement still needs a cash bridge. A statement may describe the amount payable while a bank receipt belongs to another posting period. Keep opening and closing amounts due and actual references. The UAE cash-planning guide explains why expected receipts need dated cash context. No payment deadline or guaranteed arrival is created by the fictional AED calculation here.

Compare examples by question, not by invented fee rate

The samples share a teaching formula so readers can practise signs, but their amounts are not a market comparison. Dividing each invented fee by its sales does not reveal which country or provider is cheaper. No negotiated agreement, service scope, tax base or actual payment mix was used to create those numbers. They are arithmetic inputs chosen to make different evidence questions understandable.

Compare the question each market example highlights. India concerns implemented module boundaries; the United States concerns date and payout meanings; Canada concerns country-specific dictionaries and currency; the United Kingdom concerns document categories; Australia concerns feature scope despite a localised URL. New Zealand and Ireland emphasise source evidence without guessed schemas, Singapore category-level public information and the UAE recurring charges.

For an actual provider comparison, obtain equivalent evidence for the same business scope and period. Identify percentage bases, fixed charges, recurring services, taxes, optional features and contract conditions. Use the restaurant's actual payment or order mix. A public teaching table cannot establish the complete cost of a specific proposal or recommend a switch based on a fictional deduction.

Keep report availability separate from product support. A provider may offer a downloadable file while our tools do not parse it. Conversely, a supported local export can have completeness limitations that require review. A manual worksheet is useful precisely because it can document those boundaries without pretending that every report is automatically compatible.

Build a bank-period bridge after the entitlement calculation

Each sample calculates expected net entitlement under its model. None states a posted bank receipt. To connect entitlement to a bank period, start with the supported opening amount due, add current entitlement, subtract matched receipts and obtain the closing amount due. Add other evidenced adjustments only when their meaning is established. The sign convention should remain explicit throughout.

Do not infer a missing payment merely by comparing current sales with current bank receipts. Fees, earlier balances and later settlements can explain differences. Equally, do not label every difference timing without evidence. A closing balance should have identifiable components and a next check. An unresolved amount remains unresolved even when a worksheet carries it forward neatly.

Use the actual reference and status together with amount, currency, outlet and dates. Equal values alone can produce accidental matches. If a transfer combines locations or several cycles, retain its supported composition. Do not split it arbitrarily across branches to make each schedule balance. The month-end guide works through these relationships in a separate complete fictional close.

Keep a record of later resolution. A received adjustment, rejected claim and accounting reclassification are different outcomes. Save the statement or response that establishes the change and update the next opening balance appropriately. An investigation log should preserve the original question rather than replace it with a fresh unexplained number each month.

Handle multi-market files without losing definitions

When a group operates across markets, maintain local schedules first. Keep currency, source dictionary, outlet scope and date basis attached to every result. A group account or common provider does not guarantee compatible data fields across countries. Do not remove those dimensions to obtain a smaller table if doing so makes the money impossible to interpret.

If a translated group view is needed, document the chosen exchange-rate source, relevant date or period and reporting purpose. Obtain the appropriate accounting policy for actual consolidation. Retain the local amounts so an exchange-rate movement can be distinguished from an operating movement. Changing a currency selector does not establish that translation or make unlike tax bases equivalent.

Compare compatible ratios only after checking their numerator and denominator. A fee-to-sales ratio can differ because the fee base, funded promotion treatment or included services differ. Even a correctly calculated percentage can answer a different question. Keep the money components visible, and avoid ranking markets using measures whose definitions cannot be aligned.

Use the multi-outlet guide for weighted totals and shared-cost allocation. It deliberately separates branch operating questions from cash consolidation. These market examples do not certify a cross-border accounting method, determine an entity's tax obligations or promise that a particular tool can consolidate international sources automatically.

Prepare a safe source pack for an actual review

Keep original reports, approved mapping, working calculation, source register and exception log together in authorised private storage. Label each file by purpose and selected scope. A large collection of downloads is not useful evidence unless another person can identify which version supports the result. Retain later corrections without overwriting the original history.

Remove unneeded personal information from analysis copies. Public teaching examples should use fictional identifiers and amounts. An exported file can contain customer names, instructions, bank references or hidden fields beyond the visible financial columns. Inspect the copy before legitimate sharing and use the provider's authenticated support channel when a private account issue requires evidence.

Ask support a precise question. Identify the report, period, outlet scope, field definition and exact difference being investigated. Do not send passwords, OTPs, cookies or session tokens. A generic request saying the payout is wrong gives less useful evidence than a specific explanation of the expected bridge and the actual statement line.

Keep legal retention and storage requirements local. Revenue, Inland Revenue, IRAS, HMRC and the FTA have different scopes and conditions. This article does not combine them into a universal number of years or a single approved storage method. Follow the current applicable guidance for the business and obtain qualified advice when the classification or obligation matters.

What to do when official pages disagree

Official material can still describe different product versions or contain inconsistent wording. Our research found a practical example in Toast's public help: an older access article gives a limited report-history period, while its newer Sales Summary FAQ describes no date-range limit. We therefore do not promise a universal historical window. Check the current account, report version and appropriate support route when historical availability matters.

Square's public reporting page also uses wording in different sections that should not be collapsed into one universal gross-sales formula. The safe response is to preserve the actual metric definition and inspect the relevant report context. Do not choose the sentence that makes your existing calculation easiest. A source-aware worksheet can record the uncertainty while continuing to use amounts whose meanings are established.

Keep a research note showing which pages were checked, their displayed dates when available and the exact unresolved question. A newer date can help prioritise a source, but it does not automatically establish applicability to every account or market. Public help can describe a limited release. Ask whether the actual user has that version before presenting a step-by-step interface as verified.

For contractual or tax matters, seek the applicable agreement or official local guidance rather than using a conflicting generic help sentence as a final ruling. An entitlement calculation should not become more confident than its evidence. Narrow the conclusion when needed: the worksheet can explain its own arithmetic while leaving actual report availability or a particular field treatment unconfirmed.

Keep the unresolved point out of reusable formulas until its meaning is established. Otherwise a single uncertain interpretation can spread into every outlet or country tab. Use a clearly labelled manual input or exclude the affected comparison with an explanation. Once the source is clarified, update the mapping and review dependent results. This approach lets the team continue useful work while preventing uncertainty from becoming an invisible assumption in a shared report.

Distinguish a plausible format from authentic evidence

A table can look like a merchant report while containing entirely invented data. That is acceptable for a clearly labelled teaching exercise, as these examples are, but the appearance must not be used as proof of account access or an observed business result. A provider logo, familiar colour or realistic column heading does not establish authenticity. We use plain authored worksheet labels so the learning purpose stays clear.

For real business work, retain provenance: where the file came from, who was authorised to obtain it, what scope was selected and which version was used. Do not request credentials or session tokens to establish that provenance. The authorised operator should use the official process. A reviewer can inspect source references and aggregate controls without publishing private account or customer information.

Distinguish three kinds of statement in your notes. A provider fact is attributed to its current public explanation or actual account evidence. A calculation follows the stated input assumptions and can be checked independently. An interpretation is a judgement about what the result means for the business. Keeping those categories visible prevents a fictional number from being promoted into a provider claim or an uncertain cause being presented as an observed fact.

Use the same discipline when sharing a worked example with colleagues. Retain the fictional label and exclusions when copying a table into a presentation or message. A caveat left behind on another page cannot protect a detached table from being misunderstood. State the important assumptions with the numbers so a reader sees their purpose without needing to reconstruct the original conversation.

Read a changed report without overwriting its history

Suppose a provider revises a report after an order correction. Save the new file as a new source version and compare the affected records. Identify whether the change is a new event, a revised amount, a status update or a changed presentation. Those differences require different treatment. Appending the new file to the old one without a version rule can duplicate the original activity.

Preserve the source field and create a separate normalised interpretation when needed. A changed header may be a simple rename, or it may introduce a different inclusion rule. Confirm before mapping it to the previous field. A trend can move because the business changed or because the definition changed. Both should be explainable from the source and mapping history.

Recalculate control totals after applying an approved change. Keep the number of accepted records, relevant distinct identifiers and amount totals before and after. State the effect on the entitlement bridge and any opening or closing balance. A correction that changes last month's closing amount may also change this month's opening amount. Do not repair one chart while leaving the related clearing schedule inconsistent.

Where the change cannot be interpreted, keep the affected records in an exception list. Record the evidence needed and the next review date. Avoid renaming or deleting fields to suppress an error message. The traceable cleaning guide explains why preserving the source trail is more useful than producing a file that merely loads without complaint.

Practise a source-aware review

Choose one sample and explain the starting amount before calculating. State that its model sales are before the separately listed funded promotions and refunds, while tax and tips are excluded. Then identify each deduction and addition. If your actual source already nets one of those reductions, rewrite the mapping rather than copying the formula unchanged.

For the GBP example, explain why the separate GBP 50 assumed payout adjustment must not be confused with Deliveroo's named Credit Note column. For the AUD example, explain why a localised help URL does not establish access to a United States-only export feature. For the NZD example, name the difference between a useful manual ledger and a verified native merchant schema.

Finally, name the evidence still missing before you can call the result cash received or restaurant profit. Bank evidence is needed for a receipt, while ingredients, staffing, occupancy and other appropriate costs are needed for the relevant profitability question. An accurate entitlement bridge is useful, but its scope should remain visible when the result moves into another report or meeting.

Sources and review limits

Public material reviewed 17 October 2026 includes Uber's United States and Canadian report definitions, DoorDash's Australian-localised feature boundary, Deliveroo's invoice categories, Grab's Singapore report overview and Deliveroo's UAE recurring-fee explanation. These support concise scoped distinctions, not claims of authenticated testing.

Local record references are HMRC, Inland Revenue New Zealand, Revenue Ireland, IRAS and the UAE FTA corporate-tax reminder. The exact native schemas, account permissions and contracts were not verified. All worksheet examples were independently authored and calculated. Use the manual workbooks for practice while preserving current product, privacy and source boundaries.