If your restaurant uses Posist to record restaurant sales and receives online orders through Swiggy, your finance team needs to reconcile much more than the total sales reported by the two systems.

The complete financial flow is:

Posist Order → Swiggy Order Economics → Swiggy Net Payable → Bank Receipt

This creates a three-way reconciliation across:

Posist ↔ Swiggy ↔ Bank

The objective is to answer three distinct questions:

1. Does every Swiggy order recorded in Posist also exist in Swiggy's report?
2. Does Swiggy calculate the correct amount payable after discounts, commissions, cancellations, taxes, TCS and TDS?
3. Does the resulting Swiggy payout actually reach the restaurant's bank account?

Cointab can automate these checks and give the finance team a transaction-level view of where any difference originates.

---

Start with the restaurant order, not the bank receipt

A common reconciliation mistake is to compare total Swiggy sales from Posist directly with credits received in the bank.

Those numbers are not supposed to be identical.

A Posist order may begin with:

• Gross Amount
• Subtotal
• Discount
• Net Sale
• GST
• Packaging charges
• Tip

Swiggy then applies its own commercial and statutory calculations.

These may include:

• Restaurant trade discount
• Restaurant coupon discount
• Swiggy commission
• Service fee
• Lead generation fee
• Taxes on fees
• Cancellation sharing
• Refunds
• GST deduction
• TCS
• TDS

The resulting:

NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS

is much closer to what eventually contributes to the restaurant's payout.

The proper bridge is therefore:

Posist Sales → Swiggy Order Calculation → Swiggy Net Payable → Bank

---

What does the Posist report contain?

A Posist restaurant-sales report may contain information such as:

For Swiggy reconciliation, particularly useful fields include:

• Order Id
• Store Name
• Date
• Subtotal
• Discount
• Net Sale
• GST
• Packaging charges

---

What does the Swiggy report contain?

The Swiggy report provides both order-level and financial-settlement information.

A typical file can contain:

Order information

• ORDER_DATE
• RESTAURANT_ID
• RESTAURANT_NAME
• CITY
• CITY_NAME
• SERVICE_PERIOD_FROM
• SERVICE_PERIOD_TO
• ORDER_NO
• ORDER_STATUS
• ORDER_TYPE
• ORDER_COMMENT

Customer order economics

• ITEM_TOTAL
• PACKING_CHARGE
• SERVICE_CHARGE
• ORDERCGST
• ORDERSGST
• ORDERIGST
• GMV
• CUSTOMER_PAYABLE
• CASH_PAID

Discounts

• RESTAURANT_TRADE_DISCOUNT
• RESTCOUPONDISCOUNT

Swiggy commercial charges

• CALL_CENTER_SERVICE_FEE
• LEAD_GEN_FEE
• SWIGGY_COMMISSION
• SERVICE_FEE
• CGST_SERVICE_FEE
• SGST_SERVICE_FEE
• TOTAL_COMMISION_AND_TAXES
• FCP_COMMISSION
• COMMISSION_EXPRESSION

Cancellations and refunds

• BUYER_CANCELLATION_COST_SHARING
• REFUND_TO_CUSTOMER
• CANCELLATIONRESPONSIBLE

Statutory deductions

• GSTDEDUCTION
• TCS
• TDS

Final payable values

• NET_PAYABLE_AMOUNT_BEFORE_TCS_AND_GST
• NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS

This makes the Swiggy file the financial bridge between restaurant sales and bank settlement.

---

Reconciliation stage 1: Posist orders vs Swiggy orders

The first reconciliation is:

Posist Order Id ↔ Swiggy ORDER_NO

For example:

Posist

Order Id:

SWG-784521

Store:

Restaurant - Koramangala

Net Sale:

₹1,250

Swiggy

ORDER_NO:

SWG-784521

RESTAURANT_NAME:

Restaurant - Koramangala

Relevant order value:

₹1,250

Cointab can identify that both rows belong to the same restaurant order.

The financial components can then be validated.

---

Fully Matched Swiggy orders

An order can be classified as Fully Matched when:

• The same order exists in Posist and Swiggy
• The configured comparable amount fields agree

For example:

Posist

Order ID:

SWG-65218

Subtotal:

₹900

Packaging:

₹50

Swiggy

ORDER_NO:

SWG-65218

