RECONCILIATION GUIDE
How to reconcile a restaurant settlement without losing the order trail
A settlement statement is not simply a sales report. It is a bridge between customer orders, platform adjustments, service invoices and the amount that reaches the bank. A useful reconciliation proves each stage of that bridge instead of comparing only total sales with total payout.
Start with four separate records
Collect the order-level report, the settlement or payout statement, fee and tax invoices, and the bank statement for the same period. Keep each source separate. The order report explains what customers ordered; the settlement explains how payable value was calculated; invoices support service charges and their GST; the bank statement confirms cash receipt.
Use a stable matching key. Order ID is normally the best key for order-related rows, while settlement ID or UTR is better for matching payout cycles to the bank. Do not force invoice-level charges onto individual orders unless the source provides a reliable allocation key.
Build the settlement equation
The exact labels vary. Classify rows by economic meaning, not by their position in a CSV. A packaging charge collected from a customer is revenue only if it belongs to the restaurant. GST collected on food may be handled differently from GST charged on platform services. Check your contract and invoices before deciding.
A worked example
Assume the included orders produce ₹100,000 of restaurant revenue. The restaurant funds ₹4,000 of discounts. Commission and other taxable platform services are ₹20,000, GST on those services is ₹3,600, refunds and penalties are ₹1,400, and reimbursements are ₹500. The expected payout is ₹71,500. If the bank shows ₹70,900, the unexplained difference is ₹600—not ₹29,100. The larger number consists mostly of known deductions.
| Component | Amount | Treatment |
|---|---|---|
| Restaurant revenue | ₹100,000 | Starting value |
| Funded discounts | −₹4,000 | Deduction |
| Platform services | −₹20,000 | Deduction |
| GST on services | −₹3,600 | Deduction |
| Refunds and penalties | −₹1,400 | Deduction |
| Reimbursements | +₹500 | Credit |
| Expected payout | ₹71,500 | Control total |
Investigate differences in the right order
- Date boundary: an order placed at month-end may settle in the next payout cycle.
- Status: cancelled, rejected and refunded orders should not be treated as fully delivered revenue.
- Duplicates: one order can have multiple transaction rows; aggregate by transaction type before summing.
- Tax basis: separate tax on food from tax on platform services and withholding entries.
- Carry-forwards: prior-cycle adjustments can appear in a later statement.
- Bank timing: the settlement date and value date may differ.
Use a reconciliation control sheet
For every payout, record its settlement ID, covered dates, gross included order value, each deduction category, each credit, expected payout, bank amount and variance. Preserve the raw exports unchanged and perform transformations in a separate workbook. That makes the process repeatable and lets another person trace a number back to source.
Frequently asked questions
Should item sales equal settlement sales?
Not always. Item reports may use order date while settlements use payout eligibility or delivery date. They may also exclude taxes, packaging, cancellations or adjustments. First align scope and definition.
Can I reconcile without order-level data?
You can prove the payout cycle at an aggregate level, but you cannot fully attribute every difference to a specific order. Mark that limitation instead of inventing a link.
Does the free analyser upload my statement?
No. The current web analyser reads supported files locally in the browser. Review the preview and classification before relying on its totals.
Educational information only. Platform terms and tax treatment vary; verify your contract, invoices and professional advice.