If your restaurant uses Posist for restaurant operations and receives online orders through Zomato, your finance team has three different versions of the same commercial activity to reconcile.

Posist records the restaurant sale.

Zomato records the marketplace order and calculates the eventual amount payable to the restaurant.

The bank confirms whether that settlement was actually received.

The complete reconciliation therefore becomes:

Posist Restaurant Sales → Zomato Orders & Settlements → Bank Statement

This creates two linked reconciliations:

Reconciliation 1

Posist ↔ Zomato

Did every Zomato order recorded in Posist appear correctly in Zomato's report, and do the order values agree?

Reconciliation 2

Zomato ↔ Bank

After Zomato applied commissions, discounts, taxes, TDS/TCS, logistics charges and other settlement components, did the expected settlement actually reach the restaurant's bank account?

Together, these create an end-to-end 3-way Zomato reconciliation.

Cointab can automate both stages and help restaurant finance teams move from manually comparing spreadsheets to reviewing a focused list of exceptions.

---

Why restaurants need Zomato reconciliation

A restaurant may process hundreds or thousands of Zomato orders across:

• Multiple outlets
• Multiple cities
• Different order types
• Different discount constructs
• Different service-fee arrangements
• Different settlement cycles

At the POS level, the transaction may appear straightforward.

For example:

Order ID: ZOM-784521
Net Sale: ₹850

But Zomato's report for the same order can contain many financial components:

• Item subtotal
• Packaging charge
• Restaurant discount
• Zomato-funded or other discount structures
• Delivery charges
• Service fee
• Payment-gateway charges
• Logistics charges
• Taxes on fees
• TCS
• TDS
• Customer compensation or recoupment
• Final amount payable

The amount received in the bank therefore does not necessarily equal the restaurant's gross or net sales reported in Posist.

Reconciliation is what explains the movement from:

Restaurant order value → Zomato calculation → Bank receipt

---

The complete restaurant reconciliation flow

A useful way to think about the workflow is:

Customer places Zomato order

↓

Order recorded in Posist

↓

Order appears in Zomato report

↓

Zomato calculates fees, taxes and adjustments

↓

Orders are grouped into settlements

↓

Zomato transfers settlement to bank

↓

Bank records the credit

The finance team needs evidence that every step is complete.

---

What does the Posist report contain?

A Posist sales or order report may contain fields such as:

The exact Posist export may contain additional operational fields.

For Zomato reconciliation, particularly useful fields can include:

• Order Id
• Store Name
• Date
• Bill Number
• Channel
• Subtotal
• Discount
• Net Sale
• GST
• Packaging Charges

---

What does the Zomato report contain?

The Zomato order and settlement report is considerably richer.

It can include fields relating to:

Order identification

• Order Date
• Order ID
• Restaurant ID
• Restaurant Name
• State
• Order Type
• Order Status

Sales value

• Subtotal
• Packaging Charge
• Total GST collected
• Total order amount

Discounts

• Restaurant promotional discount
• BOGO / Freebies / Gold and other discounts
• Merchant delivery-charge discount
• Other discount constructs

Zomato charges

• Base service fee
• Additional service fee
• Total service fee
• Payment-gateway charge
• Logistics charge

Taxes and statutory deductions

• Tax on commission
• Tax on PG charges
• TCS amount
• TDS amount
• GST-related values

Other settlement adjustments

• Customer compensation / recoupment
• Long-distance enablement fee
• Related discounts

Settlement

• Final amount
• Settlement status
• Settlement date
• Bank UTR

This report provides the financial bridge between the restaurant order and the actual amount Zomato eventually settles.

---

Start with order-level Posist vs Zomato reconciliation

The first step should be:

Posist Order ↔ Zomato Order

The most obvious common identifier is:

Order Id

in Posist and:

Order ID

in Zomato.

For example:

Posist

Order Id:

452178964

Store:

Restaurant - Indiranagar

Net Sale:

₹1,250

Zomato

Order ID:

452178964

Restaurant:

Restaurant - Indiranagar

Relevant order value:

₹1,250

The transaction can be identified on both sides.

Cointab can then compare the relevant financial components.

---

Fully Matched Zomato orders

An order is Fully Matched when:

• The same order can be identified in Posist and Zomato
• The configured financial values agree

For example:

Posist

Order ID:

ZOM-78521

Subtotal:

₹900

Packaging:

₹50

Relevant order value:

₹950

Zomato

Order ID:

ZOM-78521

Subtotal:

₹900

Packaging Charge:

₹50

Relevant order value:

₹950

The order agrees across both datasets.

Cointab can classify it as:

Fully Matched

---

Partially Matched Zomato orders

The same Order ID may exist in both systems but the financial values may differ.

For example:

Posist

Order ID:

ZOM-65218

Net Sale:

₹1,200

Zomato

Order ID:

ZOM-65218

Relevant amount:

₹1,150

The Order ID confirms that both rows represent the same customer order.

But the amounts differ by:

₹50

Cointab reports:

Partially Matched

The finance team can investigate the exact financial components responsible for the difference.

---

Posist order missing from Zomato

Suppose Posist contains:

Order ID: ZOM-85421

Store: Koramangala

Amount: ₹1,450

but no corresponding order can be identified in Zomato's report.

Cointab reports:

Present in Posist but not found in Zomato

The team can investigate whether:

• Wrong channel was recorded in Posist
• Order belongs to another Zomato reporting period
• Order ID was captured incorrectly
• Transaction was cancelled or reversed differently
• Source data is incomplete

---

Zomato order missing from Posist

The reverse situation is particularly important.

Suppose Zomato reports:

Order ID: ZOM-98542

Order Status: Delivered

Amount: ₹980

but there is no corresponding order in Posist.

Cointab reports:

Present in Zomato but not found in Posist

The restaurant team can investigate whether:

• Order failed to reach Posist
• POS integration failed
• Order was manually handled
• Order was recorded under another identifier
• Outlet data is incomplete

This can expose operational as well as accounting differences.

---

Store Name and Restaurant ID help with multi-outlet reconciliation

Restaurants often operate multiple outlets.

Posist contains:

Store Name

Zomato provides information such as:

• Res_id
• Res_name

This lets the finance team retain outlet context while reconciling orders.

For example, two orders may have similar:

• Dates
• Amounts
• Bill numbers

but belong to different restaurants.

The outlet or restaurant mapping helps prevent incorrect matching and allows exceptions to be analyzed store by store.

---

Reconcile restaurants separately when required

A restaurant group may want to review results by outlet.

For example:

If one outlet has a disproportionate number of exceptions, the finance team can investigate whether there is a local:

• POS integration issue
• Order-status problem
• Outlet configuration issue
• Mapping problem

---

Delivered and cancelled orders should not be treated the same

Zomato provides:

Order status (Delivered/ Cancelled)

This is important because not every order should be expected to generate the same financial result.

A delivered order follows the normal settlement process.

A cancelled order may involve:

• Full refund
• Partial compensation
• Cancellation policy
• Restaurant compensation
• No payable amount

The reconciliation should therefore retain the order status during exception review.

---

Cancellation policy can affect the restaurant's financial entitlement

Zomato also provides information relating to:

Cancellation policy (% Amount refunded back to restaurant partner)

and:

Cancellation / Rejection Reason

Suppose an order was cancelled after preparation.

The restaurant may still receive a portion of the value depending on the applicable treatment.

A straightforward comparison of:

Posist Net Sale vs Zomato Final Amount

may therefore be misleading for cancelled transactions.

The cancellation-related fields can explain why the financial treatment differs.

---

Discounts need to be reconciled carefully

Restaurant marketplace orders can contain several types of discounts.

Zomato may separately report:

• Restaurant discount [Promo]
• Restaurant discount [BOGO, Freebies, Gold & others]
• Merchant delivery charge discount
• Other discount constructs

Posist may show the restaurant-side:

Discount

field.

The finance team therefore needs to understand which discounts actually affect the restaurant's revenue and settlement.

