Bank Reconciliation & Open Banking

Key Features

`Bank Statement` and `Bank Statement Line` DocTypes with idempotent import that de-duplicates transactions by bank reference and value date

Statement ingestion from CSV, MT940 and CAMT.053 (ISO 20022) with per-bank column/field mapping templates

Open-banking / aggregator feed connector polled on a `scheduler_events` job, with encrypted credential storage and token refresh

`Reconciliation Rule` DocType: ordered, weighted match conditions (exact ref, amount tolerance, date window, counterparty name similarity, party map)

Server-side matching engine run via `frappe.enqueue` background jobs so multi-thousand-line imports never block the desk

Auto-proposes matches against existing Payment Entries, Journal Entries, Sales/Purchase Invoices and unreconciled GL entries

One-click creation of the settling Payment Entry or Journal Entry on match confirmation, respecting company defaults

Split and partial-settlement handling for bundled payouts (Stripe/PayPal/marketplace) and part-paid invoices

Configurable suspense/clearing account so unmatched or ambiguous lines are parked and auditable, never dropped

Multi-bank and multi-company mapping — each feed bound to a Bank Account + Company with its own rule set

Multi-currency with FX gain/loss posting to nominated accounts and bank-charge auto-allocation

`hooks.py` doc events on Payment/Journal Entry keep reconciliation status consistent through amend and cancel

Keyboard-driven review workspace (client script) for fast match / split / ignore, with running matched-vs-unmatched totals

Dedicated Role + Role Profile and Permission Level rules for clerks, approvers and auditors

Whitelisted REST API methods to push statements and pull reconciliation status from external treasury tools

Reconciliation audit log and exportable exception report for month-end close and external audit

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your ERPNext.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Most finance teams hit the same wall in ERPNext: month-end bank reconciliation is still largely manual. ERPNext core ships a Bank Reconciliation Tool and a Bank Statement Import, but matching is one bank statement at a time, largely by hand, with limited fuzzy logic and no live bank feed. There is no native open-banking connection, no persistent multi-condition matching rules, and weak handling of the messy real-world cases — partial settlements, bundled payouts (Stripe, PayPal, marketplaces), FX differences, and bank charges — so reconciling hundreds of lines a month becomes a multi-day slog and the GL drifts out of trust.

This build-to-order app closes that gap as a proper Frappe application installed on your bench. We add a Bank Statement and Bank Statement Line DocType pair that ingests transactions from CSV, MT940/CAMT.053, or a live open-banking/aggregator API, plus a Reconciliation Rule DocType where you define ordered, weighted matching conditions (exact reference, amount within tolerance, date window, counterparty name similarity, party mapping). A server-side matching engine — implemented as whitelisted methods with frappe.enqueue background jobs so large imports never block the UI — proposes matches against existing Payment Entries, Journal Entries, Sales/Purchase Invoices and unreconciled GL rows, and can auto-create the settling Payment or Journal Entry on confirmation.

Technically it is wired the ERPNext-native way. hooks.py doc events on Payment Entry and Journal Entry keep reconciliation state in sync when documents are amended or cancelled; scheduler_events (cron/hourly) poll the open-banking feed and refresh pending statements; a client script on the reconciliation workspace gives reviewers a fast keyboard-driven match/split/ignore screen. Unmatched or ambiguous amounts route to a configurable suspense/clearing account so nothing is silently dropped, and everything respects ERPNext permissions — we ship a dedicated Role and Role Profile plus Permission Level rules so approvers, clerks and auditors see the right scope. Multi-bank and multi-currency are first-class: each feed maps to a Bank Account and Company, and FX gain/loss on settlement posts to the accounts you nominate. Reads and writes are also exposed over the Frappe REST API so an external cash-management or treasury tool can push statements or pull reconciliation status.

Because this is build-to-order, you are not downloading a fixed app off a marketplace — ECOSIRE builds your version around your banks, statement formats and chart of accounts. Engagement starts with a short scoping call to confirm banks, feed method (file vs. API/aggregator), currencies and match tolerances. We build on a staging bench, run UAT against your real (sanitised) statements, then install on your production site (Frappe/ERPNext v15 or v16, self-hosted or Frappe Cloud). Typical delivery is 2-4 weeks from confirmed scope, and you receive the full source in a git repository along with a post-go-live support window.

What you get

Installable source code for your version of the app, delivered as a proper Frappe app on your bench (Frappe/ERPNext v15/v16)

Installation and configuration on your ERPNext site: bank accounts, feed mapping templates, rules, suspense accounts and roles

Technical documentation — DocType schema, hooks, scheduler events, whitelisted API endpoints and rule syntax

End-user guide plus a live training session for your finance team on the reconciliation workspace and exception handling

UAT on a staging bench against your real sanitised statements, with an agreed rollback plan before production cutover

