If your company supplies products to Zepto and maintains the customer account in Microsoft Dynamics, your finance team may periodically need to reconcile your receivable ledger with the ledger shared by Zepto.

Your Microsoft Dynamics ledger records the transactions according to your books.

Zepto maintains the same commercial relationship from its own accounting perspective.

Both datasets should eventually represent the same invoices, payments, adjustments, and outstanding balances.

But they may look very different.

Your Dynamics ledger may contain:

• GST Invoice Number
• Sales Order Number
• Purchase Order Number
• UTR Number
• Invoice Amount
• Due Date
• Overdue Amount
• Settlement Document
• Settlement Date
• Voucher information

Zepto's ledger may instead contain:

• Document Number
• Reference Number
• GRN Date
• UTR Number
• Amount
• Clearing Document
• Clearing Date
• Assignment
• Running Balance

The reconciliation requirement is:

Your Microsoft Dynamics Customer Ledger ↔ Zepto Ledger

Cointab can automatically compare both files and classify transactions into:

• Fully Matched
• Partially Matched
• Present in your Dynamics ledger but missing from Zepto
• Present in Zepto but missing from your Dynamics ledger
• Manually Matched

The reconciliation can then be downloaded in Excel, used to resolve accounting differences, and repeated when updated ledgers become available.

---

Why reconcile your Zepto customer account?

Selling through quick-commerce channels creates a very different finance workflow from selling directly through your own website.

For a direct-to-consumer order, the financial flow may be:

Customer Order → Payment Gateway → Bank

When supplying Zepto as a business customer, the flow can look more like:

Purchase Order → Supply → GRN → Invoice → Customer Accounting → Payment → Clearing

Your accounts receivable ledger may therefore contain hundreds or thousands of transactions at different stages.

Some invoices may be:

• Newly raised
• Accepted by Zepto
• Awaiting payment
• Partially settled
• Fully settled
• Missing from the customer ledger
• Recorded with a different reference
• Carried forward from an earlier period

A customer reconciliation helps determine exactly which transactions are causing any difference between your books and Zepto's records.

---

What does your Microsoft Dynamics customer ledger contain?

A Microsoft Dynamics customer ledger used for this reconciliation may have fields such as:

This file contains several useful reconciliation identifiers.

An individual customer transaction may be identifiable through:

• GST Invoice Number
• PO No
• SO No
• UTR Number
• Internal Reference Number
• Voucher
• Description

The availability of multiple references is important because Zepto may not use your Dynamics voucher number as its own transaction identifier.

---

What does the Zepto ledger contain?

The ledger received from Zepto may contain fields such as:

This creates a particularly useful customer-reconciliation dataset because Zepto provides information relating to both:

invoice recognition

and:

payment / clearing

The reconciliation can therefore answer more than simply whether an invoice number exists.

---

Reconcile the complete Zepto invoice lifecycle

When supplying a quick-commerce customer, an invoice does not exist in isolation.

A typical transaction may pass through several stages:

PO → Supply → GRN → GST Invoice → Customer Posting → Payment → Clearing

Your Dynamics system and Zepto's accounting system may capture different parts of this lifecycle.

For example, your Dynamics file may contain:

• PO No
• SO No
• GST Invoice Number
• Invoice Amount
• Due Date

Zepto may contain:

• Reference No
• GRN Date
• Document Number
• UTR No.
• Clearing Document
• Clearing Date

Reconciliation connects these different views of the same commercial transaction.

---

How to reconcile Microsoft Dynamics with Zepto using Cointab

Start a new reconciliation in Cointab and select:

Customer Reconciliation

For this workflow:

• Side 1 = Your Microsoft Dynamics Zepto customer ledger
• Side 2 = Zepto ledger

The process is:

Upload Dynamics Ledger → Upload Zepto Ledger → Configure Fields → Run Reconciliation → Review Exceptions

---

Step 1: Upload your Microsoft Dynamics ledger

