Follow a restaurant payout, rupee by rupee.

Check the maths without relying on the screen

Use a consistent starting basis. For these invented files, “net order value” is the provided starting settlement value. It is not assumed to be gross sales, taxable turnover or bank cash. The examples deliberately keep every deduction category separate.

Zomato-shaped example: a timing gap and a ₹200 calculation gap

Cycle A has 100 orders and a starting value of ₹50,000. Additions are ₹600. Order deductions are ₹12,500, tax deductions ₹2,100 and growth deductions ₹2,000. Procurement is zero.

The recorded payout and the invented bank credit are both ₹34,000. That cycle ties out. Cycle B has 80 orders and is still processing at the initial review date, 15 July 2026.

Cycle B records only ₹25,200. That is ₹200 below the independently calculated value. Keep the ₹200 as an unresolved calculation difference; the sample does not invent a reason for it. Separately, the initial bank credit for cycle B is zero. Because its scheduled sample payout date is 17 July, the ₹25,200 bank gap is a timing item to follow up—not evidence of an extra fee.

Tick the bank exercise to advance past that date and post a ₹25,200 credit. The bank-to-record gap becomes zero, but the ₹200 calculation gap remains. It takes a source adjustment or correction, not just a later bank transfer, to explain that difference.

The JSON deliberately repeats cycle A with the same synthetic payout ID and the same numbers. Summing the raw detail objects would count ₹34,000 twice. The analyser keeps one copy per platform and payout ID, producing two unique cycles, 180 orders and ₹59,200 of recorded payouts. If two copies disagree in a real report, investigate the source versions; “first copy wins” is not proof that the older figure is right.

Swiggy-shaped example: settlement maths matches, bank does not

Both recorded payouts match the calculations. The combined result is 210 orders and ₹70,400 of recorded payouts. However, the invented bank credits are ₹39,900 and ₹30,300: ₹200 is missing from the second credit in this teaching record. The status says “Paid,” which still does not prove that the right amount reached the bank.

Check the bank value date, reference and split credits first, then the payout details. The exercise adds the missing ₹200 as a separately confirmed credit; once that evidence is supplied, bank credits total ₹70,400. Do not silently classify an unexplained gap as commission, tax, fraud or loss.

What the numbers mean—and do not mean

Order deductions

A sample bucket for order-related adjustments. In an actual file, review the detailed fee, discount and refund labels; this bucket alone cannot tell you which contract rate applied.

Tax deductions

The amount provided in that report category. This demo does not determine whether it is GST, withholding or recoverable credit. Match actual entries to their invoices and tax records.

Growth deductions

The sample's advertising or marketing bucket. Classifying the amount does not prove that a campaign was profitable; compare attributable incremental contribution separately.

Procurement deductions

Purchasing spend shown in the statement, labelled Hyperpure in the Zomato-shaped file. Do not subtract the same purchase again when measuring cash outflow, and do not confuse purchases with ingredients consumed during the period.

Payout retained

Recorded payout ÷ provided order value × 100. The Zomato-shaped example retains 65.8%; the Swiggy-shaped example 67.0%. Neither number is profit margin. Ingredient use, staffing, rent and other expenses are still missing.

Calculation variance

Recorded payout minus the payout rebuilt from the supplied categories. Negative means the record is below the calculation; it does not explain why.

Bank variance

Matched bank credits minus recorded payout. Keep pending transfers, split credits and date differences visible instead of mixing them with settlement fees.

Why the demo is different from a real audit

These files intentionally omit order-level lines, invoice evidence and actual banking records. The exercise proves arithmetic and matching logic only. It cannot verify order eligibility, a tax position, invoice authenticity or an actual contractual liability. A reported payout can look consistent while its source lines are still incomplete.

Repeat the checks with your own authorised data

1. Export only an outlet you are authorised to access. Keep the raw file unchanged.
2. Open the settlement analyser and choose a supported ZIP, JSON or settlement CSV. Free access permits one file and up to three payout cycles; a subscription is optional for batches and larger reports.
3. Check the detected platform, covered dates, unique payout count and field totals against the original report. A missing field is not proof of a zero charge.
4. Match each payout to bank credits using the reference and value date. The web analyser does not read your bank account; record the match yourself in a control sheet.
5. Keep unexplained differences with an owner and evidence request. Share only redacted references with support—never a partner password or full customer data.

Want to understand profitability after the payout? Read restaurant contribution margin and add your own food cost, packaging and fixed expenses. To learn what the extension actually exports, visit About the extension.