Post-go-live support window for bug fixes and match-rule tuning

Full git repository handover with commit history and README/build instructions

Sample MT940/CAMT/CSV mapping templates for your specific banks

Who this is for

Finance Manager / Controller

Owns month-end close and wants bank reconciliation to stop being a multi-day manual grind. Needs a trustworthy GL, a visible suspense/clearing account for open items, and an exception report for the auditors.

Accounts / AP-AR Clerk

Reconciles hundreds of lines daily and wants the software to propose matches, not force line-by-line hunting. Values the keyboard-driven match/split/ignore workspace and auto-created settlement entries.

ERP / Systems Administrator

Runs the Frappe/ERPNext bench and cares about clean install, encrypted bank credentials, scheduler health, permission scoping and a git repo they can maintain across v15/v16 upgrades.

Group / Multi-Entity Finance Lead

Oversees several companies, banks and currencies in one ERPNext instance and needs per-bank rule sets, correct FX gain/loss posting and consolidated reconciliation status.

How Bank Reconciliation & Open Banking Compares

Criterion	ECOSIRE	Custom Build	Competitor	ERPNext Native
Bank feed / open banking	File import plus optional live open-banking/aggregator feed on a scheduler job	Whatever you have time to build and maintain	Usually file import only, few offer live feeds	No live feed; manual Bank Statement Import only
Auto-matching engine	Weighted multi-condition `Reconciliation Rule` engine with review queue	Bespoke logic you specify and debug yourself	Basic fixed matching, limited tolerance/fuzzy logic	Manual tool, one statement at a time, minimal fuzzy match
Suspense / clearing handling	Configurable suspense account + auditable exception report	Only if you design it in	Rarely handled explicitly	Not a first-class concept
Multi-bank / multi-currency	Per-bank rule sets, per-company mapping, FX gain/loss posting	Possible but significant extra build	Often single-bank, weak FX handling	Multi-currency GL exists but no reconciliation automation
Fit to your banks & COA	Built around your statement formats, banks and chart of accounts	Fully bespoke by definition	Generic; you adapt to its assumptions	Generic core behaviour
Delivery model	Build-to-order, 2-4 weeks from confirmed scope, source in git	Months of in-house dev and QA	Instant download but fixed feature set	Already installed, but leaves the gap unsolved
Support & updates	Post-go-live support window + v15/v16 upgrade path	Your team owns all maintenance	Varies; often subscription-locked	Community/ERPNext release cycle only
Source & lock-in	Full git repo handover, no subscription lock-in	You own it, at full build cost	Often closed or license-gated	Open source but no added functionality

Frequently Asked Questions about Bank Reconciliation & Open Banking

How long does delivery take?

This is build-to-order, so there is no instant download. After a scoping call to confirm your banks, statement formats, currencies and match tolerances, typical delivery is 2-4 weeks from confirmed scope. Complex multi-bank open-banking integrations sit at the upper end; a CSV/MT940-only build is usually faster. You get a firm timeline in the quotation.

What ERPNext and Frappe versions are supported?

We build for Frappe/ERPNext v15 and v16, on self-hosted benches or Frappe Cloud. We confirm your exact version during scoping and ship the app tested against it so it installs cleanly with `bench get-app` / `bench install-app`.

How do updates and support work after go-live?

Every engagement includes a post-go-live support window for bug fixes and match-rule tuning. Because you receive the full source in a git repository, you can maintain it yourself, or contract ECOSIRE for ongoing support, new bank feeds and version-upgrade compatibility. We do not force a subscription to keep your app running.

Can it connect to a live bank feed, or is it file-based only?

Both. We can build file-based import (CSV, MT940, CAMT.053) and/or a live open-banking/aggregator API connector polled on a Frappe scheduler job. Live feed availability depends on your bank or aggregator supporting an API in your region — we confirm what is feasible for your specific banks during scoping.

How does the auto-matching actually decide a match?

Matching is driven by a `Reconciliation Rule` DocType where you define ordered, weighted conditions — exact reference, amount within a tolerance, date window, counterparty name similarity and party mapping. The engine scores candidate Payment Entries, Journal Entries, invoices and open GL lines, auto-confirms high-confidence matches, and routes ambiguous ones to a review queue rather than guessing.

What happens to transactions that don't match anything?

Nothing is silently dropped. Unmatched or ambiguous lines are parked against a configurable suspense/clearing account and surfaced in the exception report and review workspace, so open items stay visible and auditable until a human resolves them.

Does it handle multiple banks and currencies?

Yes. Each feed maps to a specific Bank Account and Company with its own rule set, and multi-currency is first-class — FX gain/loss on settlement posts to accounts you nominate and bank charges can be auto-allocated. This suits multi-entity groups running several banks in one ERPNext instance.