Export the relevant Zepto customer ledger from Microsoft Dynamics and upload it to Cointab.

Select the date

Choose the date field appropriate for your reconciliation.

Select transaction identifiers

Useful identifiers can include:

• GST Invoice Number
• Internal Reference Number
• PO No
• SO No
• UTR Number
• Voucher
• Description

Multiple identifiers can be selected.

This allows Cointab to use the commercial references contained throughout your ledger instead of depending on only one field.

Select the amount

Configure the relevant:

Invoice Amount

field.

Cointab can now interpret your customer transactions.

---

Step 2: Upload the Zepto ledger

Next, upload the ledger received from Zepto.

Select the date

Useful date fields can include:

• Posting Date
• Document Date

depending on how the reconciliation is performed.

Select transaction identifiers

Potential identifiers include:

• Document No
• Reference No
• UTR No.
• Assignment
• Text

These fields provide several possible connections with the corresponding Dynamics transactions.

Select the amount

Configure:

Amount

as the transaction value.

Additional fields such as:

• GRN Date
• Settlement Type
• Clearing Doc
• Clearing Date
• Running Balance

can provide valuable context while investigating reconciliation exceptions.

---

Step 3: Run Customer Reconciliation

Once both datasets are configured, start the reconciliation.

Cointab analyzes the selected identifiers and financial values to determine which Dynamics records correspond to which Zepto records.

The invoice-level reconciliation broadly answers two questions:

1. Can the same invoice be identified on both sides?
2. If it exists on both sides, do the amounts agree?

The output is then divided into clear reconciliation categories.

---

Fully Matched Zepto invoices

An invoice is Fully Matched when the corresponding invoice can be identified in your Dynamics ledger and the Zepto ledger and the values agree.

For example:

Microsoft Dynamics

GST Invoice Number:

INV-78452

Invoice Amount:

₹2,80,000

Zepto

Reference No:

INV-78452

Amount:

₹2,80,000

The invoice exists on both sides with no amount difference.

Cointab therefore classifies it as:

Fully Matched

The invoice itself requires no further reconciliation investigation.

---

Partially Matched Zepto invoices

An invoice may exist in both systems but at different values.

For example:

Microsoft Dynamics

GST Invoice Number:

INV-78452

Invoice Amount:

₹2,80,000

Zepto

Reference No:

INV-78452

Amount:

₹2,72,500

The common invoice reference establishes that both records represent the same underlying transaction.

However, there is a:

₹7,500

difference.

Cointab classifies the transaction as:

Partially Matched

Your finance team can immediately focus on explaining the value difference.

---

What can cause an amount difference?

Possible causes may include:

• Invoice booked at an incorrect amount
• Credit adjustment
• Debit adjustment
• Customer deduction
• Rate difference
• Product return
• Commercial adjustment
• Tax-related difference
• Incorrect posting
• Transaction split differently across the two systems

The important point is that Cointab has already identified the invoice relationship.

You are investigating the difference, rather than searching manually for whether the invoice exists.

---

Invoice present in Dynamics but missing from Zepto

Suppose your Dynamics ledger contains:

GST Invoice Number: INV-91524

Invoice Amount: ₹4,25,000

but no corresponding transaction can be identified in the Zepto ledger.

Cointab reports:

Present in Your Ledger but not in Zepto

This becomes a customer-side reconciliation exception.

Possible explanations include:

• Invoice has not yet been booked by Zepto
• Invoice is pending processing
• Different reference was used
• GRN process is incomplete
• Invoice belongs to another accounting period
• Invoice is under review
• Transaction was missed

You can share the specific invoice with the relevant Zepto team for investigation.

---

Transaction present in Zepto but missing from Dynamics

The reverse situation is equally important.

Zepto may contain an accounting transaction that cannot be found in your Microsoft Dynamics customer ledger.

For example:

Zepto

Reference No:

ADJ-56214

Amount:

₹32,000

