If your company supplies products to Swiggy Instamart and maintains the customer account in Microsoft Dynamics NAV or Dynamics 365 Business Central, your finance team may need to periodically reconcile the Instamart receivable ledger in Dynamics with the transaction file received from Swiggy.

This reconciliation is particularly useful because the two systems provide different views of the same transaction.

Your Microsoft Dynamics customer ledger tells you:

• What you invoiced
• What remains outstanding
• Whether an entry is still open
• How receipts and adjustments have been applied
• Whether TDS-related items remain unresolved

The Swiggy Instamart ledger can tell you:

• Whether the invoice exists in Swiggy's records
• Which PO relates to it
• Whether a GRN is available
• What payment status Swiggy shows
• How much has been paid
• Which payment reference was used
• Whether withholding tax was recorded
• Whether a vendor credit exists

The reconciliation therefore becomes:

Microsoft Dynamics NAV / Business Central Receivables ↔ Swiggy Instamart Invoice and Payment Records

Rather than merely comparing closing balances, Cointab can help determine the status of each underlying transaction.

---

What are you trying to answer in a Swiggy Instamart reconciliation?

The most useful question is usually not:

"Does our Swiggy balance equal their balance?"

It is:

"Why is this particular Instamart invoice still open in Microsoft Dynamics?"

For every open Dynamics transaction, you may want to know:

• Does Swiggy have the invoice?
• Does the invoice amount agree?
• Is there a PO?
• Is there a GRN?
• Does Swiggy show the invoice as paid?
• Is it only partially paid?
• Is withholding tax creating part of the open balance?
• Has Swiggy recorded a vendor credit?
• Is the payment available but not applied in Dynamics?

This creates a much more useful reconciliation than simply comparing one total against another.

---

Your Microsoft Dynamics NAV / Business Central ledger

A Microsoft Dynamics customer ledger used for Swiggy Instamart reconciliation may contain fields such as:

Your full Dynamics export may contain many more fields relating to:

• GST
• Locations
• Branches
• Profit centres
• TDS certificates
• Customer applications
• HSN/SAC

Not every column needs to participate in matching.

The important fields can be configured for reconciliation while the rest remain available when an exception requires investigation.

---

What does the Swiggy Instamart ledger contain?

The Swiggy Instamart file can contain:

The file therefore provides both accounting and operational context around the invoice.

That makes it possible to investigate why a transaction remains open rather than merely identifying that it is open.

---

The key comparison: Dynamics open item vs Swiggy payment status

This reconciliation becomes particularly useful when you compare:

Microsoft Dynamics

• Original transaction amount
• Remaining Amount
• Open status

with:

Swiggy Instamart

• Amount
• Payment Status
• Paid Amount
• Withhold Tax Amount

For example:

Dynamics

Invoice: INV-48215
Amount: ₹4,00,000
Remaining Amount: ₹4,00,000
Open: Yes

Swiggy Instamart

Invoice Number: INV-48215
Amount: ₹4,00,000
Payment Status: Paid
Paid Amount: ₹4,00,000

The invoice itself agrees perfectly.

But the accounting status does not.

Swiggy says the invoice has been paid while Dynamics still shows the full amount open.

That tells your finance team exactly where to investigate:

• Customer receipt
• Bank entry
• Payment reference
• Application against the invoice
• Incorrect customer allocation

This is more useful than treating the invoice simply as "matched."

---

How to reconcile Microsoft Dynamics with Swiggy Instamart in Cointab

Start a new reconciliation in Cointab and select:

Customer Reconciliation

For this workflow:

• Side 1 = Your Microsoft Dynamics NAV / Business Central Swiggy Instamart customer ledger
• Side 2 = Swiggy Instamart ledger

The process becomes:

Upload Dynamics → Upload Instamart → Configure Identifiers and Amounts → Run Reconciliation → Investigate Open Items

---

Step 1: Upload your Microsoft Dynamics customer ledger

Export the Swiggy Instamart customer account from Dynamics NAV / Business Central.

Upload it into Cointab.

Choose the relevant date

Depending on your process, you can use:

• Posting Date
• Document Date