ITEM_TOTAL:

₹900

PACKING_CHARGE:

₹50

The comparable order economics agree.

Cointab can report:

Fully Matched

---

Partially Matched Swiggy orders

Suppose both systems contain:

SWG-98521

but the values differ.

Posist

Relevant order amount:

₹1,400

Swiggy

Comparable order value:

₹1,350

The order reference establishes the relationship.

Cointab can classify it as:

Partially Matched

The finance team can then investigate the ₹50 difference rather than searching manually for whether the order exists.

---

Posist order missing from Swiggy

Suppose Posist records:

Order ID: SWG-84215

Store: Indiranagar

Amount: ₹1,180

but the Swiggy report has no corresponding ORDER_NO.

Cointab can report:

Present in Posist but not in Swiggy

Possible causes include:

• Wrong marketplace source recorded in Posist
• Order belongs to another Swiggy reporting period
• Order number was captured incorrectly
• Source file is incomplete
• Order was handled differently due to cancellation or another event

---

Swiggy delivered order missing from Posist

The reverse case can be more operationally significant.

Suppose Swiggy reports:

ORDER_NO: SWG-75214

ORDER_STATUS: Delivered

but there is no corresponding Posist order.

The restaurant can investigate whether:

• Swiggy order failed to reach Posist
• POS integration failed
• Order was handled manually
• Order was recorded under another reference
• Outlet mapping is incorrect

This reconciliation therefore controls both finance and POS integration completeness.

---

Map Posist stores to Swiggy restaurant IDs

A restaurant group may have many outlets.

Posist identifies them through:

Store Name

Swiggy provides:

• RESTAURANT_ID
• RESTAURANT_NAME

The reconciliation can preserve a mapping such as:

This helps ensure that transactions are compared within the correct outlet.

---

Store-level reconciliation can reveal local problems

Suppose most restaurants reconcile almost completely, but one outlet has many missing Swiggy orders.

The issue may be related to that location's:

• Posist integration
• Store configuration
• Swiggy restaurant mapping
• Local order handling

The reconciliation can therefore be reviewed by:

• Restaurant
• City
• Store
• Service period

rather than only as one consolidated total.

---

Posist Subtotal vs Swiggy ITEM_TOTAL

One useful component-level comparison is:

Posist Subtotal ↔ Swiggy ITEM_TOTAL

For example:

Posist

Subtotal:

₹800

Swiggy

ITEM_TOTAL:

₹800

This confirms that both systems agree on the underlying food-item value before additional charges and adjustments.

If the order IDs match but these amounts differ, the finance team can investigate:

• Item-level pricing
• Missing item
• Discount treatment
• Order modification

---

Packaging charges should be compared separately

Posist can contain several packaging-charge fields.

Swiggy provides:

PACKING_CHARGE

Instead of allowing packaging differences to disappear inside the total order value, the reconciliation can validate this component separately.

For example:

Posist

Total applicable packaging:

₹40

Swiggy

PACKING_CHARGE:

₹40

The packaging component agrees.

---

Restaurant discounts need to be separated from platform deductions

Posist may show a general:

Discount

Swiggy separately provides:

• RESTAURANT_TRADE_DISCOUNT
• RESTCOUPONDISCOUNT

These are important because restaurant-funded discounts directly affect the economics of the order.

For example:

Posist

Subtotal:

₹1,000

Discount:

₹100

Net Sale:

₹900

Swiggy

ITEM_TOTAL:

₹1,000

Restaurant-funded discount:

₹100

The order can still reconcile correctly.

The ₹100 difference from gross value is explained by the discount rather than representing a missing settlement amount.

---

CUSTOMER_PAYABLE is not the same as restaurant payable

Swiggy provides:

CUSTOMER_PAYABLE

This represents what the customer is required to pay under Swiggy's order calculation.

It should not automatically be treated as the amount that Swiggy owes the restaurant.

After the order, the restaurant's payable amount can still be affected by:

• Swiggy commission
• Service fees
• Taxes
• TCS
• TDS
• Cancellations
• Refunds
• Other adjustments

This distinction is important.

---

CASH_PAID can affect how the order is settled

The Swiggy report also contains:

CASH_PAID

This can be useful for understanding orders where part or all of the customer collection was handled in cash.