Microsoft Dynamics

No corresponding transaction identified.

Cointab reports:

Present in Zepto but not in Your Ledger

Your finance team can investigate whether:

• Adjustment needs to be booked
• Credit is missing
• Receipt has not been allocated
• Transaction exists under another reference
• Zepto's transaction requires clarification

This becomes an internal action item.

---

GST Invoice Number can be the primary commercial identifier

Your Microsoft Dynamics file contains a dedicated:

GST Invoice Number

field.

For customer reconciliation, this is often more useful than comparing internal accounting document numbers.

For example:

Dynamics

Voucher:

ARV-0098741

GST Invoice Number:

INV-56241

Zepto

Document No:

5100874215

Reference No:

INV-56241

The internal accounting references are completely different.

But the common commercial identifier is:

INV-56241

That is the relationship the reconciliation needs to identify.

---

Zepto Document Number does not need to match your Dynamics Voucher

Each organization generates its own internal accounting references.

Your transaction may have:

Dynamics Voucher: ARV-0098741

while Zepto records:

Document No: 5100874215

These numbers are not supposed to match.

The invoice may instead be connected through:

• GST Invoice Number
• Reference No
• PO Number
• Assignment
• Description
• Other supporting identifiers

This is why customer reconciliation should not rely on a single exact document-number lookup.

---

Use Purchase Order numbers to investigate exceptions

Your Dynamics ledger contains:

PO No

The Zepto transaction lifecycle originates from the customer's purchase process.

When an invoice does not reconcile, the purchase order can provide an important second reference.

For example:

Your Dynamics

GST Invoice:

INV-78421

PO No:

PO-562148

Zepto

Reference:

INV-78421

or another record associated with the relevant commercial transaction.

The PO can help establish which customer order the invoice relates to.

This is particularly useful when:

• Invoice reference is inconsistent
• Several invoices have similar amounts
• Customer asks for supporting transaction information
• Invoice is pending in the procurement process

---

Sales Order Number provides another internal link

Your Dynamics ledger also contains:

SO No

The sales order provides an internal link between:

• Customer order
• Product supply
• Invoice

For example:

Zepto PO → Your Dynamics SO → GST Invoice

When investigating an exception, this provides another way to trace the transaction internally.

The finance team does not need to rely entirely on the final accounting voucher.

---

GRN Date can explain why an invoice has not progressed

One particularly useful field in the Zepto ledger is:

GRN Date

GRN refers to the customer's goods receipt process.

For businesses supplying physical products, the commercial lifecycle can involve:

Purchase Order → Delivery → GRN → Invoice Processing

Suppose you raised an invoice but it has not reconciled correctly against Zepto.

The GRN information can provide an important clue.

If the relevant goods receipt has not been completed, the invoice may not yet have progressed normally through the customer's accounting process.

This turns the reconciliation from:

"Invoice is missing"

into a more useful investigation:

"Invoice is missing — check whether the corresponding goods receipt has been completed."

---

GRN information is especially useful for quick-commerce suppliers

Quick-commerce businesses operate high-volume supply networks.

A brand may supply products across:

• Distribution centers
• Dark-store networks
• Warehouses
• Different purchase orders
• Multiple deliveries

An invoice discrepancy can therefore originate before the accounting stage.

For example:

• Wrong PO
• Delivery not acknowledged
• GRN pending
• Quantity discrepancy
• Invoice created against the wrong supply transaction

The presence of GRN Date in Zepto's file provides useful operational context when investigating customer-ledger exceptions.

---

UTR Number helps reconcile customer payments

Both datasets can contain payment references.

Your Dynamics file contains:

UTR Number

Zepto's file contains:

UTR No.

This can create a strong reference for matching customer receipts.

For example:

Zepto

UTR:

HDFC123456789

Microsoft Dynamics

UTR Number:

HDFC123456789

The common UTR can help establish that Zepto's payment corresponds to the receipt recorded in your books.