Select transaction identifiers

Useful Dynamics identifiers may include:

• External Document No.
• Document No.
• Narration
• Description
• Party DN Nos / SB Invoice Nos.
• Custom Apply-to Doc.

Configure the amount

Use the appropriate transaction amount from your Dynamics export.

Fields such as:

• Remaining Amount
• Remaining Amt. (LCY)
• Open

can remain available for exception analysis.

---

Step 2: Upload the Swiggy Instamart ledger

Upload the file received from Swiggy Instamart.

Useful identifiers may include:

• Invoice Number
• Reference Number
• Document Identifier
• Document Number
• Payment Reference Number
• Payment Number
• Vendor Credit Number
• PO Number
• GRN Number
• Description

The primary financial field is:

Amount

while:

• Paid Amount
• Withhold Tax Amount

provide additional settlement information.

---

Match Dynamics External Document No. with Swiggy Invoice Number

One of the clearest invoice relationships may be:

Dynamics External Document No. ↔ Swiggy Invoice Number

For example:

Microsoft Dynamics

External Document No.:

INV-78521

Amount:

₹2,60,000

Swiggy Instamart

Invoice Number:

INV-78521

Amount:

₹2,60,000

The internal accounting numbers in the two systems may be completely different.

The invoice itself provides the common commercial reference.

Cointab can classify the transaction as:

Fully Matched

when both the invoice and amount agree.

---

Do not try to match Dynamics Document No. with Swiggy Document Number

Your Dynamics transaction may contain:

Document No.:

SI-0098452

Swiggy may record:

Document Number:

5100874521

These are internal identifiers generated independently by each system.

They do not need to match.

The same transaction may instead be connected through:

• External Document No.
• Invoice Number
• Reference Number
• Narration
• Description

This is why customer reconciliation should identify the common commercial transaction rather than compare internal ERP document numbers mechanically.

---

Fully Matched Swiggy Instamart invoices

Suppose:

Microsoft Dynamics

External Document No.:

INV-56218

Amount:

₹1,90,000

Swiggy Instamart

Invoice Number:

INV-56218

Amount:

₹1,90,000

The invoice and amount agree.

Cointab reports:

Fully Matched

You can then move to a second question:

Has the invoice also been settled correctly?

The Swiggy fields:

• Payment Status
• Paid Amount

and Dynamics:

• Remaining Amount
• Open

help answer that question.

---

Partially Matched Instamart invoices

Suppose:

Dynamics

External Document No.:

INV-65421

Amount:

₹3,20,000

Swiggy Instamart

Invoice Number:

INV-65421

Amount:

₹3,12,000

The invoice clearly exists in both datasets.

But the amount differs by:

₹8,000

Cointab reports:

Partially Matched

The finance team can investigate whether the difference relates to:

• Incorrect invoice value
• Credit
• Deduction
• Return
• Withholding
• Other accounting adjustment

---

Dynamics invoice exists but Swiggy cannot be found

Suppose Microsoft Dynamics contains:

External Document No.: INV-78425

Amount: ₹2,75,000

but Cointab cannot identify the corresponding Swiggy Instamart transaction.

The item is:

Present in Microsoft Dynamics but not in Swiggy Instamart

This creates a useful investigation path.

Check:

• PO Number
• GRN status
• Invoice submission
• Reference formatting
• Customer processing period

The exception may originate before payment is even relevant.

---

Swiggy transaction exists but Dynamics does not

The reverse situation can also occur.

Swiggy Instamart may contain:

Vendor Credit Number: VCN-84521

Amount: ₹35,000

but no corresponding Dynamics entry can be identified.

Cointab reports:

Present in Swiggy Instamart but not in Microsoft Dynamics

Your finance team can investigate whether:

• Credit note needs to be recorded
• Customer deduction is missing
• Adjustment exists under another reference
• Swiggy's entry requires clarification

This provides a specific internal action item.

---

Use PO Number when an invoice cannot be found cleanly

The Swiggy Instamart ledger contains:

PO Number

This can provide valuable context when invoice references do not line up cleanly.

Suppose your Dynamics entry contains the Swiggy PO reference inside:

Narration

while Swiggy has it in a dedicated:

PO Number

field.

The common PO can help establish that both transactions relate to the same underlying supply.

This is especially useful when:

• Invoice numbering differs
• Invoice reference is incomplete
• Several invoices have similar values
• The transaction needs operational investigation

---

GRN Number helps distinguish accounting issues from receipt issues

Swiggy Instamart also provides:

• GRN Number
• GRN Date

This gives the finance team an additional diagnostic layer.

The commercial process can look like:

PO → Supply → GRN → Invoice → Payment

Suppose an invoice is present in Dynamics but cannot be found as an accepted Swiggy transaction.

The finance team can check whether:

• GRN exists
• GRN was created later
• Goods receipt is still pending
• Invoice processing is waiting on receipt confirmation

The reconciliation therefore helps determine whether an open receivable is:

• An accounting mismatch
• A timing difference
• A procurement/receipt-stage issue
• A payment-stage issue

---

A GRN does not automatically mean the invoice is paid

It is important to separate the different stages.

A Swiggy transaction may have:

PO Number: Available
GRN Number: Available
Invoice Number: Available
Payment Status: Pending

This tells you that the commercial and accounting process has progressed significantly.

But payment remains outstanding.

The issue is no longer:

"Has Swiggy received or recognized this supply?"

It is now:

"When will the accepted invoice be settled?"

That distinction makes the customer reconciliation more actionable.

---

Compare Dynamics Remaining Amount with Swiggy Paid Amount

One of the most useful controls in this reconciliation is:

Dynamics Remaining Amount ↔ Swiggy Paid Amount

For example:

Original invoice

₹5,00,000

Dynamics

Remaining Amount:

₹2,00,000

Swiggy Instamart

Paid Amount:

₹3,00,000

This is internally consistent with a partially settled invoice.

The reconciliation can therefore establish:

• Invoice exists
• Invoice value agrees
• ₹3,00,000 has been paid
• ₹2,00,000 remains open

The invoice itself does not have a reconciliation discrepancy.

It simply remains partially outstanding.

---

When Swiggy says Paid but Dynamics still shows Remaining Amount

Consider:

Swiggy Instamart

Payment Status:

Paid

Paid Amount:

₹2,50,000

Microsoft Dynamics

Remaining Amount:

₹2,50,000

Open:

Yes

This is an important exception.

Possible explanations include:

• Payment received but not booked
• Receipt sitting unidentified in the bank
• Payment booked against another customer
• Receipt recorded but not applied to the invoice
• Payment reference differs

This type of exception can be more important than an invoice-number mismatch because the cash may already have moved.

---

Payment Reference Number can help locate the receipt

Swiggy provides:

Payment Reference Number

Your Dynamics transaction data may contain the same reference in:

• Narration
• Description
• Custom Apply-to Doc.
• Another receipt-related field

For example:

Swiggy Instamart

Payment Reference Number:

UTR874521963

Dynamics Narration

Swiggy receipt UTR874521963

The shared payment reference helps connect the customer-side payment to your receipt.

This can be especially useful when an invoice remains open because the receipt has not been applied correctly.

---

Payment Number provides another Swiggy settlement identifier

Swiggy also provides:

Payment Number

This may be different from:

• Payment Reference Number
• Document Number
• Invoice Number

When investigating a payment exception, keeping these different identifiers available can help trace the transaction through the customer's records.

Cointab allows such supporting fields to remain visible during exception review even if they are not all primary matching keys.

---

One Swiggy payment may cover multiple Dynamics invoices

Swiggy may settle several supplier invoices together.

For example:

• INV-101 — ₹1,00,000
• INV-102 — ₹1,50,000
• INV-103 — ₹2,00,000

could form one payment of:

₹4,50,000

Your Dynamics ledger may therefore contain:

One receipt

that needs to be applied against:

Three invoices

This means payment reconciliation can involve:

Multiple invoices ↔ One customer payment

rather than a simple one-to-one match.

The invoice reconciliation and payment allocation should therefore be considered separately.

---

Withhold Tax Amount can explain part of an open balance

