Zomato MIS Reconciliation for Restaurants
Restaurants that sell through Zomato often need to compare internal MIS or POS data with partner reports covering orders, commissions, refunds, taxes, and settlement amounts. Cointab helps finance teams reconcile Side A internal records with Side B Zomato reports in a structured workflow, so differences are easier to review, explain, and report.
What Zomato MIS reconciliation covers
A restaurant reconciliation workflow usually compares the business's own records against the reports received from Zomato. That can include:
- Internal sales or POS/MIS reports from the restaurant
- Zomato order or settlement reports
- Commission, GST, TCS, and TDS deductions
- Cancellation refunds or adjustments
- Amounts settled in the bank
- Pending or delayed settlement amounts
Cointab is designed to handle this as a repeatable reconciliation setup, rather than a one-off spreadsheet exercise.
Side A and Side B in a restaurant workflow
Cointab uses a clear Side A and Side B model:
Side A: your internal records
These are the records the restaurant expects to be correct. Common examples include:
- POS or MIS sales data
- Store-level sales registers
- Internal settlement working files
- Ledger or accounting exports
- Outlet-wise order summaries
Side B: Zomato reports
These are the external records received from Zomato. Common examples include:
- Zomato order reports
- Settlement summaries
- Deductions and fee reports
- Refund or cancellation details
- Bank settlement references
This structure makes it easier to compare what the restaurant recorded internally with what Zomato reported and paid out.
Why restaurant teams reconcile Zomato data
Manual reconciliation often becomes slow when a restaurant has multiple outlets, frequent orders, and monthly settlement statements. Finance teams use Zomato MIS reconciliation to:
- Identify missing or delayed payments
- Validate commission and fee deductions
- Review refunds and cancellation adjustments
- Check whether bank settlements match partner reports
- Spot differences across outlets or periods
- Reduce dependence on formula-heavy Excel files
- Keep month-end close and audit review more controlled
Instead of reviewing every transaction manually, teams can focus on exceptions such as partial matches, unmatched records, and skipped rows.
How Cointab structures the reconciliation process
A typical reconciliation run follows a simple sequence:
- Upload the required files for Side A and Side B.
- Map the important fields such as date, amount, and identifiers.
- Add optional supporting data if needed for lookups or enrichment.
- Create derived columns when a calculated field is required.
- Run the reconciliation manually or on a schedule.
- Review matched, partially matched, unmatched, and skipped transactions.
- Download the reconciliation report for internal review or audit.
This workflow can be reused for future months, so the setup does not need to be rebuilt every time.
Common fields in restaurant settlement reconciliation
Restaurant reconciliation reports often include transaction-level detail as well as monthly store summaries. Some commonly reviewed fields are:
| Field | What it helps review |
|---|---|
| Restaurant ID / Store ID | Links outlet-level records across reports |
| Transaction month | Groups the reconciliation period |
| Sales as per POS | Internal sales recorded by the restaurant |
| Sales as per Zomato | Sales reported by Zomato |
| Total deductions | Commission, GST, TCS, TDS, and similar charges |
| Cancellation refund | Refunds tied to cancelled orders |
| Calculated payable | Expected payout after deductions |
| Net receivable as per Zomato | Amount reported by Zomato as payable |
| Difference | Gap between calculated and reported payable |
| Amount settled in bank | Actual settlement received |
| Amount pending | Settlement not yet received |
These fields help finance teams understand not only what was paid, but also why the final payout may differ from internal expectations.
Matching logic for Zomato MIS reconciliation
Cointab's reconciliation engine is built for structured transaction matching. In a restaurant use case, that can include:
- One-to-one matching for direct order references
- One-to-many or many-to-one matching when records are grouped differently
- Net-to-net comparisons for settlement totals
- Partial matching when identifiers match but amounts differ
- Contra or adjustment handling where applicable
The system supports identifier-based matching such as order ID, transaction reference, restaurant ID, settlement ID, or other business identifiers. If records do not match cleanly, they remain visible for review instead of being forced into a weak match.
Handling differences and exceptions
For restaurant finance teams, the real value of reconciliation often lies in the exceptions. Cointab separates records clearly so users can review the reason for the gap.
Fully matched
These are records where the expected reference and amount match according to the configured rules.
Partially matched
These are records where the reference matches, but the amount does not. This is useful for identifying short payments, overpayments, deductions, or rounding differences.
Unmatched
These are records present on one side but not found on the other. For example, an order may appear in the POS report but not in the Zomato settlement report, or vice versa.
Skipped
These are rows that were not included in reconciliation because of missing columns, invalid values, duplicate rows, or file issues.
Users can also manually match transactions when the business context is clear but the system cannot confidently match them automatically.
Supporting data and derived columns
Restaurant teams often need more than just the primary order and settlement files. Cointab allows optional supporting data to be uploaded for enrichment, lookup, or preparation. Examples include store masters, outlet mappings, fee reference files, or other internal reports.
Users can also create derived columns using AI-generated Excel-style formulas. This helps finance users build calculated fields such as:
- Net amount after fees
- Clean order reference
- Delivered payment amount
- Refund amount as a negative value
- Combined reference fields
These calculated fields can then be used in the reconciliation logic.
Reusable for monthly restaurant close
Zomato MIS reconciliation is typically recurring, not one-time. Cointab supports reusable reconciliation setups so finance teams can run the same workflow for each period with minimal repeat work.
This is useful for:
- Monthly outlet-wise reconciliation
- Quarterly and yearly close
- Rolling settlement review
- Multi-store restaurant groups
- Periodic review of unpaid or short-settled items
If a report is received late, users can upload the missed file under the same reconciliation and refresh the output.
Automation for recurring restaurant operations
Once the reconciliation is configured, teams can automate data flow through email, SFTP, or API-based input. That makes it easier to keep recurring restaurant finance workflows moving without repeated manual uploads.
Cointab can also support scheduled reconciliation runs, so the report is prepared when the required data is available. The output can then be made available as an Excel reconciliation report for internal review, reporting, and audit support.
What the report helps finance teams see
After the run completes, teams can review the reconciliation output in a dashboard that shows matched, partially matched, unmatched, and skipped records. This makes it easier to answer practical questions such as:
- Which orders were paid correctly?
- Which deductions need review?
- Which settlements are still pending?
- Which outlet or month has the largest difference?
- Which records need manual follow-up?
For restaurant finance teams, that clarity is often more useful than a single summarized payout number.
FAQs
What files are usually needed for Zomato MIS reconciliation?
Most restaurant workflows use an internal MIS or POS export as Side A and a Zomato order or settlement report as Side B. Depending on the setup, supporting files such as outlet mappings or fee reference files can also be added.
Can multiple outlets be reconciled in the same workflow?
Yes. A restaurant group can reconcile store-wise data within the same setup, which is useful when sales, fees, and settlements need to be reviewed by outlet and by period.
What happens if a settlement report is missing?
The missed file can be uploaded later under the same reconciliation. After that, the report can be refreshed so the new data is included in the output.
Can the same Zomato reconciliation be reused every month?
Yes. Once the reconciliation logic and field mapping are configured, the same setup can be reused for future periods instead of being rebuilt from scratch.
Does Cointab only compare one type of restaurant file?
No. Cointab is built as a flexible reconciliation engine, so it can compare internal records with different external reports as long as the files are mapped into the same workflow.