This is one reason the reconciliation should preserve the underlying discount components rather than compare only a final total.

---

Example: discount explains the order-value difference

Suppose:

Posist

Gross Amount:

₹1,000

Discount:

₹100

Net Sale:

₹900

Zomato

Subtotal:

₹1,000

Restaurant Discount:

₹100

Relevant restaurant value:

₹900

The apparent ₹100 difference from gross sales is completely explained.

The transaction can still reconcile correctly when the comparable fields are configured.

---

Packaging charges need their own comparison

Posist may contain several packaging charge columns depending on configuration.

Zomato separately reports:

Packaging charge

For an order such as:

Posist

Subtotal:

₹800

Packaging:

₹40

Zomato

Subtotal:

₹800

Packaging:

₹40

the packaging component can be validated independently.

This is useful because differences can otherwise become hidden inside the overall order amount.

---

A customer's total order value is not necessarily the restaurant's settlement amount

Consider an order where the customer pays:

₹1,200

The restaurant should not automatically expect Zomato to deposit ₹1,200 into the bank.

The settlement may include adjustments for:

• Restaurant discounts
• Service fee
• Payment-gateway fee
• Logistics
• Taxes on fees
• TDS
• TCS
• Customer compensation
• Other adjustments

This is why:

Posist vs Bank

is not sufficient.

The Zomato report is the bridge.

---

Move from order reconciliation to settlement reconciliation

Once the underlying orders have been validated, the next question is:

How did Zomato calculate the amount payable to the restaurant?

A useful conceptual bridge is:

Order Value

↓

Applicable Discounts

↓

Zomato Service Fees

↓

Payment Gateway / Logistics Charges

↓

Taxes and Statutory Deductions

↓

Other Adjustments

↓

Final Amount

↓

Settlement

↓

Bank Receipt

---

Base service fee and additional service fee

Zomato can report:

• Base service fee %
• Additional service fee % based on distance
• Total service fee %
• Total Service Fee

These fields help explain the commercial fee charged on the order.

Rather than treating the difference between sales and settlement as one unexplained amount, the finance team can validate the individual fee components.

---

Service fee reconciliation can identify incorrect deductions

Suppose an order has a commissionable amount of:

₹1,000

and the configured service fee should result in:

₹200

but Zomato's report shows:

₹230

The transaction may require investigation.

The objective is not only to confirm that Zomato paid something.

It is also to understand whether the settlement calculation is correct.

---

Payment gateway charges reduce the settlement

Zomato can separately report:

• pgcharge_base
• pgcharge
• Taxes on PG charges

These components may reduce the amount ultimately payable to the restaurant.

A reconciliation can preserve these deductions and validate the settlement bridge.

---

Logistics charges may also affect the settlement

Depending on the order and commercial arrangement, Zomato can report:

Logistics charge

alongside distance-related fields such as:

• Actual order distance
• Long-distance enablement fee
• Discount on long-distance enablement fee

These can provide useful context when one order has a different settlement profile from another.

---

TDS and TCS should remain visible in the settlement working

Zomato provides fields including:

• tcs_amount
• tds_amount
• Applicable amount for TCS
• Applicable amount for TDS

These statutory-deduction fields can help explain why the net amount payable differs from the restaurant's underlying order value.

They should generally be retained in the reconciliation output so the finance team can understand the settlement calculation.

This reconciliation is not a substitute for tax advice, but it provides the transaction-level data required for the finance team to review the deductions recorded by Zomato.

---

GST-related components can also affect the settlement bridge

The Zomato report may contain fields such as:

• Total GST collected from customers
• GST paid by Zomato on behalf of restaurant under section 9(5)
• GST to be paid by restaurant
• Taxes on commission
• Taxes on payment-gateway charges

These values should not simply be collapsed into one unexplained difference.

Keeping them visible allows the restaurant finance team to understand how Zomato arrived at the final payable amount.

---

Section 9(5) data deserves separate visibility

Zomato's report explicitly provides values associated with section 9(5).

For relevant orders, the finance team can retain fields such as:

• Applicable tax base
• GST collected
• GST paid by Zomato on behalf of the restaurant
• GST amount attributed to the restaurant

This makes it easier to review marketplace tax treatment alongside the order reconciliation.

Again, Cointab is reconciling the source data; the restaurant's tax team remains responsible for determining the correct accounting and tax treatment.

---

Customer compensation and recoupment can explain unusual adjustments

Zomato also reports:

Customer Compensation/Recoupment

This can create settlement movements that are not obvious from the original Posist order.

For example, customer compensation may affect what Zomato ultimately pays the restaurant.

When such a transaction generates a difference, the finance team can see the adjustment rather than treating it as an unexplained short settlement.

---

Calculate the bridge to final_amount

One of the most useful Zomato fields is:

final_amount

Conceptually, the reconciliation can validate how each order moves from its commercial value to the amount ultimately attributable to the restaurant.

For example:

Order / restaurant value

minus / plus:

• Relevant discounts
• Service fee
• PG charges
• Logistics
• Tax components
• TCS / TDS
• Compensation or recoupment
• Other adjustments

equals:

Final Amount

The exact Zomato calculation should follow the fields and logic present in the report rather than a manually assumed formula.

---

Example: sales value is ₹1,000 but final amount is lower

Suppose:

Posist

Net Sale:

₹1,000

Zomato

Order recognized:

₹1,000

Service fee and related deductions:

₹200

Other relevant deductions:

₹30

Final Amount:

₹770

The ₹230 difference from Posist is not automatically an error.

The reconciliation can show exactly how Zomato reached ₹770.

The finance team then needs to investigate only if one of those components is unexpected.

---

Reconcile one order across multiple financial components

A useful Zomato reconciliation output can retain:

This turns a simple:

₹1,000 vs ₹710

difference into an explainable settlement calculation.

---

Settlement status tells you whether Zomato has processed the payable amount

After order-level settlement values are calculated, Zomato provides:

Settlement status

This helps distinguish between:

• Amount calculated but not yet settled
• Amount included in a completed settlement
• Another settlement state

A transaction can therefore reconcile correctly at the order level while still remaining unsettled.

---

Settlement date provides the expected bank timeline

Zomato also provides:

Settlement date

This tells the finance team when the settlement was processed or attributed.

The corresponding bank credit may appear:

• On the same date
• On the next banking day
• Within the normal settlement window

The bank value date therefore does not necessarily need to equal the Zomato order date.

---

Bank UTR provides the strongest bridge to the bank statement

Zomato provides:

Bank UTR

The bank statement may contain the same reference in:

• Description
• CHQ/reference field
• Other bank narration

This creates the second reconciliation:

Zomato Settlement ↔ Bank Credit

For example:

Zomato

Settlement date:

18 August

Bank UTR:

HDFC985214763

Settlement amount:

₹4,82,500

Bank

Transaction date:

18 August

Description:

ZOMATO SETT HDFC985214763

Credit:

₹4,82,500

The settlement exists in both sources for the same amount.

Cointab can classify it as:

Fully Matched

---

What does the bank statement contain?

A bank statement used for this reconciliation may contain:

For Zomato settlement matching, the most useful fields are typically:

• Transaction Date
• Value Date
• Description
• CHQ / reference
• Credit

---

Zomato says settled but the bank credit is missing

Suppose Zomato reports:

Settlement Status: Settled

Settlement Date: 20 August

Bank UTR: UTR78521469

Amount: ₹6,40,000

but no corresponding bank credit can be identified.

Cointab can report:

Present in Zomato but not found in Bank

The finance team can investigate:

• Settlement timing
• Correct bank account
• Bank-statement period
• UTR formatting
• Delayed transfer
• Incorrect settlement data

This is specifically a:

Zomato → Bank

exception.

The underlying restaurant orders may already be fully reconciled.

---

Bank credit exists but Zomato settlement is unidentified

The reverse situation may also occur.

The bank shows:

Credit: ₹5,18,000

Description: ZOMATO