The Swiggy Instamart file contains:

Withhold Tax Amount

Your Dynamics ledger also contains TDS-related information.

This provides a useful cross-check.

For example:

Invoice value

₹1,00,000

Swiggy Paid Amount

₹98,000

Withhold Tax Amount

₹2,000

The ₹2,000 difference does not necessarily represent an unpaid invoice amount.

It may represent withholding.

Your Dynamics ledger may need to reflect the corresponding TDS treatment before the invoice becomes fully settled.

---

Dynamics TDS and Swiggy withholding can be investigated together

Your Dynamics data may contain information such as:

• Certificate No.
• TDS Certificate Rcpt Date
• TDS Section Code
• Certificate Received

Swiggy provides:

Withhold Tax Amount

The primary reconciliation may establish that the invoice itself agrees.

The TDS-related fields can then help explain why:

• Paid Amount is lower
• Remaining Amount still exists
• Invoice remains Open

This provides a useful bridge between customer reconciliation and TDS accounting.

---

Vendor Credit Number can explain unexplained reductions

Swiggy Instamart includes:

Vendor Credit Number

Suppose Swiggy records:

Vendor Credit Number: VCN-6842

Amount: ₹42,000

but your Microsoft Dynamics ledger does not contain the corresponding credit or adjustment.

Your Dynamics receivable may therefore be ₹42,000 higher than Swiggy's payable position.

Cointab can surface this as a Swiggy-only exception.

Your team can then determine whether:

• A credit note was issued
• An adjustment needs to be booked
• Swiggy has taken a deduction requiring validation
• Another reference was used internally

---

Use Document Type to understand what the Swiggy entry represents

The Swiggy file contains:

Document Type

Dynamics also contains:

Document Type

An unmatched transaction should not automatically be assumed to be another missing invoice.

It may represent:

• Invoice
• Payment
• Credit
• Adjustment
• Other accounting transaction

Reviewing the document type helps determine which corresponding entry you should expect in Dynamics.

---

Customer Posting Group provides useful Dynamics-side context

Your Microsoft Dynamics file contains:

Customer Posting Group

This is generally not the primary invoice identifier.

However, it can be useful when investigating an exception because it provides context around how the customer transaction is being treated within Dynamics.

If an unexpected transaction appears in the wrong accounting classification, the posting group can help the finance team trace the issue.

---

Organisation Name, Vendor Code, PAN and GSTIN help validate the account context

Swiggy Instamart provides fields including:

• Organisation Name
• Vendor Code
• PAN
• GSTIN

These fields are not normally required to match individual invoices.

However, they can be useful controls when:

• A company transacts with multiple Swiggy entities
• Multiple vendor codes exist
• Similar supplier names appear in source files
• GST registrations differ across entities or locations

They help ensure that the reconciliation is comparing transactions belonging to the intended commercial relationship.

---

AI-assisted identifier extraction can help when invoice numbers are inside Dynamics Narration

Suppose Dynamics contains:

Narration

Swiggy Instamart Inv SI/24/78521 PO 64852

while Swiggy separately provides:

Invoice Number: 78521

PO Number: 64852

The useful identifiers exist in both files, but Dynamics stores them inside a longer narration.

Cointab can use AI-assisted processing to identify useful references from the configured text fields and use them during matching.

This reduces manual:

• Text splitting
• Reference cleaning
• Helper columns
• Excel FIND formulas

---

Use multiple Swiggy references instead of relying on one lookup

Swiggy provides several identifiers:

• Invoice Number
• Reference Number
• Document Identifier
• Document Number
• PO Number
• GRN Number
• Payment Reference Number
• Payment Number
• Vendor Credit Number

Different transaction types may use different identifiers.

For an invoice, Invoice Number may be strongest.

For a receipt, Payment Reference Number may matter more.

For a credit, Vendor Credit Number may be relevant.

For operational investigation, PO Number and GRN Number may provide the clue.

This is why a single-column VLOOKUP is often insufficient.

---

Manual Match for genuine transactions with unrelated references

Some valid transactions may still remain unmatched.

For example:

Dynamics

Narration:

Instamart Commercial Adj Aug