---

Payment reconciliation is different from invoice reconciliation

A customer account contains two related but different reconciliation problems.

Invoice reconciliation

Does Zepto recognize the invoice you raised?

Payment reconciliation

Has the payment or settlement recorded by Zepto been correctly reflected in your books?

An invoice can be fully matched while the corresponding payment is still missing or incorrectly allocated.

This distinction is important for accounts receivable teams.

---

Clearing Document provides settlement information

The Zepto ledger contains:

Clearing Doc

This can be extremely useful when investigating whether an invoice has already been settled in the customer's books.

For example:

Zepto

Reference:

INV-68421

Amount:

₹3,00,000

Clearing Doc:

2000784521

Clearing Date:

18 August

This indicates that the transaction has been cleared in Zepto's accounting records.

If your Dynamics ledger still shows the invoice as outstanding, the finance team can investigate the customer receipt or settlement allocation.

---

Your Dynamics file also contains settlement information

Your Microsoft Dynamics file contains:

• Settlement Doc
• Settlement Date

This means both sides provide information about transaction settlement.

That creates an especially useful reconciliation opportunity.

You can compare:

Dynamics Settlement ↔ Zepto Clearing

For a genuinely settled transaction, the accounting position in both systems should eventually be consistent.

---

Settlement Doc vs Clearing Doc

The terminology may differ:

Microsoft Dynamics

Settlement Doc

Zepto

Clearing Doc

But both provide information relevant to whether an open customer transaction has been settled.

Suppose Zepto shows an invoice as cleared while your Dynamics transaction has no corresponding settlement.

This may indicate:

• Receipt has not been allocated
• Payment was posted elsewhere
• Settlement is pending
• Reference differs
• Customer and supplier records are not aligned

This allows the reconciliation to identify not only missing invoices but also settlement-state differences.

---

Settlement Date vs Clearing Date

The files also contain:

Dynamics

Settlement Date

Zepto

Clearing Date

These dates may not always be identical.

For example:

Zepto Clearing Date: 29 July

Dynamics Settlement Date: 1 August

The transaction may still be correct.

The difference can simply reflect different posting or processing timelines.

Cointab allows the reconciliation to use identifiers and financial values without requiring every date to be exactly the same.

---

Posting Date and Document Date can differ

Zepto separately provides:

• Posting Date
• Document Date

Your own Dynamics transaction also has its accounting date.

For example:

Invoice date: 30 June

Zepto Posting Date: 2 July

Both can refer to the same invoice.

A simple Excel comparison based on exact dates may therefore create unnecessary mismatches.

The transaction reference and financial value often provide the stronger connection.

---

Assignment can provide another reconciliation reference

Zepto also provides:

Assignment

This can contain useful transaction information depending on how the entry was recorded.

When an invoice cannot be matched using one obvious reference, fields such as:

• Reference No
• Assignment
• Text
• Document No
• UTR

can provide additional clues.

Cointab allows multiple identifier fields to be considered during reconciliation.

---

AI-assisted identifier extraction from ledger descriptions

Not every useful reference is stored in a perfectly structured field.

Your Dynamics Description may contain:

Zepto GST Inv 784521 PO 45682

while the Zepto Text field may contain:

Invoice 784521

The underlying common reference is:

784521

A spreadsheet-led reconciliation may require:

• Text cleaning
• Helper columns
• FIND formulas
• LEFT / RIGHT / MID formulas
• Manual searches

Cointab can use AI-assisted processing to identify useful transaction references from selected ledger fields and use them for matching.

This reduces the amount of manual preparation required before the reconciliation starts.

---

Manual Match when you know the transactions belong together

Some transactions may still remain unmatched because the reference formats differ substantially.

For example:

Microsoft Dynamics

Internal Reference:

ZP-ADJ-482

Amount:

₹37,500

Zepto

Assignment:

ADJ78421

Amount:

₹37,500