Reference: UTR45218963

but no corresponding Zomato settlement has yet been identified.

The finance team can investigate:

• Different Zomato report period
• Settlement grouping
• Missing source report
• Reference formatting
• Settlement belonging to another restaurant entity

The bank-side exception remains separate until the corresponding settlement is identified.

---

Multiple Zomato orders are normally settled together

At the order stage, reconciliation can often be:

One Posist Order ↔ One Zomato Order

At the bank stage, the relationship changes.

Many Zomato orders may be combined into one settlement.

For example:

• 750 delivered orders
• Less cancellations and adjustments
• Less applicable fees and deductions

may result in:

One Zomato settlement of ₹8,42,500

which appears as:

One bank credit of ₹8,42,500

This means the finance team should not try to match individual Posist orders directly to bank entries.

---

The correct 3-way relationship

The complete relationship is:

Stage 1

Individual Posist Orders ↔ Individual Zomato Orders

Stage 2

Many Zomato Orders / Adjustments → Zomato Settlement

Stage 3

Zomato Settlement ↔ Bank Credit

Cointab can preserve these different levels of reconciliation.

---

Example: complete Zomato order-to-bank flow

Suppose an outlet has:

Order ID: ZOM-45218

Posist

Net Sale:

₹1,200

Zomato

Order recognized.

After the applicable financial components, the order contributes:

₹875

to the merchant payable amount.

That order is included with hundreds of other orders in:

Settlement: ₹5,42,000

Zomato reports:

Bank UTR: UTR85214763

The bank contains:

Credit: ₹5,42,000

Reference: UTR85214763

The complete chain is:

Posist Order ✓ → Zomato Order ✓ → Settlement ✓ → Bank ✓

---

Example: Posist and Zomato agree but the settlement is still pending

Posist

Order exists and value agrees.

Zomato

Order exists and financial components reconcile.

Settlement Status:

Pending

The order-level reconciliation is complete.

There is not yet a bank exception because the gateway has not reported the settlement as completed.

The transaction is simply awaiting the normal settlement process.

---

Example: Zomato settlement completed but bank receipt is missing

Zomato

Settlement:

₹7,25,000

Status:

Settled

UTR:

UTR98521478

Bank

No matching credit.

This becomes a high-priority settlement exception.

The finance team now knows that the issue has nothing to do with:

• Posist
• Restaurant order
• Order amount

It is specifically between:

Zomato Settlement ↔ Bank

---

Example: cancellation creates an order-level difference

Posist

Order:

ZOM-65421

Recorded value:

₹900

Zomato

Order Status:

Cancelled

Cancellation treatment:

Partial restaurant compensation

The expected amount may therefore differ from the normal delivered-order value.

Keeping:

• Order Status
• Cancellation reason
• Cancellation policy

in the reconciliation allows the difference to be investigated correctly.

---

Example: Zomato discount explains the difference

Posist

Gross sale:

₹1,500

Discount:

₹200

Net Sale:

₹1,300

Zomato

Subtotal:

₹1,500

Relevant restaurant discount:

₹200

Comparable order value:

₹1,300

The order can reconcile even though the gross and net amounts differ.

---

Example: TDS/TCS explain part of settlement difference

Suppose the restaurant's underlying payable before statutory deductions is:

₹10,000

and Zomato reports relevant:

• TDS
• TCS

that reduce the immediate net settlement.

The bank credit will therefore be lower than the pre-deduction amount.

The reconciliation keeps these deductions visible so the finance team can explain the difference and separately perform the required accounting review.

---

Reconcile Zomato fees instead of treating them as one deduction

For a finance team, it can be useful to retain individual Zomato deduction categories such as:

• Service fee
• Additional service fee
• PG charges
• Logistics charges
• Taxes on commission
• Taxes on PG
• TDS
• TCS
• Long-distance fee
• Other adjustments

This gives a much richer control than comparing:

Restaurant sales vs bank receipt

and calling the entire difference "Zomato commission."

---

Validate expected commercial charges

