If your company supplies products to Manash E-Commerce Private Limited / Manash Lifestyle Pvt Ltd and maintains the customer account in Microsoft Dynamics NAV or Dynamics 365 Business Central, your finance team may periodically need to reconcile your books with the ledger shared by the customer.

Your Dynamics customer ledger represents what your company has recorded.

The Manash ledger represents the same commercial relationship from the customer's accounting perspective.

Both should eventually agree on the underlying invoices, credits, payments, deductions, and outstanding balances.

However, the files can look very different.

Your Microsoft Dynamics ledger may contain fields such as:

• Customer No.
• External Document No.
• Document No.
• Original Amount
• Amount in Local Currency
• Posting Date
• Narration

The Manash ledger may contain:

• Reference
• Document Number
• Amount in Local Currency
• Clearing Document
• Clearing Date
• Payment Terms
• Withholding Tax Amount
• Net Due Date
• Business Area
• Material Group

The reconciliation requirement is therefore:

Your Microsoft Dynamics Customer Ledger ↔ Manash Customer Ledger

Cointab can compare the two datasets and classify the resulting transactions into:

• Fully Matched
• Partially Matched
• Present in your Dynamics ledger but not found in Manash
• Present in Manash but not found in your Dynamics ledger
• Manually Matched

The complete reconciliation can then be reviewed, downloaded in Excel, and repeated with revised ledgers as both finance teams resolve outstanding differences.

---

Why reconcile your Manash customer account?

A customer balance can appear correct at a summary level while still containing several transaction-level differences.

For example, your Microsoft Dynamics ledger may contain an invoice that does not appear in the Manash statement.

Manash may have recorded a credit or deduction that is missing from your books.

Both systems may contain the same invoice number but at different amounts.

A customer payment may have cleared the invoice in Manash's books while your Dynamics customer entry remains open.

Withholding tax may also cause the settlement amount to differ from the original invoice value.

The objective of reconciliation is therefore not simply to compare two closing balances.

It is to determine:

• Which invoices agree
• Which invoice amounts differ
• Which invoices are missing from either side
• Which transactions Manash has already cleared
• Which customer deductions need investigation
• Whether withholding explains a payment difference
• Which finance team needs to take corrective action

---

Your Microsoft Dynamics NAV / Business Central customer ledger

A typical customer ledger export may contain:

Several of these fields may help identify the underlying commercial transaction.

In particular:

• External Document No.
• Document No.
• Description
• Narration

can contain useful invoice or transaction references.

---

What does the Manash ledger contain?

The ledger received from Manash E-Commerce / Manash Lifestyle can contain significantly richer customer-side accounting information.

A typical format may include:

This dataset can provide useful context not only for invoice matching but also for understanding why a customer item is still open or has already been cleared.

---

External Document No. versus Manash Reference

One of the most important fields in Microsoft Dynamics customer reconciliation is:

External Document No.

This often contains the commercial document reference used outside your accounting system.

Manash may store the corresponding invoice reference in:

Reference

For example:

Microsoft Dynamics

External Document No.:

INV-68425

Manash

Reference:

INV-68425

The internal accounting document numbers may be completely different.

But the shared external reference allows both records to be connected.

This is usually more useful than trying to match:

Dynamics Document No. ↔ Manash Document Number

because each organization independently generates its own internal accounting documents.

---

Internal document numbers do not need to agree

Suppose your Microsoft Dynamics ledger contains:

Document No.: SI-0097842

while Manash contains:

Document Number: 1900864521

These numbers may have no relationship.

That does not mean the transactions are different.

The commercial invoice might instead be:

INV-52641

and appear as:

Dynamics

External Document No.:

INV-52641

Manash

Reference:

INV-52641

The purpose of reconciliation is to identify the common business transaction, not to make both accounting systems use identical internal numbers.

---

How to reconcile Microsoft Dynamics with Manash using Cointab

Start a new reconciliation in Cointab and choose:

Customer Reconciliation

For this workflow:

• Side 1 = Your Microsoft Dynamics NAV / Business Central customer ledger
• Side 2 = Manash E-Commerce / Manash Lifestyle ledger

The process is:

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

---

Step 1: Upload your Microsoft Dynamics customer ledger

Export the relevant Manash customer account from Dynamics NAV or Business Central and upload the file.

Select the transaction date

Relevant fields can include:

• Posting Date
• Document Date

Choose the date appropriate for your reconciliation process.

Select transaction identifiers

Useful fields may include:

• External Document No.
• Document No.
• Description
• Narration

Multiple identifier fields can be selected where necessary.

Configure the amount

Select the appropriate amount field, such as:

• Amount
• Original Amt. (LCY)
• Amount (LCY)

depending on the export structure and the transaction value being reconciled.

---

Step 2: Upload the Manash ledger

Next, upload the ledger received from Manash.

Select the transaction date

Useful fields can include:

• Document Date
• Posting Date

Select transaction identifiers

Relevant Manash fields can include:

• Reference
• Document Number
• Text

These provide several possible ways of identifying the corresponding customer transaction.

Configure the amount

Select:

Amount in Local Currency

as the relevant transaction amount where applicable.

The reconciliation is now ready to run.

---

Step 3: Run Customer Reconciliation

Start the reconciliation.

Cointab analyzes the configured identifiers and financial values across both datasets.

For invoice-level matching, the basic questions are:

1. Can the same invoice or commercial transaction be identified on both sides?
2. If so, do the corresponding amounts agree?

The results are then separated into reconciliation categories.

---

Fully Matched Manash invoices

An invoice is Fully Matched when:

• The corresponding transaction can be identified in both ledgers
• The financial values agree

For example:

Microsoft Dynamics

External Document No.:

INV-74215

Amount:

₹2,60,000

Manash

Reference:

INV-74215

Amount in Local Currency:

₹2,60,000

Both sides agree.

Cointab therefore classifies the transaction as:

Fully Matched

These invoices generally require no further invoice-level investigation.

---

Partially Matched invoices

Sometimes the same invoice is present in both systems but the amounts differ.

For example:

Dynamics

External Document No.:

INV-74215

Amount:

₹2,60,000

Manash

Reference:

INV-74215

Amount:

₹2,55,000

The invoice reference confirms that both records relate to the same transaction.

However, there is a:

₹5,000

difference.

Cointab therefore classifies the transaction as:

Partially Matched

The finance team can then investigate the amount difference directly.

---

What can cause an amount difference?

Possible causes can include:

• Invoice recorded at an incorrect value
• Customer deduction
• Credit adjustment
• Debit adjustment
• Sales return
• Commercial scheme
• Tax difference
• Withholding treatment
• Incorrect manual posting
• Transaction split differently across both systems

A partial match is useful because the invoice itself has already been identified.

The remaining task is to understand why the values differ.

---

Invoice present in Dynamics but missing from Manash

Suppose your Microsoft Dynamics ledger contains:

External Document No.: INV-89521

Amount: ₹3,75,000

but no corresponding Reference can be found in the Manash ledger.

Cointab reports:

Present in Your Ledger but not in Manash

Possible causes may include:

• Manash has not booked the invoice
• Invoice processing is pending
• Different reference was used
• Invoice belongs to another accounting period
• Invoice is under review
• Accounting entry was missed

You can share these exceptions with the Manash finance team for investigation.

---

Transaction present in Manash but missing from Dynamics

The reverse situation can also occur.

Manash may contain:

Reference: CN-45218

Amount: ₹42,000

while your Dynamics customer ledger contains no identifiable corresponding transaction.

Cointab reports:

Present in Manash but not in Your Ledger

Your internal finance team can investigate whether:

• Credit note needs to be recorded
• Customer deduction is missing
• Payment or adjustment is unallocated
• Transaction is booked under another reference
• Manash's entry needs clarification

This immediately creates an internal reconciliation worklist.

---

Original Amount and current Amount can help explain open items

Microsoft Dynamics can contain both:

• Original Amt. (LCY)
• Amount (LCY)

This is useful because an open customer transaction may no longer carry its full original value.

For example:

Original invoice

₹5,00,000

Remaining Dynamics Amount (LCY)

₹1,00,000

This may indicate that part of the transaction has already been settled or applied.

The Manash ledger may provide a corresponding view through its:

• Clearing Document
• Clearing Date
• Remaining transaction position

These fields provide useful context while investigating open customer balances.

---

Clearing Document can show that Manash has already settled an item

The Manash file includes:

Clearing Document

A populated Clearing Document indicates that the customer has used another accounting entry to clear the transaction.

For example:

Manash

Reference:

INV-62451

Amount:

₹4,20,000

Clearing Document:

2000864572

Clearing Date:

14 August

If your Dynamics ledger still shows the invoice as open, the invoice itself may not be the problem.

The issue could instead relate to:

• Customer receipt allocation
• Missing settlement
• Incorrect accounting reference
• Payment posted against another customer
• Adjustment not applied

This makes clearing information particularly useful during customer reconciliation.

---

Clearing Date helps distinguish timing differences from genuine exceptions

Suppose Manash cleared an invoice on:

31 July

while your Dynamics settlement was posted on:

2 August

Both records may still be correct.

The different dates simply reflect separate accounting timelines.

A reconciliation should therefore not reject a genuine transaction solely because:

Posting Date ≠ Clearing Date ≠ Settlement Date

Transaction references and financial amounts generally provide the stronger relationship.

---

Withholding Tax Amount can explain a lower customer payment

The Manash ledger also contains:

Withholding Tax Amt

and:

Withhldg Tax Base Amount

These fields can be especially useful when the amount ultimately received is lower than the original invoice value.

For example:

Invoice

₹1,00,000

Withholding Tax

₹2,000

Net customer payment

₹98,000

If the finance team compares only:

Invoice ₹1,00,000 ↔ Receipt ₹98,000

the transaction may initially look short by ₹2,000.

The Manash ledger provides additional information that can help explain the difference.

The finance team can then verify whether the corresponding withholding accounting is correctly reflected in its own books.

---

Do not confuse withholding with an unexplained deduction

A lower payment does not automatically mean the customer has short-paid the invoice.

The difference could be explained by:

• Withholding tax
• Credit note
• Agreed commercial deduction
• Other adjustment

The reconciliation should therefore first identify the underlying invoice and then use the available accounting information to explain how the item was settled.

This is different from simply matching:

Invoice Amount = Bank Receipt

---

Payment Terms and Net Due Date provide receivables context

The Manash ledger contains:

• Payment terms
• Net Due Date

These fields help distinguish a reconciliation issue from a collections issue.

Suppose an invoice is fully matched between both ledgers.

That means:

Both parties agree that the invoice exists for the same value.

It does not necessarily mean:

The invoice has been paid.

For example:

Invoice A

Fully Matched
Net Due Date: Next month

Invoice B

Fully Matched
Net Due Date: 45 days ago

Invoice B may require collection follow-up even though the reconciliation itself is correct.

---

Reconciliation and collections answer different questions

It is useful to separate these two processes.

Reconciliation asks:

• Does Manash recognize our invoice?
• Is the invoice value the same?
• Are credits and adjustments aligned?
• Has the transaction been cleared consistently?

Collections asks:

• Is the invoice due?
• Is it overdue?
• How much remains unpaid?
• When should we follow up?

The Manash ledger contains fields that can support both views.

---

Document Type helps explain unmatched transactions

The Manash ledger includes:

Document Type

This can be useful when reviewing transactions that are present only on the customer side.

An unmatched entry may represent:

• Invoice
• Payment
• Credit
• Adjustment
• Other accounting document

Instead of assuming every unmatched value is another missing invoice, the finance team can use Document Type to understand what kind of transaction it is investigating.

---

Special G/L Indicator provides additional accounting context

The Manash file also contains:

Special G/L Ind.