Amount:

₹36,500

Swiggy Instamart

Vendor Credit Number:

VCN-98421

Description:

Commercial adjustment

Amount:

₹36,500

Your finance team may know from supporting documentation that both entries represent the same adjustment.

Cointab provides:

Manual Match

You can:

1. Select the Dynamics transaction.
2. Select the corresponding Swiggy transaction.
3. Review both records.
4. Confirm the relationship.

The transaction is then recorded as manually reconciled.

---

A useful two-stage Swiggy Instamart reconciliation

Instead of treating all transactions alike, the finance team can think about this reconciliation in two stages.

Stage 1: Invoice recognition

Determine:

• Does Swiggy have the invoice?
• Does the amount agree?
• Is there a PO?
• Is there a GRN?
• Is the transaction recognized correctly?

Stage 2: Settlement

For recognized invoices, determine:

• What is the Payment Status?
• What is the Paid Amount?
• Is withholding involved?
• What does Dynamics show as Remaining Amount?
• Is Dynamics still Open?
• Can the payment reference be located internally?

This structure helps pinpoint where each open receivable is actually stuck.

---

Example: invoice booked and fully paid by Swiggy, but still open in Dynamics

Microsoft Dynamics

External Document No.:

INV-52148

Amount:

₹3,00,000

Remaining Amount:

₹3,00,000

Open:

Yes

Swiggy Instamart

Invoice Number:

INV-52148

Amount:

₹3,00,000

Payment Status:

Paid

Paid Amount:

₹3,00,000

Payment Reference:

UTR98521463

The invoice itself is fully matched.

But the settlement status does not agree.

The finance team should search for the UTR in:

• Bank statement
• Dynamics receipts
• Unallocated customer collections

This is a receipt-allocation investigation.

---

Example: invoice is recognized but only partly paid

Dynamics

External Document No.:

INV-68215

Original value:

₹5,00,000

Remaining Amount:

₹2,00,000

Swiggy Instamart

Invoice Number:

INV-68215

Amount:

₹5,00,000

Paid Amount:

₹3,00,000

Payment Status:

Partially Paid

Both systems tell a consistent story.

The invoice is fully recognized and ₹2,00,000 remains outstanding.

There may be no reconciliation discrepancy at all.

The item may simply require collection follow-up.

---

Example: PO and GRN exist but invoice remains unpaid

Swiggy shows:

PO Number: PO-78214

GRN Number: GRN-45218

Invoice Number: INV-74215

Payment Status: Pending

This gives your finance team useful context.

The supply has an associated purchase order and goods receipt, and the invoice exists in Swiggy's records.

The remaining issue is likely later in the payable process.

This is a very different situation from an invoice that Swiggy cannot find at all.

---

Example: withholding explains the remaining Dynamics balance

Dynamics

Invoice:

INV-96218

Amount:

₹2,00,000

Remaining Amount:

₹4,000

Swiggy Instamart

Invoice Number:

INV-96218

Amount:

₹2,00,000

Paid Amount:

₹1,96,000

Withhold Tax Amount:

₹4,000

The invoice and economic settlement can be explained.

Your finance team can investigate the corresponding TDS entry in Dynamics instead of treating the ₹4,000 as a customer short payment.

---

Example: Swiggy vendor credit is missing from Dynamics

Swiggy

Vendor Credit Number:

VCN-78452

Amount:

₹30,000

Dynamics

No corresponding transaction identified.

Cointab reports:

Present in Swiggy Instamart but not in Microsoft Dynamics

Your finance team can investigate whether:

• The credit is valid
• A credit note was issued
• The entry needs to be booked
• Another Dynamics reference was used

---

Example: invoice exists in Dynamics but has no Swiggy record

Microsoft Dynamics

External Document No.:

INV-87521

Amount:

₹2,25,000

Swiggy Instamart

No corresponding Invoice Number or identifiable transaction.

Cointab reports:

Present in Microsoft Dynamics but not in Swiggy Instamart

Your follow-up can now include the relevant:

• Invoice
• PO
• Supply information
• Amount

rather than merely asking why the overall account balance differs.