Where the restaurant knows the agreed commercial rates, the detailed Zomato fields can also support further validation.

For example, finance may want to investigate whether:

• Base service fee is as expected
• Additional distance-related fee is correctly applied
• PG charges are reasonable
• Logistics charges apply to the correct orders

Cointab can retain these columns in the reconciliation working so the restaurant can perform the relevant checks.

---

Refunds and reversals need separate treatment

Although many Zomato restaurant reports focus on delivered and cancelled orders, other adjustments can affect settlement.

Where refund, reversal, compensation or recoupment information exists, the finance team should not force these transactions into normal delivered-order logic.

They may need to be:

• Identified separately
• Linked back to the original order
• Included in the appropriate settlement period

This prevents valid adjustments from appearing as unexplained differences.

---

Posting periods can differ across the three datasets

The same commercial activity can have three different dates.

For example:

Posist

Order Date:

31 July

Zomato

Order Date:

31 July

Settlement Date:

2 August

Bank

Value Date:

2 August

All three can be correct.

The reconciliation should therefore understand the lifecycle rather than requiring:

Order Date = Settlement Date = Bank Date

---

Weekend settlements can cross reporting periods

Suppose an order is delivered on Saturday.

Posist and Zomato both record the order immediately.

The resulting Zomato settlement may reach the bank on Monday.

At Saturday's reconciliation:

Posist ↔ Zomato = Matched

but:

Zomato ↔ Bank = Not yet due for settlement

On Monday, the settlement leg can complete.

This prevents normal timing differences from being treated as missing money.

---

Multi-outlet restaurants can reconcile each Zomato relationship independently

A restaurant group may have several:

• Res IDs
• Restaurant names
• POS store names
• Legal entities
• Bank accounts

The reconciliation can retain this hierarchy so the finance team understands which Zomato settlement belongs to which outlet or entity.

This is especially valuable where collections for several restaurants eventually reach the same bank account.

---

Map Posist Store Name to Zomato Res_id / Res_name

One important setup step can be maintaining the relationship:

Posist Store Name → Zomato Restaurant ID / Restaurant Name

For example:

This ensures orders are compared within the correct restaurant population.

---

Manual Match for orders where references differ

Some genuine transactions may still remain unmatched.

For example:

Posist

Order ID:

ZMT-784521

Bill Number:

B-9852

Amount:

₹1,250

Zomato

Order ID stored in another reference format

Restaurant and order details otherwise agree.

If the finance team knows both records represent the same transaction, Cointab provides:

Manual Match

The user can:

1. Select the Posist order.
2. Select the corresponding Zomato order.
3. Review restaurant, date, amount and other information.
4. Confirm the match.

The transaction is then recorded as manually reconciled.

---

Manual Match can also be used for settlement references

A Zomato settlement may occasionally have a UTR or bank narration that does not match cleanly.

For example:

Zomato

Bank UTR:

HDFC985214763

Settlement:

₹6,20,000

Bank

Description:

ZOMATO SETTLEMENT

CHQ / Reference:

abbreviated or different

Credit:

₹6,20,000

If the finance team can independently establish that the two records belong together, it can manually match them.

---

A useful exception framework for restaurant finance teams

The complete 3-way reconciliation can reduce thousands of rows into a small number of meaningful exception types.

Posist vs Zomato exceptions

• Posist order missing from Zomato
• Zomato order missing from Posist
• Order amount difference
• Discount difference
• Packaging difference
• Order-status difference
• Outlet mapping difference

Zomato settlement exceptions

• Unexpected service fee
• PG charge difference
• Logistics-charge difference
• Tax/deduction difference
• Customer compensation / recoupment
• Other settlement adjustment

Zomato vs Bank exceptions

• Settlement marked completed but bank credit missing
• Bank credit without identified Zomato settlement
• UTR mismatch
• Settlement amount difference
• Timing difference

This makes ownership much clearer.

---

Know which team needs to investigate

Different exceptions belong to different teams.

Restaurant operations / POS team

Examples:

• Zomato order exists but Posist order is missing
• Wrong store mapping
• Order ID issue

