Guides, glossaries and calculators to help you scope, cost and run an ERPNext implementation — from GST and e-invoicing setup to module-by-module walkthroughs.
Quick definitions of key terms
Expert insights and updates
Simple step-by-step resources
Easy explanations through videos.
Complete IRN flow in ERPNext (2026)
ERPNext HRMS for India's Labour Codes
ERPNext for Indian hospitals (NABH, ABDM, DPDP)
DPDP Act 2023 Compliance in ERPNext
Reconciliation that takes minutes, not a fortnight. Bank reconciliation is the task everyone postpones and nobody can skip. It gets postponed because it is done at month end against four weeks of transactions, by which point nobody remembers what a particular UPI credit was for. Done daily against a short list, it stops being a task at all.
ERPNext ships a Bank Reconciliation Tool with statement import and rule-based matching. The work is in the rules, not the import.
Statements are imported as CSV, XLSX or MT940, or pulled by feed where the bank supports it. The Bank Reconciliation Tool proposes matches against existing payment entries and invoices using amount, date, party and reference, and matching rules can be defined for recurring patterns. Anything unmatched stays in a queue for review.
The volume is not the problem. The problem is that most credits arrive without enough information to identify them.
A credit shows a handle, a reference string and an amount. Nothing names the invoice. At low volume you can guess from the amount; at high volume you cannot, and the queue grows faster than anyone clears it.
Customers settle in round figures against whatever is outstanding, so one receipt covers three invoices and part of a fourth. A one-to-one matcher cannot resolve that, so those entries sit unmatched indefinitely.
Bank charges, processing fees and interest appear on the statement having never been entered in the books. Each is small and each blocks a clean reconciliation until someone posts it.
By the time reconciliation runs, the person who could identify a payment has forgotten. Monthly cadence is the single largest contributor to reconciliation effort, and it is a choice rather than a constraint.
The objective is a queue short enough to clear before the first coffee, every day, by someone who is not a chartered accountant.
CSV and XLSX in your bank's own column layout, or MT940 where offered, mapped once so imports need no manual reshaping thereafter.
Where the bank supports a direct feed, that removes the download step entirely — but the mapping work is the same either way.
Recurring patterns are matched by rule — a particular narration fragment always being a specific customer, a standing debit always being rent, a fee pattern always posting to bank charges.
Each rule permanently removes a category of transaction from the queue. Ten good rules typically handle the large majority of monthly volume.
Reference strings are parsed for the fragments that identify a payer — VPA handles, account name text, invoice numbers where customers include them — and matched against party records.
Customers who quote an invoice number reconcile automatically. Part of the work is nudging your regular payers to do that.
A single credit can be allocated across several outstanding invoices, with the residual held on account rather than forcing an artificial split.
This is what makes reconciliation work for businesses whose customers settle in round figures rather than per invoice.
Bank charges, interest and fees identified by rule create their own journal entries during reconciliation instead of blocking it.
Small in value, disproportionate in nuisance. Automating them is most of what makes a daily cadence realistic.
Every line resolves to one of these outcomes. Nothing is allowed to remain simply unexplained.
| Statement line | ERPNext outcome | Direction | Notes |
|---|---|---|---|
| Credit matching one payment entry | Matched and cleared | Automatic | Amount, date and party agree |
| Credit against several invoices | Allocated across invoices | Automatic or assisted | Residual held on account |
| UPI or NEFT credit with a parseable reference | Matched to party | Automatic | Narration rules identify the payer |
| Credit with no identifiable payer | Unmatched queue | Manual | Reviewed daily while context is fresh |
| Debit matching a payment entry | Matched and cleared | Automatic | Supplier payments and salary transfers |
| Bank charge or fee | Journal Entry to charges | Automatic by rule | Created during reconciliation, not before |
| Interest credit or debit | Journal Entry | Automatic by rule | Posted to the nominated account |
| Gateway settlement | Matched to batched payments | Automatic | Works with the payment gateway setup |
| Returned or bounced instrument | Reversal against the original | Assisted | Reinstates the receivable rather than netting it |
Built against your own statement history, so the rules are proved on transactions whose answers you already know.
Your bank's actual export is mapped once — column order, date format, how debits and credits are represented, and where the narration sits. This differs by bank far more than people expect.
Past statements are analysed for recurring patterns, which is what identifies the rules worth writing. Most businesses find a small number of patterns cover the bulk of their volume.
Narration rules, party rules and charge rules are configured and tested against the historical statements, where you can immediately see whether a rule matched correctly.
Reconciliation moves to daily or every other day, with a named owner. This is the change that actually reduces effort; the tooling only makes it feasible.
A short session on resolving unmatched items, including when to hold on account and when to escalate, so the queue is cleared by whoever is there rather than by one person.
Timeline shown is indicative and assumes statements are available in a machine-readable format. PDF-only statements need a conversion step first.
Reconciliation attracts optimistic expectations. These are the honest boundaries.
The realistic target is that reconciliation stops being a month-end event. Complete automation is not the goal and is not achievable.
Where the bank offers a corporate feed, yes. For many Indian banks the practical route remains a scheduled statement download and import, which is why the mapping is set up once and works thereafter. Either way the matching behaviour is identical.
It depends almost entirely on what your bank narration contains. Payments carrying an invoice reference or a recognisable payer name match reliably; anonymous UPI credits do not, and no configuration changes that. The realistic outcome is a short daily queue rather than a month-end exercise.
That is handled directly — a single credit is allocated across multiple outstanding invoices with any residual held on account. It is one of the more common patterns in Indian receivables and a one-to-one matcher simply cannot cope with it.
No. Charges, fees and interest identified by rule create their own journal entries during reconciliation. Requiring them to be posted in advance is precisely what makes manual reconciliation slow.
Yes, and most businesses do. The import handles your bank's own CSV or XLSX format directly once mapped, so it is a file upload rather than a reformatting exercise.
Daily, or close to it. The effort is not proportional to frequency — it is proportional to how much context has been lost. A credit reviewed the same day is usually identifiable by whoever handles that account; the same credit four weeks later frequently is not.
A short call about how far behind reconciliation is today and what your bank narration actually tells you.
ERPNext and Frappe are trademarks of Frappe Technologies Pvt. Ltd. References to UPI, NEFT and MT940 describe payment and messaging standards operated by their respective authorities and are used here for identification only.