Your finance team knows from supporting documentation that these are the same transaction.

Cointab provides a:

Manual Match

workflow.

You can:

1. Select the Dynamics transaction.
2. Select the corresponding Zepto transaction.
3. Review the records.
4. Confirm the match.

Cointab then records the relationship as a manual reconciliation decision.

---

Manual matching is useful for historical Zepto open items

Older customer accounts can contain:

• Legacy invoice references
• Manually posted adjustments
• Old receipts
• Rebooked transactions
• Incorrect references
• Historic open items

Trying to modify the original source data just to make an Excel lookup work may not be appropriate.

Manual Match allows finance teams to use their knowledge of the underlying transaction while keeping the source ledger unchanged.

---

Due Date and Overdue Amount provide collections context

Your Microsoft Dynamics data also contains:

• Due Date
• OverDue Amount

These fields help distinguish two different situations.

Reconciliation issue

Zepto does not agree with your invoice or transaction.

Collection issue

Zepto agrees with the invoice, but the amount remains unpaid after its due date.

For example:

Invoice A

Reconciliation: Fully Matched
Due Date: Next week

Invoice B

Reconciliation: Fully Matched
Overdue Amount: ₹2,00,000

Invoice B does not necessarily have a reconciliation problem.

It may simply require collection follow-up.

This distinction allows finance teams to avoid mixing accounting exceptions with normal receivables management.

---

Running Balance is useful for control but does not explain differences

The Zepto ledger contains:

Running Balance

This helps show how each customer transaction affects the account.

However, comparing only the final balance does not explain the underlying reconciliation.

For example:

Your Dynamics Zepto Receivable: ₹48,50,000

Zepto Ledger Balance: ₹46,90,000

Difference:

₹1,60,000

That ₹1,60,000 might consist of:

• One invoice missing in Zepto
• One receipt not settled in Dynamics
• One amount difference
• One adjustment recorded only by Zepto
• Several older timing differences

A transaction-level reconciliation identifies these components individually.

---

Example: GST invoice missing in Zepto

Your Dynamics ledger contains:

GST Invoice Number: INV-32841

Invoice Amount: ₹2,90,000

Zepto has no corresponding Reference No or related transaction.

Cointab reports:

Present in Your Ledger but not in Zepto

You can then investigate:

• Was the invoice submitted?
• Was the correct PO quoted?
• Has the GRN been completed?
• Is invoice processing pending?
• Was another reference used?

This provides a much more precise follow-up than simply reporting a balance difference.

---

Example: Zepto has cleared the invoice but Dynamics still shows it open

Suppose:

Zepto

Reference:

INV-46215

Amount:

₹5,20,000

Clearing Doc:

CLR-784521

Clearing Date:

12 August

Microsoft Dynamics

GST Invoice:

INV-46215

Invoice remains unsettled.

The invoice itself may be fully matched, but the settlement state differs.

Your finance team can investigate:

• Customer receipt
• UTR
• Bank entry
• Settlement allocation
• Posting against another customer

This is a payment-allocation issue rather than an invoice-recognition issue.

---

Example: same invoice but different values

Suppose:

Dynamics

GST Invoice:

INV-58421

Amount:

₹3,40,000

Zepto

Reference:

INV-58421

Amount:

₹3,32,000

The invoice is identifiable on both sides.

Cointab classifies it as:

Partially Matched

Your finance team can investigate the:

₹8,000

difference directly.

---

Example: UTR connects a customer payment

Zepto records:

UTR No.: ICIC000784521

Your Dynamics customer ledger also contains:

UTR Number: ICIC000784521

Even if the internal voucher and clearing document numbers are different, the shared UTR provides a strong relationship between the customer-side payment and your receipt.

This helps resolve payment-related open items.

---

Example: invoice is missing but GRN information provides a clue

Your Dynamics ledger contains:

GST Invoice: INV-67215

PO No: PO-84217

The invoice does not reconcile.