Finance team

Examples:

• Settlement amount does not reconcile
• Zomato fees differ from expectation
• TDS/TCS needs accounting review
• Bank credit is unidentified

Zomato follow-up

Examples:

• Settlement marked completed but bank credit is missing
• Unexpected fee or deduction
• Missing order in Zomato report
• Unexplained settlement adjustment

Instead of maintaining one generic "Zomato difference" column, the reconciliation provides a structured resolution workflow.

---

Download the complete Posist vs Zomato vs Bank reconciliation in Excel

Once the reconciliation is complete, Cointab can provide the entire working in Excel.

The output can retain Posist information such as:

• Order ID
• Store Name
• Bill Number
• Date
• Channel
• Gross Amount
• Discount
• Net Sale
• GST
• Packaging Charges

alongside Zomato fields such as:

• Order ID
• Restaurant ID
• Order Status
• Subtotal
• Discounts
• Packaging
• Service Fee
• PG Charges
• Logistics Charges
• Tax components
• TDS
• TCS
• Final Amount
• Settlement Status
• Settlement Date
• Bank UTR

and bank information such as:

• Transaction Date
• Value Date
• Description
• Reference
• Credit

This provides an end-to-end order-to-cash audit trail.

---

Use the reconciliation for outlet-level profitability and settlement review

The detailed data also allows finance teams to understand which deductions are associated with each restaurant or outlet.

For example:

• Gross Zomato sales
• Restaurant-funded discounts
• Zomato fees
• Logistics charges
• Tax deductions
• Final settlements

Even if the immediate objective is reconciliation, retaining these fields can make the output more useful for broader financial analysis.

---

Use the reconciliation during month-end closing

At month end, restaurant finance teams may need to confirm:

• Total Posist Zomato sales
• Total Zomato delivered orders
• Cancelled orders
• Discounts
• Service fees
• PG charges
• Logistics
• TDS
• TCS
• Zomato payable amount
• Settlements processed
• Bank amount received
• Open reconciliation exceptions

A 3-way reconciliation provides transaction-level evidence behind each of these totals.

---

Do not reconcile Posist directly with the bank

This is a critical point.

Suppose Posist shows:

Zomato sales: ₹50,00,000

The bank may receive only:

₹40,00,000

after the relevant:

• Discounts
• Zomato charges
• Taxes
• Deductions
• Adjustments

That ₹10,00,000 difference is not automatically missing money.

The correct bridge is:

Posist Sales → Zomato Settlement Calculation → Bank Receipt

Without the Zomato report, the restaurant cannot properly explain the difference.

---

Why a 3-way reconciliation is more reliable

A two-way reconciliation answers only part of the question.

Posist vs Zomato

Confirms whether the restaurant and marketplace agree on underlying orders.

But it does not prove that the resulting money reached the bank.

Zomato vs Bank

Confirms the settlement reached the bank.

But without Posist, it does not prove that every underlying restaurant order was correctly included.

The three-way model provides both controls.

---

A complete status for each reconciliation layer

The restaurant can conceptually track:

This tells the finance team where each unresolved item sits in the process.

---

Reconcile Posist with Zomato regularly

For high-volume restaurant operations, the reconciliation can be run for each reporting period.

A typical workflow becomes:

1. Export the Posist sales report.
2. Obtain the Zomato order and settlement report.
3. Upload the Posist file into Cointab.
4. Configure Order ID, Store Name, date and relevant sales amounts.
5. Upload the Zomato report.
6. Configure Order ID, Restaurant ID, order status and relevant financial fields.
7. Run Posist vs Zomato reconciliation.
8. Review Fully Matched orders.
9. Investigate order-value differences.
10. Review orders present only in Posist.
11. Review orders present only in Zomato.
12. Review cancelled orders separately.
13. Analyze discounts and packaging differences.
14. Review Zomato service fees and other deductions.
15. Calculate and validate settlement amounts.
16. Upload the bank statement.
17. Match Zomato settlement UTRs against bank credits.
18. Review settlements missing from the bank.
19. Review unidentified Zomato-related bank credits.
20. Complete Manual Matches where required.
21. Download the reconciliation working.
22. Correct operational or accounting differences.
23. Upload revised data and rerun where required.