---

Turn open receivables into specific reasons

One of the strongest uses of this reconciliation is to classify open Dynamics receivables by what is happening in Swiggy's records.

For example:

This converts one large ageing balance into specific reconciliation actions.

---

Use Dynamics Due Date only after establishing that the invoice agrees

Your Microsoft Dynamics file contains:

Due Date

This becomes especially useful once invoice reconciliation is complete.

Consider two invoices:

Invoice A

Fully Matched
Swiggy Payment Status: Pending
Due Date: Next week

Invoice B

Fully Matched
Swiggy Payment Status: Pending
Due Date: 60 days ago

Both invoices reconcile correctly.

But Invoice B may require collection escalation.

This separates:

Reconciliation

from:

Receivables collection

---

Download the complete Dynamics vs Swiggy Instamart reconciliation in Excel

Once the reconciliation has been reviewed, download the complete working from Cointab.

The Excel output can include:

• Fully Matched transactions
• Partially Matched transactions
• Unmatched transactions
• Manual Matches
• Relevant Dynamics source data
• Relevant Swiggy Instamart source data

Important context can remain available, including:

• External Document No.
• Invoice Number
• PO Number
• GRN Number
• Payment Status
• Paid Amount
• Withhold Tax Amount
• Payment Reference Number
• Remaining Amount
• Due Date
• Open status

The finance team can use this working for:

• Customer reconciliation
• Accounts receivable review
• Payment follow-up
• Internal receipt allocation
• TDS investigation
• Month-end closing
• Audit support

---

Create different action lists from the same reconciliation

Once the exceptions are identified, they can be routed to the right team.

Follow up with Swiggy Instamart

Examples:

• Invoice missing from their records
• Invoice amount differs
• Payment remains pending
• PO or GRN requires clarification
• Vendor credit requires explanation

Investigate internally

Examples:

• Swiggy shows Paid but Dynamics is still Open
• Payment reference is not allocated
• Swiggy vendor credit is missing in Dynamics
• TDS entry remains unresolved
• Customer receipt is posted under another account

The reconciliation becomes a workflow for resolving the receivable rather than simply a comparison report.

---

Correct Microsoft Dynamics and reconcile again

As exceptions are resolved:

• Receipt may be booked
• Receipt may be applied to the correct invoice
• TDS entry may be recorded
• Customer credit may be booked
• Swiggy may post a missing invoice
• Incorrect amount may be corrected

Upload the revised files and rerun the reconciliation.

Transactions can move from:

Unmatched → Fully Matched

or:

Partially Matched → Fully Matched

and previously open Dynamics items can move toward complete settlement.

---

Repeat Microsoft Dynamics vs Swiggy Instamart reconciliation every month

For regular Instamart suppliers, the account changes continuously.

Each month can introduce:

• New invoices
• New POs
• New GRNs
• New customer payments
• New withholding entries
• Vendor credits
• Previously open receivables

A recurring process can be:

1. Export the latest Swiggy Instamart customer ledger from Microsoft Dynamics NAV / Business Central.
2. Obtain the latest Swiggy Instamart transaction file.
3. Upload the Dynamics ledger into Cointab.
4. Configure External Document No., Narration and other relevant identifiers.
5. Configure the transaction amount.
6. Upload the Swiggy Instamart file.
7. Configure Invoice Number and supporting references.
8. Run Customer Reconciliation.
9. Review Fully Matched invoices.
10. Investigate invoice-value differences.
11. Review Dynamics invoices missing from Swiggy.
12. Review Swiggy transactions missing from Dynamics.
13. Compare Payment Status with Dynamics Open status.
14. Compare Paid Amount with Remaining Amount.
15. Review withholding-related differences.
16. Check PO and GRN information where invoice recognition is unclear.
17. Complete Manual Matches where required.
18. Download the reconciliation working.
19. Correct internal entries.
20. Follow up with Swiggy on customer-side exceptions.
21. Upload revised files and rerun the reconciliation.

---

Previously open Dynamics invoices can resolve in later Swiggy files

Timing differences are common.

For example:

July

Dynamics contains:

INV-58421