Zepto's latest data shows activity relating to the transaction but the expected invoice is not yet reflected.

Reviewing the GRN information may help determine whether the issue relates to the underlying receipt process.

This allows your finance team to follow up using:

• PO
• GRN
• Invoice

rather than relying only on invoice number and amount.

---

Separate invoice exceptions from settlement exceptions

This reconciliation can generate two broad categories of issues.

Invoice-side exceptions

Examples:

• Invoice missing from Zepto
• Invoice missing from Dynamics
• Invoice value differs
• Reference differs
• Invoice linked to an incorrect PO

Settlement-side exceptions

Examples:

• Zepto shows invoice cleared but Dynamics does not
• Receipt exists but UTR does not reconcile
• Settlement recorded in a different period
• Payment allocated incorrectly
• Adjustment exists only on one side

Separating these categories makes the finance team's investigation more efficient.

---

Know which party needs to take action

Once the reconciliation is complete, the exception population can be divided into actionable worklists.

Present in Dynamics but missing from Zepto

These may require customer-side follow-up.

You can investigate with Zepto using:

• GST Invoice Number
• PO No
• SO No
• Invoice Date
• Amount
• Supporting delivery documentation

Present in Zepto but missing from Dynamics

These generally require internal review first.

Your team can investigate:

• Customer receipts
• Adjustments
• UTR references
• Settlement entries
• Incorrect customer allocation
• Missing accounting entries

This gives every unmatched transaction a practical next step.

---

Download the complete Zepto customer reconciliation in Excel

Once you have reviewed the reconciliation, download the complete working in Excel.

The output can provide transaction-level views across:

• Fully Matched
• Partially Matched
• Unmatched
• Manual Matches
• Relevant source transaction information

The working can be used for:

• Accounts receivable review
• Customer follow-up
• Month-end closing
• Outstanding reconciliation
• Finance-team review
• Audit support
• Historical exception tracking

Instead of maintaining a separate manual Excel workbook, the finance team receives a prepared reconciliation output.

---

Use the reconciliation for precise Zepto follow-up

Without transaction-level reconciliation, customer follow-up may look like:

"Our balance differs from yours. Please confirm."

With the reconciliation, the discussion can be much more specific:

• GST Invoice INV-4821 is missing from your ledger.
• Invoice INV-5624 has an ₹8,000 value difference.
• Invoice INV-6842 is shown as cleared in your ledger but remains open in ours.
• UTR 784512 has not been allocated against the relevant customer account.

Specific exceptions are much easier for both finance teams to investigate.

---

Correct the books and reconcile again

Customer reconciliation is rarely complete after the first comparison.

The process usually identifies actions such as:

• Book missing entry
• Correct invoice amount
• Allocate customer receipt
• Update settlement
• Correct reference
• Customer posts missing invoice

Once these corrections are made, upload the revised datasets again.

Cointab reruns the reconciliation and updates the result.

Transactions can move from:

Unmatched → Fully Matched

or:

Partially Matched → Fully Matched

or settlement-related open items can disappear after the relevant receipt is correctly allocated.

---

Repeat the Zepto reconciliation every month

If you supply Zepto regularly, the customer account continuously changes.

Every month can introduce:

• New invoices
• New purchase orders
• New GRNs
• New payments
• New UTR references
• New settlements
• Older open transactions

The same reconciliation can therefore be repeated each accounting period.

A typical monthly workflow becomes:

1. Export the latest Zepto customer ledger from Microsoft Dynamics.
2. Obtain the latest ledger from Zepto.
3. Upload the Dynamics ledger to Cointab.
4. Configure the relevant date, amount, and identifier fields.
5. Upload the Zepto ledger.
6. Configure Reference No, UTR, Assignment, and other relevant identifiers.
7. Run Customer Reconciliation.
8. Review Fully Matched invoices.
9. Investigate Partially Matched invoices.
10. Review invoices appearing only in Dynamics.
11. Review transactions appearing only in Zepto.
12. Compare settlement and clearing information.
13. Review UTR references for payment differences.
14. Complete Manual Matches where required.
15. Download the reconciliation working.
16. Correct internal transactions.
17. Follow up with Zepto on customer-side exceptions.
18. Upload revised files and run the reconciliation again.