---

Older orders and settlements can reconcile in later periods

Timing differences can carry across periods.

For example:

31 August

Posist and Zomato both contain the delivered order.

The order reconciliation is complete.

The corresponding Zomato settlement has not yet reached the bank.

2 September

Zomato settles the amount.

The bank receives the credit.

The previously open settlement can now reconcile.

This allows order-level and settlement-level reconciliation to operate on their appropriate timelines.

---

Why automated Zomato reconciliation becomes important at scale

For a restaurant with a handful of Zomato orders, Excel may be manageable.

For a multi-outlet restaurant group, the process can quickly involve:

• Thousands of Posist transactions
• Thousands of Zomato orders
• Multiple restaurant IDs
• Numerous discount constructs
• Multiple fee types
• TDS and TCS
• Cancelled orders
• Settlement batches
• Bank credits

The work becomes less about doing one VLOOKUP and more about maintaining an entire reconciliation process.

---

Move from Excel formulas to exception management

A manual reconciliation may require:

• Exporting Posist
• Downloading Zomato reports
• Cleaning Order IDs
• Mapping restaurants
• Building lookups
• Comparing order values
• Reviewing discounts
• Calculating fees
• Reviewing taxes
• Checking TDS/TCS
• Grouping settlements
• Searching UTRs in bank statements
• Carrying unresolved items forward

Cointab changes this to:

Upload Posist → Upload Zomato → Reconcile Orders → Validate Settlement → Upload Bank → Reconcile Settlement → Review Exceptions

The finance team spends more time investigating real differences and less time constructing Excel workbooks.

---

How Cointab helps reconcile Posist with Zomato and bank

Cointab can help restaurant finance teams:

• Upload Posist restaurant sales reports
• Upload Zomato order and settlement reports
• Map Posist stores with Zomato restaurant IDs
• Match Posist Order ID with Zomato Order ID
• Compare order amounts
• Compare discounts
• Compare packaging charges
• Retain order status
• Separate delivered and cancelled transactions
• Identify Posist orders missing from Zomato
• Identify Zomato orders missing from Posist
• Identify amount differences
• Review Zomato service fees
• Review PG charges
• Review logistics charges
• Retain GST-related settlement components
• Review TDS and TCS values
• Review compensation and recoupment
• Retain the Zomato final amount
• Group transactions into settlements
• Use Settlement Date and Bank UTR
• Upload the restaurant bank statement
• Match Zomato settlements with bank credits
• Identify settlements missing from the bank
• Identify unidentified bank credits
• Manually match genuine transactions or settlements where references differ
• Download the complete reconciliation working in Excel
• Upload corrected files and reconcile again

---

Automate Posist vs Zomato vs Bank reconciliation

If your restaurant uses Posist and receives orders through Zomato, Cointab can automate the complete three-way reconciliation.

The process becomes:

Posist Restaurant Sales

↓

Zomato Orders & Settlement Calculation

↓

Zomato Settlement

↓

Bank Receipt

You can identify:

• Orders that agree between Posist and Zomato
• Orders missing from either system
• Order-value differences
• Discount and packaging differences
• Cancelled-order exceptions
• Zomato service fees and other deductions
• PG and logistics charges
• TDS and TCS components
• Settlement adjustments
• Final amounts payable
• Settlements that successfully reached the bank
• Zomato settlements missing from the bank
• Unresolved bank credits

Instead of simply comparing Zomato sales with the amount received in the bank, the finance team gets a transaction-level explanation of the entire movement from restaurant order to final cash receipt.

If your restaurant currently reconciles Posist, Zomato settlements and bank statements manually in Excel, you can use Cointab to automate the complete process.

Try Cointab

For multi-outlet restaurant groups, high Zomato transaction volumes, customized Posist exports, or more complex marketplace settlement reconciliation requirements:

Book a Demo