Swiggy's July file does not yet show the invoice.

It remains unmatched.

August

The Swiggy file now contains:

• Invoice Number INV-58421
• PO Number
• GRN Number
• Payment Status

Cointab can now reconcile the previously open Dynamics invoice with the new Swiggy transaction.

Later, the same invoice may move through:

Pending → Partially Paid → Paid

while Dynamics:

Remaining Amount

reduces over time.

This makes recurring reconciliation particularly useful for accounts with large numbers of open transactions.

---

Why Microsoft Dynamics users supplying Swiggy Instamart need more than invoice matching

A simple invoice reconciliation tells you whether:

Invoice A exists in both systems.

But for an accounts receivable team, that is only the beginning.

The real objective is to understand:

Why does Invoice A remain open?

Swiggy Instamart provides useful information about:

• PO
• GRN
• Payment
• Withholding
• Vendor credits

Microsoft Dynamics provides useful information about:

• Open status
• Remaining Amount
• Customer applications
• TDS
• Due Date

Combining these two datasets provides a much richer explanation of the receivable position.

---

From Dynamics open items to an Instamart exception workflow

A manual process might require the finance team to:

• Export open customer transactions from Dynamics
• Obtain the Swiggy Instamart file
• Search invoice numbers
• Check PO references
• Check GRN details
• Compare invoice amounts
• Review payment status
• Search payment references
• Compare paid amounts
• Investigate TDS
• Review vendor credits
• Maintain an Excel tracker

Cointab changes this to:

Upload Dynamics → Upload Swiggy Instamart → Reconcile → Review Open-Item Exceptions → Resolve

Instead of manually researching every invoice, the finance team can focus on the transactions where the two systems genuinely disagree.

---

How Cointab helps reconcile Microsoft Dynamics with Swiggy Instamart

Cointab's Customer Reconciliation workflow can help you:

• Upload your Microsoft Dynamics NAV / Business Central customer ledger
• Upload the Swiggy Instamart ledger
• Use External Document No. and Invoice Number to identify invoices
• Use multiple reference fields when invoice formats differ
• Use PO Number and GRN Number during exception investigation
• Compare invoice amounts across both systems
• Separate Fully Matched and Partially Matched transactions
• Identify invoices missing from Swiggy Instamart
• Identify Swiggy transactions missing from Dynamics
• Compare Dynamics Remaining Amount with Swiggy Paid Amount
• Compare Dynamics Open status with Swiggy Payment Status
• Review Payment Reference Numbers for receipt allocation
• Investigate Swiggy withholding against Dynamics TDS information
• Identify Vendor Credit Numbers missing from your books
• Extract useful references from Dynamics Narration and transaction descriptions
• Manually match genuine transactions with inconsistent references
• Download the complete reconciliation working in Excel
• Upload corrected files and reconcile again
• Continue resolving open invoices across future periods

---

Automate Microsoft Dynamics vs Swiggy Instamart customer reconciliation

If your company supplies Swiggy Instamart and currently reconciles their records manually against your Microsoft Dynamics NAV or Dynamics 365 Business Central customer account, Cointab can automate much of the repetitive reconciliation work.

The workflow becomes:

Microsoft Dynamics Open Receivables → Swiggy Instamart Ledger → Invoice Matching → Payment & Open-Item Review → Exception Resolution

You can identify:

• Invoices that agree
• Invoices with amount differences
• Invoices missing from Swiggy
• Swiggy transactions missing from Dynamics
• Invoices Swiggy shows as paid but Dynamics still shows as open
• Partially settled invoices
• Payment references requiring internal allocation
• Withholding-related balances
• Vendor credits requiring investigation
• PO and GRN information for unresolved invoices

The result is not simply a matched ledger.

It is a transaction-level explanation of why your Swiggy Instamart receivables remain open and what needs to happen next.

If you currently reconcile your Swiggy Instamart customer account manually using Microsoft Dynamics and Excel, you can use Cointab to automate the process.

Try Cointab

For larger Instamart ledgers, customized Microsoft Dynamics exports, or more complex accounts receivable and payment reconciliation requirements:

Book a Demo