What ERPNext bank reconciliation does and when your team needs it
Every month, the cash balance in the ledger and the balance on the bank statement drift apart. Bank fees post late, customer receipts clear after the cutoff, and some payments are entered twice or not at all. ERPNext's Bank Reconciliation Tool is the place where finance teams close that gap. It takes Bank Transactions, the lines imported from a bank statement or fed from a bank connection, and matches each one against a Payment Entry or Journal Entry already recorded in the ledger. Each Bank Account record is linked to a General Ledger account, so the matching works against the cash or bank account that the statement belongs to. If that link is wrong or missing, the tool has nothing reliable to reconcile against, which is why the account setup comes first.
Set this up before go-live, not after. Opening balances, historical statements and the first few months of live transactions all depend on the bank accounts, their ledger links and the currency settings being right from day one. Once a year of unreconciled activity has built up, the cleanup is slower and harder to audit than the routine itself. Confirm in the documentation for the ERPNext version you run how the Bank Reconciliation Tool, Bank Transactions and bank feed options are named and behave, because menu paths and matching options have changed between major releases. Check with your own finance lead which bank accounts, currencies and payment channels must be covered at launch, and whether your bank supports the statement format or connection method you plan to use.
A practical first step is to list every bank and payment account the business uses, then confirm each one maps to a single ledger account with a clear owner. Ask who will perform the monthly reconciliation, who approves it, and what evidence the finance team keeps for the auditor. These decisions shape the permissions, the import routine and the reporting that come later. An implementation partner can help define these ownership and control points before the first statement is loaded, so that the reconciliation process is designed around your accounts rather than adjusted after the first close.
Statement import or Plaid sync: which feed fits your bank setup
A statement import brings bank lines into ERPNext from a file that someone downloads from the bank and loads into the system. The feed is only as current as the last upload, so the process depends on a person repeating the step on a schedule that your month-end calendar can support. ERPNext's general Data Import tool accepts CSV and Excel files, and its documentation advises importing a few thousand records at a time, so confirm whether bank statement uploads follow the same limits.
- Bank and country coverage: Confirm the export formats each of your banks offers and whether your ERPNext version accepts them directly or needs a mapped file prepared by your team.
- Review effort: Every upload adds lines to review, and the effort grows with transaction volume and the number of bank accounts.
- Data handling: The statement file stays inside your environment and follows your own storage and retention rules, with no third party in the data path.
- Credential ownership: Your staff control bank portal access and download rights, so access reviews cover named people rather than a connector.
- Timing gaps: Lines appear only after a file is produced, so late postings and intraday movements reach the books later.
Check the export format from each bank, the upload template for your ERPNext version, and how the system handles overlapping date ranges that could create duplicate lines.
A Plaid connection pulls transactions from linked bank accounts on an ongoing basis through a third-party data aggregator. The work shifts from downloading files to reviewing a continuous stream, but the connection adds a vendor, consent flows and a dependency on bank availability. Plaid's coverage differs by institution and jurisdiction, so the first step is confirming support for each account you need to reconcile, not assuming it from the product name.
- Bank and country coverage: Confirm that each institution and country is supported and that the ERPNext integration you plan to use works with the Plaid products your account includes.
- Review effort: Feeds arrive continuously, which reduces batch uploads, but you still need a set review cadence so unmatched lines do not accumulate between closes.
- Data handling: Transaction data passes through Plaid before it reaches ERPNext, so your data processing terms, the location of processing and the retention period need approval from your privacy and security owners.
- Credential ownership: Bank logins are entered through the bank's consent flow, so you must assign a named owner for each connection, along with the renewal and revocation process.
- Dependency and failure: Broken connections, re-authentication prompts and institution outages can stop the feed without an obvious error, so monitoring and alerting need to be designed in.
Confirm coverage for every account, the integration version in your release, and who receives an alert when a connection needs attention.
Whichever feed you choose, the books are only as reliable as the checks you run before the first live reconciliation. The checks below apply to both paths and focus on evidence an auditor or controller will ask for. They also test the failure modes that are easy to miss when a feed looks healthy on the surface.
- Source traceability: Confirm that each Bank Transaction keeps a reference to the statement line or feed record it came from, so a reviewer can trace it back to the bank's data.
- Opening balance and cutoffs: Test that the ERPNext bank account balance matches the bank's statement balance at an agreed date before you rely on the matching workflow.
- Duplicate prevention: Re-import an overlapping period, or simulate overlapping feed data in a test site, and confirm that duplicate Bank Transactions are not created.
- Access and segregation: Decide who may import, match and approve reconciliation entries, and restrict those actions through role permissions so the person who posts payments does not also approve their own matches.
- Version and vendor review: Record the ERPNext and Frappe Framework versions you run, check their support status on the Frappe support versions page, and re-test after upgrades.
Run at least one period in parallel with your existing reconciliation process before you switch the primary feed, and document the differences you found and how each was resolved.
Configuration options and when each one fits
This table compares the main configuration choices for ERPNext bank reconciliation and shows the review time each one tends to leave with your team. Read each row against your transaction volume, number of bank accounts and how many people sign off the monthly close. The main takeaway is that automation reduces routine review but does not remove the need for someone to own exceptions.
| Configuration choice | How it works in ERPNext | When it fits | Review time it leaves |
|---|---|---|---|
| Bank Account per company and currency | Each bank account is linked to one company and one currency, with its GL account and party type set on the record | Multi-company groups or multi-currency treasury, where each account must post to the right ledger | Low once set up, but a wrong company or currency link causes repeated mismatches that someone must trace |
| Single shared bank account | One Bank Account record serves several sub-ledgers or cash pools | Small entities with one operating account and a single reviewer | Higher, because reviewers must sort mixed flows by hand |
| Statement import with column mapping | A CSV or Excel statement is uploaded and its columns are mapped to Bank Transaction fields such as date, description, deposit and withdrawal | Banks that do not offer a supported live feed, or teams that receive statements on a fixed schedule | Moderate, because each new bank format needs a mapping check and dates or decimal formats can need correction |
| Live bank feed through Plaid | Transactions sync into Bank Transactions automatically, subject to the connection and bank support you confirm | High transaction volume and banks supported by the connector in your region | Lower for routine items, though the connection, credentials and coverage need periodic review |
| Auto-matching rules | The system proposes matches to Payment Entries, Sales Invoices or Journal Entries based on amount, reference and party | Recurring customer receipts and supplier payments with consistent references | Low for clean matches, but false matches must be caught in review before the period closes |
| Manual matching | Reviewers link each Bank Transaction to a voucher by hand | Irregular flows, small volumes or newly onboarded accounts where patterns are not yet known | High, scaling with transaction count |
| Bank fees through expense accounts | Fees are recorded as Bank Transactions and allocated to an expense account with a cost center or dimension | Accounts with card, wire or account-maintenance charges that appear as separate lines | Low when a standing rule covers each fee type, high when fees are booked ad hoc |
| Timing differences such as outstanding cheques | Issued but uncleared payments remain open against the bank account until the statement shows them clearing | Organizations that issue many cheques or pay across month end | Moderate, because each open item needs follow-up at close and clears only on a later statement |
How to set up bank reconciliation in ERPNext step by step
This sequence takes a company from an empty bank setup to a routine where ERPNext's bank balance matches the statement at each month-end, with a check at every stage so gaps surface early.
Confirm company, currency and chart of accounts
Before any bank record exists, the finance lead confirms the company, its default currency and the chart of accounts, including the ledger accounts that will represent each real bank account. Each bank account must sit under the correct company, and its currency must match the statement currency. The step is done when the company and currency on the planned Bank Account records match the bank's own documentation, and the ledger account for each bank is identified. Mismatched currency or company here causes problems later, so confirm them with the bank and your finance team before continuing.
Create bank accounts linked to ledger accounts
An accountant creates a Bank Account record for each bank account and links it to the matching asset ledger account in the chart of accounts. Each record should carry the bank name, account number reference and currency. The check is that the Bank Account record shows the correct linked ledger account and that its ledger balance is zero or matches the opening position you expect. If a bank account has two linked ledgers or the link points to a non-bank account, correct it now, because the Bank Reconciliation Tool reads balances through that link.
Load opening balances and confirm the starting position
The accountant posts opening balances, either through a Journal Entry or the opening entry process your team has agreed, so each bank ledger starts at the closing balance from the bank's last statement before go-live. Opening entries should be posted against an equity or opening account, not against the bank itself as a plug. The check is a side-by-side comparison: the ledger balance in ERPNext for each bank account must equal the bank's closing balance on the cut-off date. Any difference must be explained by items still in transit and listed, not absorbed into the opening entry.
Connect a bank feed or import the first statement
Choose the transaction source for each bank account. ERPNext can receive bank transactions through a supported bank feed integration, or through a statement import as a CSV or Excel file that matches the Bank Transaction Import format. Confirm with your bank and your integration provider which option applies, whether the feed covers each account, and how often it refreshes. The check is that the first import or feed run creates Bank Transaction records with dates, amounts and descriptions matching the statement line for line, and that the count of imported lines matches the count on the statement for the period.
Run the Bank Reconciliation Tool on the first period
The accountant opens the Bank Reconciliation Tool, selects the bank account and period, and works through unreconciled Bank Transactions on the left against candidate Payment Entries and Journal Entries on the right. Accept system suggestions only after checking amount, date and reference. Where a bank line has no matching voucher, such as a bank charge or interest, create the entry from the tool and post it to the right expense or income account. The check is that every line in the period is either matched or has a deliberate, documented entry, with no lines left in an unexplained suspense state.
Handle fees, timing differences and unmatched items
Bank fees, interest and timing differences need separate treatment. Fees and interest should be recorded through journal entries to the agreed expense or income accounts. Outstanding cheques and deposits in transit are timing differences that should remain visible as unreconciled items until they clear the bank. Review the list of outstanding items each period so none sit indefinitely. The check is that the difference between the ledger balance and the statement balance equals the sum of documented outstanding items, and that no item is unexplained.
Verify the closing balance against the statement
At the end of the period, the accountant compares the ERPNext ledger balance for each bank account with the closing balance on the bank statement, then subtracts documented outstanding items to confirm the reconciled balance. The step closes when the reconciled figures agree and a reviewer signs off. Keep the statement, the reconciliation output and the list of open items together so an auditor can trace each balance. If the figures do not agree, do not close the period until the difference is found.
Make month-end reconciliation a routine
Assign an owner for each bank account, set a fixed month-end review, and document who approves the reconciliation. Review recurring fees and matching rules so the same items are classified the same way each time. Confirm with your team which reports they will use to monitor unreconciled transactions. The step is complete when a full cycle runs without manual rework of the opening setup, and each account has a named owner and a written review record for each period.
How to match Bank Transactions to payments, journals and fees
The core task is deciding, for each imported Bank Transaction, whether it settles an existing document or needs its own journal entry. In ERPNext, the Bank Reconciliation tool proposes candidate vouchers from the same bank account and amount range, and the candidates you should expect to see are Payment Entries, Journal Entries and, for some flows, sales and purchase invoices that the Payment Entry will settle. Review the candidate list before accepting it, because the tool ranks by amount and date proximity, not by the remittance reference on the statement. Partial payments are handled by allocating one Bank Transaction across several vouchers in a Payment Entry, and a single customer receipt that covers several invoices should be recorded that way rather than forced into one invoice. Split transactions where the bank nets fees or combines several customer receipts need a deliberate decision: either record the gross receipt and post the deduction as a separate expense line, or match the net amount and accept that the gross customer invoice stays partly open until you correct it.
Bank fees, interest and foreign exchange differences should not be squeezed into an existing voucher. Post bank charges and interest as Journal Entries against the expense and income accounts your chart defines, and match the resulting bank line to that journal. For FX differences on foreign currency accounts, confirm with your accountant which exchange gain or loss account applies and how the rate used on the bank statement is recorded, since the rate in ERPNext and the rate the bank applied can differ. Set up a written exception policy before go-live. Unmatched items should sit in a visible queue with an owner, a due date and a reason code such as missing invoice, duplicate, unknown payer or timing. Require that only a named role can create journal entries used to clear exceptions, that every clearing entry references the bank line it resolves, and that a second person reviews any exception older than the close calendar allows. Automatic suggestions reduce manual work, but they are not a guarantee of accuracy, so plan a sample check of matched items each month and confirm the approval thresholds with your finance and audit leads.
Security and access controls for bank data in ERPNext
Bank statements and feed credentials expose cash position, supplier payments and customer receipts, so access has to be designed before the first import. The cards below cover who can import and match, how roles and permissions are set on bank records, how Plaid credentials are protected, how reconciled entries stay traceable, how statement files are kept, and where the data physically runs.
Who imports and who approves
Separate the people who upload statements from the people who confirm matches. In ERPNext, a single user who can both import a Bank Statement and reconcile Bank Transactions can post cash entries without a second check. Define which roles can create Bank Transactions, which can run reconciliation, and which can submit the resulting Payment Entries or Journal Entries. Confirm these splits in a test site with non-admin users before go-live, because System Manager and Accounts Manager roles often carry more rights than teams expect.
Role permissions on bank records
Set role permissions on Bank Account and Bank Transaction deliberately rather than relying on defaults. Bank Account holds the account numbers and linked GL accounts, so restrict edit rights to a small finance group and use User Permissions where a user should see only one company or one bank. Check read, write, submit and cancel rights separately, since cancelling a reconciled transaction can reopen a closed period. Review the permission report after each role change.
Plaid credentials and tokens
If you connect a bank feed through Plaid, the client ID, secret and access tokens are the highest-value secrets in the setup. Store them in your secrets management approach, not in site configuration files shared with developers, and restrict who can open the integration settings. Rotate credentials when staff with access leave. Confirm with your Plaid agreement and the ERPNext integration documentation where tokens are stored and how they are refreshed, and document the owner of each key.
Audit trail for reconciled entries
Reconciliation is only defensible if each match can be traced back to the statement line, the payment or journal, and the user who confirmed it. Keep Bank Transaction records linked to their vouchers, and do not allow reconciled items to be deleted or silently edited. Use ERPNext's version history and activity logs to review changes, and confirm with your auditors which evidence they will request, such as the statement file, the match record and the approver's identity.
Statement file storage and retention
Imported statement files contain account numbers, balances and counterparty names, so treat them as sensitive records. Decide where uploaded files are stored, who can download them through the File DocType, and how long they are kept. Set a retention period that matches your finance and tax obligations, and plan deletion or archiving with a documented procedure. Ask your legal and compliance team to confirm the period, because no default retention rule should be assumed.
Hosting inside your infrastructure
Where ERPNext runs determines who can reach bank data outside your own controls. Self-hosting on bench, Docker Compose or Kubernetes keeps the database, file storage, backups and background workers inside your network, while a shared hosted plan places them in the provider's environment. Restrict database and Redis access to application hosts, terminate TLS at your own reverse proxy, and make sure backups are encrypted and stored in the same jurisdiction you have approved. Confirm each choice against your data residency policy before selecting a deployment model.
Making month-end reconciliation a routine, not a project
A repeatable month-end reconciliation needs a fixed calendar, named owners and a sign-off step before the period closes. Set a cadence in which statements are pulled or sync status is checked on a set day each week, with a final pass in a defined review window after the last posting date of the month. Assign the Bank Transactions review to an accounts role, the review of old unmatched items to a senior accountant, and the period sign-off to the controller or finance lead. Write these owners into your close checklist so the work does not depend on whoever happens to be available.
Escalation rules keep the list of unmatched Bank Transactions from growing silently. Decide in advance how old an unmatched item may be before it goes to the controller, and what each category needs: a fee that should be posted to an expense account, a timing difference that will clear, or a payment that was never recorded and needs investigation. Treat each category as a decision with an owner and a date, not a note. Ask your implementation partner to confirm which ERPNext reports or filters show unmatched items by age and by bank account in your version, so the escalation list can be produced without manual exports.
Operational tasks depend on how ERPNext is hosted. Someone must monitor the background jobs that process imports and feed syncs, check error logs after each scheduled pull, and confirm that a failed bank feed is noticed before month end rather than during the close. On Frappe Cloud, some of this monitoring and job visibility is handled through the platform. On a self-hosted bench, Docker Compose or Kubernetes setup, your infrastructure team owns the worker, scheduler and log checks, and their runbook should state who responds to a failed sync. Confirm these responsibilities with your hosting provider or internal team before go-live, because a reconciliation routine that depends on an unmonitored job will fail quietly.
Limits to confirm for your bank, country and ERPNext version
Bank reconciliation in ERPNext depends on four things working together: your bank, your country, the ERPNext version you run and the way statements reach the system. Confirm each limit early, because a gap found after go-live usually means manual workarounds at every month-end.
Direct feed support by bank
Confirm that your bank is available through the direct feed route you plan to use, and that the feed delivers the transaction fields ERPNext needs to match, such as value date, amount, currency, reference and counterparty. Ask the bank whether it supports the account types you hold, including accounts in multiple currencies. Do not assume that a bank listed for one country works for every account it operates.
Plaid availability in your region
If you plan to sync through Plaid, confirm that Plaid covers your bank and country, and that the connection works for the account type and login method your finance team uses. Check how consent is renewed, who holds the credentials, and what happens when a bank changes its connection rules. Ask your bank and Plaid, in writing, rather than relying on a general coverage map.
Supported statement formats
For file imports, list every format your bank exports, such as CSV, Excel, MT940 or a national format, and test each with a copy of a real statement. Check column order, date formats, decimal separators and how the bank writes debits and credits. Confirm in the ERPNext version you run whether the import path accepts the format directly or needs a mapping step first.
ERPNext version and release in use
Confirm which ERPNext major version you run and whether it is still within the supported window, because support status affects which fixes you receive. Check the reconciliation behavior in the release notes for your version before you rely on a specific tool or report. Plan to repeat your reconciliation tests after each upgrade or minor release.
Multi-currency behavior
If you hold accounts in more than one currency, test how bank transactions, payment entries and journal entries carry exchange rates and gains or losses. Confirm which currency the bank account is set up in, how the statement amount is compared with the ledger amount, and where realized exchange differences are posted. Ask your finance lead to sign off on one worked example for each currency pair.
Server scripts for custom matching
If your matching rules need logic beyond the standard tools, such as matching on a customer reference inside a narrative, you may need a server script. From version 15, server scripts are disabled by default and must be enabled, and public shared Frappe Cloud benches do not allow them. Confirm where your ERPNext will run and who will maintain the script through upgrades.
Common questions about ERPNext bank reconciliation
How much effort does ERPNext bank reconciliation setup take?
Effort depends mainly on how many bank and payment accounts you run, how your statements arrive, and how clean your existing ledger is. Each bank account needs a Bank Account record linked to a ledger account in your chart of accounts, and each statement source needs its own import or feed setup. Multi-currency accounts, several legal entities and years of unmatched history add work because each one needs a decision about how it maps. Ask any partner to break the quote into account setup, statement import or feed configuration, matching rules, historical cleanup and training, so you can see which items your own data will push up.
Can our finance team run bank reconciliation in ERPNext on its own?
Many finance teams can run day-to-day reconciliation once it is configured, because matching Bank Transactions to payments and journals is a repeatable task. Initial setup is harder to do alone, particularly the mapping of bank accounts, the choice between statement import and a bank feed, and the handling of fees and timing differences. Teams with an experienced ERPNext administrator usually keep configuration in-house and bring in outside help only for the first setup or a later change. Ask a partner which parts they would hand over and which they would document for your team to repeat.
What do we need to provide before setup starts?
Expect to provide access to the bank accounts or feed provider that will supply transactions, a set of sample statements covering each account and format, and the chart of accounts with the ledger accounts that bank transactions should post to. You will also need a list of recurring fees, interest and payment processor deductions, and the names of people who approve reconciliations. If you plan to use a bank data aggregator such as Plaid, confirm with your bank and your legal team which data access terms apply before anyone requests credentials. Missing samples or unclear account ownership are the most common reasons setup stalls.
How long does go-live take, and what changes the timeline?
Go-live depends on the number of bank accounts, the state of historical data, and how quickly your team can review sample matches. Timelines extend when statement formats need custom handling, when a bank feed requires approval, or when several companies share one set of accounts. Parallel running for one or two closing cycles is common and adds time but reduces risk. Ask for a written timeline with milestones for account mapping, a test import, matching review and sign-off, and name the dependencies on your side such as bank approvals and access reviews.
Which bank feed approach should we choose: statement import or Plaid?
Statement import works with any bank that provides downloadable files, and it gives you direct control over what enters the system. A bank feed through Plaid can reduce manual uploads but depends on Plaid coverage for your bank, the data access terms you accept, and ongoing credential handling. Neither option removes the need for matching review. Compare them on bank coverage, data residency, the number of accounts, and how your security team wants third-party connections governed before you decide.
What recurring work remains after bank reconciliation goes live?
Recurring work includes importing or syncing statements on a fixed schedule, reviewing unmatched transactions, posting bank fees and interest, and checking that reconciled balances agree with the bank at each month-end. You will also need to update rules when a bank changes its statement format, when a new account opens, or when a feed connection expires and needs renewal. Plan a named owner for each account and a month-end checklist. Ask a partner whether support covers configuration changes after go-live, and whether that work is billed per request or through a retainer.
Does DeployOpen certify that our bank reconciliation is audit-ready?
No. DeployOpen configures ERPNext, documents the controls and prepares evidence such as reconciliation records, access settings and change logs. Independent auditors decide whether those controls meet your audit requirements, and certification bodies issue any certificates. Ask your external auditor which evidence they expect for bank reconciliation and share that list with the implementation team before setup begins, so the configuration and documentation are built to produce it.
Official ERPNext documentation to read before you configure
Before you create a bank account record or connect a statement feed, read the official ERPNext documentation and the source repository for the exact version you run. The version check comes first, because bank reconciliation behavior, the names of bank-related settings and the way Bank Transactions are matched can change between releases. The supported versions page at Frappe's supported versions page shows which major releases are current and when each one ends support, which should drive whether you configure against version 15 or version 16. The release history in the frappe/erpnext releases page shows how often minor versions ship, so your team knows to plan a patch review as part of the setup.
The ERPNext docs on the Data Import tool matter if you plan to load historical bank statement lines or opening balances from CSV or Excel files, since the documentation advises importing only a few thousand records at a time. For any custom matching logic, scheduled jobs or server-side changes to reconciliation, the Frappe docs on Server Scripts explain that scripts are disabled by default from version 15 and must be enabled with server_script_enabled. Confirm that setting with your hosting provider before you design around it, because Frappe Cloud public shared benches do not allow Server Scripts.
The frappe/erpnext repository is the place to confirm the app's current license, module structure and install paths, and the frappe/frappe repository covers the framework features your bank feed setup depends on. Ask your implementation team to record the ERPNext and Frappe versions in your configuration document, along with the exact documentation pages used, so that every later upgrade starts from a known baseline.
How DeployOpen scopes and delivers ERPNext bank reconciliation
DeployOpen plans, implements, integrates and documents ERPNext inside your own infrastructure, so bank reconciliation is designed around your bank accounts, your statement sources and your close calendar. Engagements are fixed-scope, with the work agreed in writing before any configuration starts.
How we scope
- Inventory every bank and payment account, currency and company that needs reconciling in ERPNext
- Confirm the statement source for each account: file import, bank feed provider or manual upload
- Map fee, interest and timing-difference cases to the accounts your accountants already use
- Agree in writing which Bank Transactions, payments and journal types are in and out of scope
How we build
- Configure Bank Account records, GL links and the import templates for your statement formats
- Set up matching rules and test them against a copy of recent statements and ledger data
- Validate Bank Transaction matches to payments, journals and fee entries with your finance team
- Document the posting conventions and exception handling so matching results can be reviewed
How we hand over
- Deliver a written configuration record covering accounts, rules, templates and permissions
- Provide a month-end reconciliation runbook that finance staff can follow without the build team
- Run a walkthrough with accountants on a sample close and record the open questions
- Agree the acceptance criteria and the evidence your auditors will ask to see before go-live
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover
- Review ERPNext release notes for changes that affect reconciliation before each upgrade
- Confirm with your bank or feed provider any change to statement formats or access before it affects imports
- Keep the runbook and configuration record current as accounts, banks and close steps change