The same workflow can then continue into the next month.

---

Previously open Zepto invoices can reconcile later

Timing differences are normal.

For example:

July

You raise a GST invoice on 31 July.

The transaction exists in Microsoft Dynamics.

Zepto has not yet completed its processing.

Cointab reports the invoice as unmatched.

August

Zepto's latest ledger now contains the invoice.

It may also contain:

• Reference No
• GRN Date
• Clearing information

Cointab can compare the newly available Zepto transaction against the previously open invoice.

This allows genuine timing differences to resolve naturally in future periods.

---

Customer reconciliation for brands selling through quick commerce

As consumer brands expand across channels, each sales route creates a different financial reconciliation requirement.

For example:

D2C website

Orders → Payment Gateway → Bank

Marketplace

Orders → Marketplace Settlement → Bank

Distributor

Customer Ledger → Distributor Ledger

Large quick-commerce customer

PO → GRN → Invoice → Customer Ledger → Payment → Clearing

Zepto customer reconciliation therefore belongs to the accounts-receivable side of the finance process rather than simply being another marketplace settlement reconciliation.

---

Move from manual Excel comparisons to exception management

A manual Dynamics vs Zepto reconciliation may require the finance team to:

• Export Dynamics data
• Obtain the Zepto file
• Normalize different column structures
• Search GST invoice numbers
• Compare reference numbers
• Review PO information
• Check GRN dates
• Compare UTRs
• Review clearing documents
• Compare amounts
• Identify open items
• Build lookup formulas
• Carry old differences forward

The process repeats every month.

Cointab changes this to:

Upload Dynamics → Upload Zepto → Run Reconciliation → Review Exceptions → Resolve Differences

The finance team can focus on the small population that genuinely needs investigation.

---

How Cointab helps reconcile Microsoft Dynamics with Zepto

Cointab's Customer Reconciliation workflow allows you to:

• Upload your Microsoft Dynamics customer ledger
• Upload the Zepto ledger
• Configure different transaction-date fields
• Use GST Invoice Number as an invoice identifier
• Use PO and SO numbers as supporting references
• Use Zepto Reference No and Assignment fields
• Match payment references using UTR
• Extract useful identifiers from transaction descriptions
• Automatically identify corresponding invoices
• Separate Fully Matched transactions
• Identify Partially Matched transactions
• Identify records present only in Dynamics
• Identify records present only in Zepto
• Compare settlement and clearing information
• Use GRN information while investigating invoice exceptions
• Manually match transactions with different references
• Download the entire reconciliation working in Excel
• Upload corrected datasets and rerun the reconciliation
• Carry unresolved transactions into future periods

---

Automate your Microsoft Dynamics vs Zepto customer reconciliation

If you supply Zepto and currently compare their ledger manually against your Microsoft Dynamics customer account, Cointab can automate much of the reconciliation work.

The process becomes:

Microsoft Dynamics Customer Ledger → Zepto Ledger → Automated Matching → Exception Review → Corrections → Updated Reconciliation

You can quickly identify:

• GST invoices that agree
• Invoices with amount differences
• Invoices missing from either side
• Payment and UTR differences
• Transactions already cleared by Zepto
• Settlement differences in your books
• Older unresolved transactions

The complete reconciliation can then be downloaded in Excel and used for internal follow-up or discussions with Zepto.

If your company uses Microsoft Dynamics and currently reconciles its Zepto customer account manually in Excel, you can use Cointab to automate the process.

Try Cointab

For larger Zepto ledgers, customized Dynamics exports, or more complex quick-commerce customer reconciliation requirements:

Book a Demo