Those orders may behave differently from fully online-paid transactions when determining what Swiggy needs to settle to the restaurant.

The field should therefore remain available when reviewing unusual settlement differences.

---

ORDER_STATUS changes the expected financial treatment

Swiggy provides:

ORDER_STATUS

Not every order should be reconciled using identical settlement expectations.

For example:

Delivered order

Usually proceeds through the normal order-to-payout calculation.

Cancelled order

May involve:

• Refund
• Cancellation cost sharing
• Restaurant compensation
• Different net payable

Keeping Order Status attached to the reconciliation is therefore important.

---

Cancellation responsibility provides important context

Swiggy additionally provides:

CANCELLATIONRESPONSIBLE

This can help explain why two cancelled orders receive different financial treatment.

A cancellation attributed to:

• Restaurant
• Customer
• Platform / delivery process

may not have the same settlement impact.

This field is useful during exception investigation even if it is not used for primary matching.

---

Buyer cancellation cost sharing can create a positive adjustment

The Swiggy report contains:

BUYER_CANCELLATION_COST_SHARING

This can represent an amount associated with cancellation treatment.

Suppose an order is cancelled after the restaurant has already incurred some cost.

The resulting restaurant entitlement may not be zero.

Keeping this component visible helps explain why a cancelled order still contributes to the payable amount.

---

Refund to customer affects the order economics

Swiggy also provides:

REFUND_TO_CUSTOMER

This can reduce the amount ultimately attributable to the restaurant.

A reconciliation should therefore not force:

Posist Order Amount = Swiggy Final Payable

for an order where the customer received a refund.

The refund component needs to be considered in the financial bridge.

---

Reconciliation stage 2: explain Swiggy's net payable

Once Posist and Swiggy agree on the underlying order, the next question is:

How did Swiggy calculate the amount eventually payable to the restaurant?

This is where the Swiggy report becomes especially valuable.

The finance team can move through a waterfall such as:

Order economics

↓

Restaurant-funded discounts

↓

Swiggy fees and commission

↓

Cancellation / refund adjustments

↓

Taxes and statutory deductions

↓

Net payable

---

Swiggy commission should remain visible

Swiggy provides:

SWIGGY_COMMISSION

This is one of the major commercial deductions from restaurant sales.

Instead of treating:

Posist Sales - Bank Receipt

as one unexplained variance, the reconciliation can retain the commission for every order.

This lets the finance team determine how much of the difference is expected commercial cost.

---

Service fee is another separate deduction

The report also provides:

SERVICE_FEE

This may be separate from the primary Swiggy commission.

The finance team can therefore validate:

• Commission
• Service fee

independently instead of combining all marketplace deductions into one amount.

---

Lead generation fee should not disappear inside the settlement difference

Swiggy also provides:

LEAD_GEN_FEE

Where applicable, this contributes to the difference between order value and final restaurant payout.

Retaining it as a distinct component makes the reconciliation easier to explain.

---

Call center service fee can create another adjustment

The report includes:

CALL_CENTER_SERVICE_FEE

Again, this may not apply to every order.

Where populated, it can help explain an otherwise unexpected difference between restaurant sales and the net amount payable.

---

FCP commission can be retained for applicable transactions

Swiggy's report also contains:

FCP_COMMISSION

along with:

COMMISSION_EXPRESSION

Where relevant, these fields can provide additional detail around how commission was calculated.

The finance team can retain them for review without needing them to drive the original order match.

---

Taxes on Swiggy service fees should be visible separately

Swiggy provides:

• CGST_SERVICE_FEE
• SGST_SERVICE_FEE

and a consolidated:

TOTAL_COMMISION_AND_TAXES

These fields help explain the total deduction associated with Swiggy's service charges.

The reconciliation can therefore show:

Commercial fee + tax on fee

rather than treating the full deduction as commission alone.

---

Validate TOTAL_COMMISION_AND_TAXES

One useful control is to compare the underlying fee and tax components against:

TOTAL_COMMISION_AND_TAXES

where appropriate.

For example, finance can review whether the reported total is consistent with the individual:

• Commission
• Service fee
• CGST
• SGST

components contained in the source data.

This gives the restaurant a more detailed fee-control view.

---

NET_PAYABLE_AMOUNT_BEFORE_TCS_AND_GST creates a useful checkpoint