For certain transactions, this can provide extra information about how the item is classified in the customer's accounting system.

It may not be the primary field used for invoice matching, but it can be useful when investigating transactions that do not behave like standard customer-account items.

This is another example of why preserving the complete customer ledger during reconciliation can be valuable.

---

Business Area can help distinguish similar transactions

Large retail or e-commerce customers may maintain accounting activity across different operational areas.

The Manash ledger contains:

Business Area

If several transactions have similar:

• Dates
• Amounts
• Descriptions

the Business Area can provide useful additional context while investigating which item belongs to which part of the customer's operation.

---

Material Group Description can help investigate product-related differences

The Manash ledger also includes:

Material Group Desc.

This can be useful where a customer reconciliation difference relates to a particular product or category.

For example, an invoice exception may involve:

• Specific product category
• Product return
• Commercial scheme
• Category-specific deduction

The material-group information can help the finance team understand the commercial context behind the accounting transaction.

---

Cost Center and G/L Account provide investigation context

Other Manash fields such as:

• G/L Account
• Cost Center
• Offsetting Account
• Offset Account Description

are not necessarily required for the primary invoice match.

However, they can provide valuable context when an unmatched transaction requires deeper investigation.

For example, an entry may have been posted against a specific cost center or offset account that explains why it was treated differently.

Cointab can retain the source information in the reconciliation output so finance teams can review these fields when required.

---

AI-assisted identifier extraction from ledger descriptions

Not every invoice reference is always stored perfectly.

For example:

Dynamics Narration

Manash Invoice INV 82541

Manash Text

Purchase Ref 82541

The common identifier is:

82541

but it is embedded inside different descriptions.

A manual Excel reconciliation may require:

• Text formulas
• Helper columns
• Reference cleaning
• Manual searches
• Multiple lookups

Cointab can use AI-assisted processing to identify useful transaction references from the configured ledger fields and use them during reconciliation.

---

Manual Match when references are different

Some genuine transactions may still remain unmatched because the source references are substantially different.

For example:

Dynamics

External Document No.:

ADJ-MAN-482

Amount:

₹35,000

Manash

Document Number:

1900874512

Text:

Commercial Adj August

Amount:

₹35,000

Your finance team may know from supporting documentation that the two entries represent the same transaction.

Cointab provides a:

Manual Match

option.

You can:

1. Select the relevant Dynamics transaction.
2. Select the corresponding Manash transaction.
3. Review the selected records.
4. Confirm the match.

The transaction is then recorded as manually reconciled.

---

Manual Match is useful for older customer-account differences

Customer ledgers often accumulate older exceptions involving:

• Manually posted entries
• Legacy invoice references
• Rebooked transactions
• Old credit notes
• Settlement adjustments
• Incorrect descriptions

Your finance team may know how these records relate even when the source data does not provide a clean common identifier.

Manual Match allows these items to be reconciled without modifying the original source files simply to make an Excel formula work.

---

Why closing balances alone are not enough

Suppose your Dynamics ledger shows:

Manash Receivable: ₹36,80,000

The Manash ledger indicates:

Outstanding Balance: ₹35,25,000

Difference:

₹1,55,000

The balance difference tells you that the accounts disagree.

It does not explain why.

The ₹1,55,000 could consist of:

• One invoice missing from Manash
• One credit recorded only by Manash
• One withholding-related difference
• One transaction cleared by Manash but not settled internally
• Several old open items

Transaction-level reconciliation breaks this total into individual actionable differences.

---

Example: invoice missing from Manash

Your Dynamics ledger contains:

External Document No.: INV-98215

Amount: ₹2,75,000

The Manash ledger does not contain the corresponding reference.

Cointab reports:

Present in Your Ledger but not in Manash

You can share the invoice information with their finance team.

They can determine whether:

• Invoice was missed
• Different reference was used
• Entry is pending
• Invoice belongs to another period
• Transaction is under review

---

Example: same invoice but different amounts

Suppose:

Dynamics

External Document No.:

INV-64521

Amount:

₹4,10,000

Manash

Reference:

INV-64521

Amount:

₹4,00,000

Because the invoice can be identified on both sides, Cointab classifies it as:

Partially Matched

Your finance team can immediately investigate the:

₹10,000

difference.

---

Example: withholding explains the settlement difference

Suppose:

Original invoice

₹2,50,000

Manash Withholding Tax Amount

₹5,000

Net amount settled

₹2,45,000

Your finance team may initially see a ₹5,000 difference between invoice value and cash received.

The customer ledger provides the withholding information needed to explain the difference.

Your team can then verify whether the corresponding withholding entry has been correctly accounted for in Dynamics.

---

Example: Manash has cleared an invoice that remains open internally

Suppose Manash shows:

Reference: INV-76215

Amount: ₹3,25,000

Clearing Document: 2000842157

Clearing Date: 18 August

But your Dynamics ledger still shows the transaction as open.

This tells you where to focus the investigation.

Check:

• Customer receipt
• Settlement application
• Bank reference
• Incorrect customer allocation
• Credit adjustment

The issue may be settlement rather than invoice recognition.

---

Example: customer-side credit is missing from your books

The Manash ledger contains:

Document Type: Credit

Reference: CN-56218

Amount: ₹48,000

Your Dynamics customer ledger contains no corresponding transaction.

Cointab reports:

Present in Manash but not in Your Ledger

Your finance team can investigate whether:

• A credit note needs to be recorded
• The customer has taken an unauthorized deduction
• A credit exists under another reference
• The transaction requires clarification

---

Separate customer-side and internal action items

The reconciliation naturally creates two worklists.

Transactions in Dynamics but not in Manash

These can require customer-side follow-up.

For example:

• Invoice not booked
• Incorrect customer reference
• Entry pending
• Invoice under review

Transactions in Manash but not in Dynamics

These require internal investigation first.

For example:

• Credit note missing
• Customer deduction not recorded
• Payment or settlement not allocated
• Adjustment missing
• Transaction booked under another reference

This gives every exception a clear next step.

---

Download the complete Manash customer reconciliation in Excel

Once the reconciliation is reviewed, download the complete working from Cointab.

The Excel output can provide transaction-level details across:

• Fully Matched
• Partially Matched
• Unmatched
• Manual Matches
• Underlying Dynamics data
• Underlying Manash data

Fields such as:

• External Document No.
• Reference
• Document Type
• Payment Terms
• Withholding Tax Amount
• Net Due Date
• Clearing Document
• Clearing Date

can provide valuable context when reviewing exceptions.

The downloaded file can be used for:

• Accounts receivable review
• Customer follow-up
• Month-end closing
• Balance confirmation
• Audit support
• Exception tracking

---

Use transaction-level differences for customer follow-up

Without reconciliation, customer communication can become:

"Our closing balance does not agree with yours."

That gives the customer very little information to investigate.

A transaction-level reconciliation allows you to say:

• Invoice INV-5214 is missing from your ledger.
• Invoice INV-6421 differs by ₹10,000.
• Credit CN-7845 exists in your ledger but not ours.
• Invoice INV-8421 is cleared in your system but still open in ours.

This makes the discussion much more actionable for both finance teams.

---

Upload revised ledgers and reconcile again

Once the differences have been investigated:

• You may update Dynamics
• Manash may update its books
• A credit may be recorded
• Missing invoice may be booked
• Settlement may be applied
• Amount may be corrected

Upload the revised ledgers to Cointab and run the reconciliation again.

Transactions can move from:

Unmatched → Fully Matched

or:

Partially Matched → Fully Matched

as the underlying accounting differences are resolved.

---

Repeat the Manash reconciliation every month

Customer reconciliation is usually a recurring process.

Each month may introduce:

• New invoices
• Customer payments
• Credit notes
• Withholding entries
• Settlement activity
• Previous open items

The same reconciliation can therefore be repeated with updated data.

A typical monthly workflow becomes:

1. Export the latest Manash customer ledger from Microsoft Dynamics NAV / Business Central.
2. Obtain the latest ledger from Manash.
3. Upload the Dynamics file to Cointab.
4. Configure date, identifiers, and amount fields.
5. Upload the Manash ledger.
6. Configure Reference, Document Number, Text, and Amount.
7. Run Customer Reconciliation.
8. Review Fully Matched invoices.
9. Investigate Partially Matched invoices.
10. Review transactions missing from Manash.
11. Review transactions missing from Dynamics.
12. Use withholding information to investigate amount differences.
13. Use Clearing Document and Clearing Date to investigate settlements.
14. Complete Manual Matches where required.
15. Download the reconciliation working.
16. Correct internal entries.
17. Share customer-side exceptions with Manash.
18. Upload revised ledgers and rerun the reconciliation.

---

Older open transactions can reconcile in future periods

Timing differences are normal.

For example:

July

You raise an invoice in Microsoft Dynamics.

Manash has not yet posted the corresponding transaction.

The invoice appears unmatched.

August

The latest Manash ledger now contains the invoice reference.

Cointab can reconcile the new customer-side record against the previously open Dynamics transaction.

Similarly, an invoice may remain open until a future:

• Payment
• Credit
• Clearing entry

appears.

This allows unresolved transactions to continue across reconciliation periods until the customer account is aligned.

---

Why this reconciliation is useful for brands selling to large e-commerce and retail customers

As brands expand into organized retail and e-commerce channels, customer accounts become more complex.

Direct consumer collections may follow:

Order → Payment Gateway → Bank

Large B2B customer relationships instead involve:

Invoice → Customer Accounting → Deductions / Withholding → Payment → Clearing

Finance teams therefore need more than just bank reconciliation.

They need to know whether the large customer's books agree with their own accounts receivable ledger.

A structured customer reconciliation makes this process much easier to manage.

---

Move from manual Excel matching to exception management

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

• Export customer ledger data
• Obtain the Manash statement
• Normalize different formats
• Search invoice references
• Compare document numbers
• Compare amounts
• Review withholding
• Check clearing documents
• Review due dates
• Carry older open items forward
• Build lookup formulas
• Add manual comments

The same work repeats each month.

Cointab changes the process to:

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

The finance team can spend more time resolving actual discrepancies and less time constructing the reconciliation workbook.

---

How Cointab helps reconcile Microsoft Dynamics with Manash

Cointab's Customer Reconciliation workflow can help you:

• Upload your Microsoft Dynamics NAV / Business Central customer ledger
• Upload the Manash customer ledger
• Configure different transaction dates
• Use External Document No. as a commercial reference
• Use Manash Reference and Document Number as identifiers
• Select multiple identifier fields
• Extract useful references from descriptions and narrations
• Automatically identify corresponding invoices
• Separate Fully Matched transactions
• Identify invoices with amount differences
• Identify transactions present only in Dynamics
• Identify transactions present only in Manash
• Use withholding information while investigating payment differences
• Use Clearing Document and Clearing Date during settlement review
• Manually match genuine transactions with different references
• Download the complete reconciliation working in Excel
• Upload corrected ledgers and reconcile again
• Continue reconciling open items across future periods

---

Automate Microsoft Dynamics vs Manash customer reconciliation

If you supply Manash E-Commerce Private Limited / Manash Lifestyle Pvt Ltd and currently reconcile their ledger manually against your Microsoft Dynamics NAV or Business Central customer account, Cointab can automate much of the repetitive comparison work.

The workflow becomes:

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

You can quickly identify:

• Invoices that agree
• Invoices with amount differences
• Transactions missing from either ledger
• Customer credits or deductions
• Withholding-related differences
• Transactions already cleared by Manash
• Older unresolved customer-account items

The complete reconciliation can then be downloaded in Excel and used for internal review or customer follow-up.

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

Try Cointab

For larger customer ledgers, customized Dynamics NAV / Business Central exports, or more complex accounts receivable reconciliation requirements:

Book a Demo