Swiggy provides:

NET_PAYABLE_AMOUNT_BEFORE_TCS_AND_GST

This is particularly useful because it gives the finance team an intermediate financial checkpoint.

The restaurant can understand the order economics:

before

the final statutory deductions are applied.

This makes it easier to separate:

• Marketplace commercial deductions

from:

• Statutory tax-related deductions

---

GSTDEDUCTION should be retained independently

Swiggy provides:

GSTDEDUCTION

This can affect the amount eventually paid to the restaurant.

It should remain visible in the reconciliation rather than being combined into one overall settlement difference.

The restaurant's finance or tax team can then review the accounting treatment separately.

---

TCS creates another settlement difference

The Swiggy report provides:

TCS

This may contribute to the difference between:

Order economics

and:

Cash received

The reconciliation should preserve the source TCS amount so finance can understand the settlement bridge.

---

TDS also reduces immediate cash payable

Likewise, Swiggy provides:

TDS

Suppose an order population contributes:

₹10,00,000

before final statutory deductions.

Swiggy then deducts the applicable:

• TCS
• TDS
• Other reported tax deduction

The eventual payable can be lower.

This difference does not automatically represent missing cash.

---

NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS is the key payout measure

One of the most useful fields in the entire Swiggy report is:

NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS

This represents the order-level amount after the reported financial deductions have been applied.

Conceptually:

Posist / Swiggy Order Value

↓

Discounts

↓

Swiggy Commercial Charges

↓

Cancellation / Refund Adjustments

↓

Tax and Statutory Deductions

↓

NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS

This order-level amount can then contribute to the relevant Swiggy settlement or service-period payout.

---

Example: explain a ₹1,000 Posist order

Suppose Posist reports an order with:

Net Sale: ₹1,000

Swiggy identifies the same order.

After the applicable:

• Restaurant discount
• Commission
• Service fee
• Taxes
• TDS / TCS

Swiggy reports:

NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS: ₹720

The ₹280 difference is not automatically an error.

The reconciliation can show exactly which reported Swiggy components explain it.

The finance team only needs to investigate unexplained or unexpected differences.

---

Order-level reconciliation is different from payout reconciliation

At this stage, the restaurant may have completely reconciled every individual order.

But that still does not prove the money has reached the bank.

The next reconciliation is:

Swiggy Net Payable / Settlement Population ↔ Bank

---

Swiggy service periods can help organize payout populations

The supplied Swiggy report contains:

• SERVICE_PERIOD_FROM
• SERVICE_PERIOD_TO

These fields can help group transactions belonging to a common reporting or payout period.

For example:

Service Period: 1 August – 7 August

may contain hundreds of Swiggy orders.

The finance team can aggregate:

NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS

for the relevant population and compare that result with the corresponding bank receipt or payout information.

The exact grouping should follow the restaurant's actual Swiggy settlement process.

---

Do not match individual Swiggy orders directly to bank credits

This is critical.

The Swiggy file contains order-level rows.

The bank normally receives aggregated payouts.

Therefore:

One Swiggy Order ≠ One Bank Credit

Instead:

Many Swiggy Orders / Adjustments → One Settlement or Payout → Bank Credit

For example:

750 orders may collectively produce a net payable of:

₹6,42,500

The bank may receive one Swiggy credit of:

₹6,42,500

The reconciliation should compare the appropriate aggregated Swiggy population against that bank receipt.

---

What does the bank statement contain?

The restaurant bank statement may contain:

Useful fields for Swiggy payout reconciliation include:

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

---

The supplied Swiggy report does not contain a bank UTR

Unlike some settlement reports, the Swiggy format described here does not contain a dedicated:

Bank UTR

or explicit settlement reference.

The bank leg therefore needs to follow the actual settlement information available to the restaurant.

For example, reconciliation may use combinations of:

• Service period
• Expected payout amount
• Bank transaction date
• Bank narration
• Swiggy-related bank description

Where a separate Swiggy settlement or remittance report containing a reference is available, that reference can also strengthen the bank match.

Cointab does not need to assume a field that is absent from the source data.

---

Example: aggregate Swiggy net payable vs bank receipt

Suppose all relevant Swiggy transactions for a payout population produce:

Sum of NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS:

₹5,82,400

The bank statement contains:

Description: SWIGGY SETTLEMENT

Credit: ₹5,82,400

The amount and expected settlement timing agree.

The payout can be reconciled with the bank.

---

Swiggy expected payout missing from the bank

Suppose the relevant order population produces:

Expected payout: ₹7,25,000

but no corresponding Swiggy credit can be found in the bank statement within the expected settlement window.

This becomes:

Swiggy payout not found in bank

The finance team can investigate:

• Settlement timing
• Bank account used
• Missing bank-statement period
• Swiggy payout delay
• Adjustment carried into another payout
• Incorrect grouping of source transactions

This issue is separate from whether the individual orders matched Posist.

---

Bank credit found but Swiggy payout population is unclear

The opposite can also happen.

The bank contains:

Description: SWIGGY

Credit: ₹4,96,800

but the finance team has not yet identified which order/service-period population generated it.

This can be kept as a bank-side exception while the team investigates:

• Relevant Swiggy period
• Payout grouping
• Other Swiggy entity
• Older adjustments
• Different restaurant population

---

Service-period grouping should not be assumed blindly

Although Swiggy provides:

• SERVICE_PERIOD_FROM
• SERVICE_PERIOD_TO

the exact bank payout structure should follow the restaurant's actual settlement arrangement.

A service period may:

• Correspond directly to a payout
• Form part of a larger payout
• Contain adjustments from another period

The reconciliation should therefore validate the relationship from actual data rather than assume:

One service period = one bank credit

in every case.

---

A useful 3-way status model

The complete reconciliation can be viewed as:

This tells the finance team which layer needs investigation.

---

Example: complete Posist to bank flow

Consider one Swiggy order.

Posist

Order Id:

SWG-45218

Net Sale:

₹1,250

Swiggy

ORDER_NO:

SWG-45218

Order economics agree.

After commission, taxes and other applicable deductions:

NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS:

₹910

That ₹910 is combined with many other order-level payables.

The relevant Swiggy payout population totals:

₹4,85,600

The bank subsequently records:

SWIGGY credit: ₹4,85,600

The complete chain is:

Posist Order ✓ → Swiggy Order ✓ → Swiggy Payable ✓ → Bank ✓

---

Example: order matches but commission creates an exception

Posist

Order:

SWG-65241

Relevant sale:

₹1,000

Swiggy

Order value agrees.

But the reported commission or related fee differs from what the restaurant expects.

The order itself is:

Matched

The financial exception belongs specifically to:

Swiggy deduction calculation

This distinction prevents the order from being incorrectly categorized as missing.

---

Example: cancelled order explains the payout difference

Posist

Order:

SWG-78421

Value:

₹1,200

Swiggy

ORDER_STATUS:

Cancelled

BUYER_CANCELLATION_COST_SHARING:

Populated

REFUND_TO_CUSTOMER:

Populated

The Swiggy payable will not follow the standard delivered-order logic.

The cancellation information explains why the amount differs.

---

Example: TDS and TCS explain lower cash settlement

Suppose a population has:

Net Payable Before Final Deductions: ₹5,00,000

Swiggy reports applicable:

• GST deduction
• TCS
• TDS

and the resulting:

NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS

is:

₹4,86,000

A bank receipt near ₹4,86,000 is not automatically short by ₹14,000.

The deductions explain the bridge.

---

Example: all orders reconcile but payout is missing

Suppose:

• Every Posist order is matched to Swiggy
• Order amounts agree
• Swiggy fee calculations are understood
• Expected payout = ₹6,25,000

but the bank has no corresponding credit.

This is a pure:

Swiggy → Bank reconciliation exception

The restaurant does not need to reopen the entire Posist order population.

---

Distinguish reconciliation errors from commercial deductions

This is a key reason to reconcile order economics in detail.

A difference between:

Posist Net Sale

and:

Swiggy Net Payable

may be completely expected because of:

• Restaurant discount
• Commission
• Service fee
• Tax
• TDS
• TCS
• Cancellation adjustment

A genuine reconciliation exception exists when:

• Source transactions are missing
• Comparable order values disagree
• An expected deduction appears incorrect
• Net payable cannot be explained
• Expected payout is not received

---

Manual Match for order references that differ

Some valid restaurant transactions may still have inconsistent references.

For example:

Posist

Order ID:

SWG-784521-A

Swiggy

ORDER_NO:

784521

The restaurant team knows from:

• Store
• Date
• Bill
• Amount

that both rows represent the same order.

Cointab provides:

Manual Match

The user can select the corresponding records and confirm the relationship.

---

Manual Match can also help with bank payouts

Where the bank narration is abbreviated and the Swiggy source file has no direct settlement UTR, the finance team may independently know that:

Swiggy payout population ₹5,42,800

corresponds to:

Bank credit ₹5,42,800

If the automatic relationship cannot be established confidently, the payout and bank record can be reviewed and manually matched.

---

Analyze exceptions by restaurant and city

Swiggy provides:

• RESTAURANT_ID
• RESTAURANT_NAME
• CITY
• CITY_NAME

This allows the restaurant group to identify whether exceptions are concentrated in a particular location.

For example:

Outlet B may deserve specific investigation.

---

Analyze exceptions by service period

The Swiggy fields:

• SERVICE_PERIOD_FROM
• SERVICE_PERIOD_TO

also make it possible to understand whether a particular reporting or payout period contains unusual differences.

For example:

• Most weeks reconcile normally
• One service period contains a large number of missing orders
• One period contains an unusual deduction amount
• One expected payout is not visible in the bank

This can make investigation much more focused.

---

Use the reconciliation to create three worklists

Instead of one generic "Swiggy difference" sheet, the finance team can work from three distinct exception populations.

Order exceptions

Examples:

• Posist order missing from Swiggy
• Swiggy order missing from Posist
• Order amount differs
• Store mapping issue
• Cancellation discrepancy

Swiggy calculation exceptions

Examples:

• Discount difference
• Unexpected commission
• Service-fee issue
• Cancellation adjustment
• TDS/TCS or GST deduction requiring review
• Unexplained net payable

Bank exceptions

Examples:

• Expected Swiggy payout missing
• Bank credit not tied to a Swiggy payout population
• Amount mismatch
• Timing difference

This makes responsibility much clearer.

---

Download the complete Posist vs Swiggy vs Bank reconciliation in Excel

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

The output can retain Posist fields such as:

• Order ID
• Store Name
• Bill Number
• Subtotal
• Discount
• Net Sale
• GST
• Packaging charges

alongside Swiggy fields such as:

• ORDER_NO
• RESTAURANT_ID
• ORDER_STATUS
• ITEM_TOTAL
• PACKING_CHARGE
• GMV
• RESTAURANT_TRADE_DISCOUNT
• RESTCOUPONDISCOUNT
• SWIGGY_COMMISSION
• SERVICE_FEE
• TOTAL_COMMISION_AND_TAXES
• BUYER_CANCELLATION_COST_SHARING
• REFUND_TO_CUSTOMER
• GSTDEDUCTION
• TCS
• TDS
• NET_PAYABLE_AMOUNT_BEFORE_TCS_AND_GST
• NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS
• SERVICE_PERIOD_FROM
• SERVICE_PERIOD_TO

and bank fields such as:

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

This provides a complete order-to-payout audit trail.

---

Use the reconciliation for restaurant month-end close

At month end, finance may want to confirm:

• Posist Swiggy sales
• Swiggy delivered orders
• Cancelled orders
• Restaurant-funded discounts
• Swiggy commission
• Service fees
• Taxes on commission
• Refunds
• Cancellation adjustments
• GST deductions
• TCS
• TDS
• Net payable
• Amount received in bank
• Remaining exceptions

A three-way reconciliation provides transaction-level evidence underneath these totals.

---

Why this reconciliation is different from a simple marketplace settlement check

A simple settlement check asks:

How much did Swiggy pay us?

A complete reconciliation asks:

1. Did Swiggy receive every order recorded in Posist?
2. Did both systems agree on the order economics?
3. Were Swiggy's deductions and adjustments explainable?
4. What was the final net payable?
5. Did that payable ultimately reach the bank?

That provides a much stronger financial control over marketplace revenue.

---

Run Posist vs Swiggy reconciliation regularly

For a high-volume restaurant group, the process can be repeated for each reporting period.

A typical workflow is:

1. Export the Posist sales report.
2. Obtain the Swiggy order and financial report.
3. Upload the Posist file into Cointab.
4. Configure Order ID, Store, date and relevant sales fields.
5. Upload the Swiggy file.
6. Configure ORDER_NO, RESTAURANT_ID and relevant amount fields.
7. Run Posist vs Swiggy order reconciliation.
8. Review Fully Matched orders.
9. Investigate order-value differences.
10. Review Posist-only orders.
11. Review Swiggy-only orders.
12. Separate delivered and cancelled orders.
13. Review restaurant discounts.
14. Review Swiggy commission and service fees.
15. Review cancellation and refund adjustments.
16. Review GST deduction, TCS and TDS.
17. Validate NET_PAYABLE_AMOUNT_AFTER_ALL_DEDUCTIONS.
18. Group the relevant Swiggy net-payable population according to the actual payout process.
19. Upload the bank statement.
20. Reconcile expected Swiggy payouts with bank credits.
21. Review missing or unexplained bank items.
22. Complete Manual Matches where required.
23. Download the complete reconciliation working.
24. Correct or follow up on exceptions.
25. Upload revised data and rerun where required.

---

Timing differences can remain open across periods

The different stages do not always complete on the same day.

For example:

Sunday

Posist and Swiggy both contain the delivered order.

The order is fully reconciled.

Following settlement cycle

Swiggy includes the order in the relevant payout population.

Later bank date

The corresponding Swiggy credit appears in the bank statement.

The reconciliation can therefore keep different layers open until their respective transaction lifecycle is complete.

---

Move from Swiggy Excel reconciliation to exception management

A manual process may require the restaurant finance team to:

• Export Posist
• Download Swiggy reports
• Match Order IDs
• Map restaurant IDs
• Compare order values
• Review discounts
• Review cancellations
• Calculate commission
• Review service fees
• Check GST deductions
• Check TCS and TDS
• Calculate net payable
• Aggregate settlement periods
• Search bank statements
• Carry unresolved differences forward

Cointab changes the process to:

Upload Posist → Reconcile Swiggy Orders → Validate Order Economics → Determine Net Payable → Reconcile Bank → Review Exceptions

The finance team can focus on actual discrepancies rather than rebuilding the same Excel workbook every period.

---

How Cointab helps reconcile Posist with Swiggy and bank

Cointab can help restaurant finance teams:

• Upload Posist restaurant sales reports
• Upload Swiggy order and payout reports
• Match Posist Order ID with Swiggy ORDER_NO
• Map Posist stores to Swiggy restaurant IDs
• Compare item totals
• Compare packaging charges
• Review restaurant-funded discounts
• Separate delivered and cancelled orders
• Identify Posist orders missing from Swiggy
• Identify Swiggy orders missing from Posist
• Identify order amount differences
• Retain Swiggy commission
• Retain service fees
• Retain commission taxes
• Review cancellation cost sharing
• Review customer refunds
• Review GST deductions
• Review TCS and TDS
• Validate net payable before and after deductions
• Group transactions according to the actual Swiggy payout structure
• Upload bank statements
• Compare expected Swiggy payouts against bank credits
• Identify expected payouts missing from the bank
• Identify bank credits that still need explanation
• Manually match genuine orders or payouts where references differ
• Download the complete reconciliation working in Excel
• Upload corrected data and rerun the reconciliation

---

Automate Posist vs Swiggy vs Bank reconciliation

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

The workflow becomes:

Posist Restaurant Sales

↓

Swiggy Order Reconciliation

↓

Swiggy Commission, Discounts, Cancellations & Tax Deductions

↓

Swiggy Net Payable

↓

Bank Receipt

You can identify:

• Orders that agree between Posist and Swiggy
• Orders missing from either system
• Item or order-value differences
• Restaurant discount differences
• Cancelled-order adjustments
• Swiggy commissions and service fees
• GST-related deductions
• TCS and TDS
• Refunds and cancellation-sharing amounts
• Final net payable after all deductions
• Expected Swiggy payouts received in the bank
• Swiggy payouts that remain unverified
• Bank credits requiring further investigation

Instead of comparing restaurant sales directly with bank receipts, your finance team receives a complete explanation of how each Swiggy order turns into the final cash received by the restaurant.

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

Try Cointab

For multi-outlet restaurant groups, high Swiggy order volumes, customized Posist exports, or more complex marketplace payout reconciliation requirements:

Book a Demo