A build-to-order ERPNext app that turns manual bank-transfer collections into an auto-reconciling flow using per-invoice virtual accounts, statement import, and reference-code matching. ECOSIRE scopes, builds, installs, and supports it for your ERPNext v15/v16 site. Built to order by ECOSIRE for ERPNext v15, v16 — indicative price from $249.00 USD; request a quote for a scoped proposal.

A build-to-order ERPNext app that turns manual bank-transfer collections into an auto-reconciling flow using per-invoice virtual accounts, statement import, and reference-code matching. ECOSIRE scopes, builds, installs, and supports it for your ERPNext v15/v16 site.
Aucun paiement maintenant. Ceci envoie une demande de devis à notre équipe — nous vous recontacterons par e-mail avec les tarifs et les prochaines étapes.
If your customers pay by bank transfer, ERPNext's native Payment Entry and Bank Reconciliation Tool leave you doing the hardest part by hand. A finance clerk stares at a bank statement, guesses which incoming credit belongs to which Sales Invoice, hunts for a half-remembered reference in the narration field, and manually creates and matches Payment Entries one by one. For B2B and emerging-market merchants where transfer is the dominant rail, this is slow, error-prone, and it delays order fulfilment because you cannot confirm payment in real time. ERPNext gives you the accounting ledgers and a basic reconciliation screen, but it has no concept of a per-invoice collection identity, no automated ingestion of the incoming payment stream, and no way for a customer to prove they paid.
`Virtual Account` DocType that mints a unique IBAN/account number (where the bank supports it) or a deterministic reference code per Sales Invoice or per customer
`hooks.py` `doc_events` on Sales Invoice submit auto-provisions the virtual account or reference and stamps it onto the invoice and its print format
Statement ingestion for CSV, MT940, and CAMT.053 via a mapped `Bank Statement Import` DocType, plus optional scheduled bank-API pull
Matching engine that scores incoming `Bank Transaction` credits against open invoices by VA number, reference code, amount, and payer name
Auto-creation and submission of the correct `Payment Entry` for high-confidence matches through a whitelisted server-side method
Configurable confidence thresholds and amount tolerances so partial or slightly-off transfers route to review instead of mis-posting
We build a proper Frappe app that closes that gap. At its core is a Virtual Account DocType that mints a unique collection identity — a dedicated IBAN/account number where your bank supports virtual accounts, or a deterministic reference code (for example INV-2026-00042-7Q) where it does not — bound to a specific Sales Invoice or customer. A Bank Statement Import DocType plus a mapped parser ingests statements (CSV/MT940/CAMT.053, or a bank API pull via a scheduled job) into Bank Transaction rows, and a matching engine scores each incoming credit against open invoices by virtual-account number, reference code, amount, and payer name. High-confidence matches auto-create and submit the Payment Entry against the correct invoice via a server-side whitelisted method; ambiguous ones land in a review queue for a human to confirm with one click.
Technically it ships as a versioned Frappe app installed onto your bench — new DocTypes, a dedicated module, hooks.py doc_events (on Sales Invoice submit we provision the virtual account / reference; on Bank Transaction insert we run matching), server scripts and whitelisted API methods for the reconciliation logic, and scheduler_events for the periodic statement pull and stale-reference cleanup. Customers get a portal page (or a Web Form) to see exactly where to send funds and to upload a proof-of-payment, which posts through the Frappe REST API and raises a review task. Access is governed by role profiles and permission rules so that AR clerks reconcile, approvers confirm, and auditors read — with the full Frappe audit trail behind every posted entry. It targets Frappe/ERPNext v15 and v16, and integrates with your existing Chart of Accounts, bank accounts, and multi-currency setup rather than sitting beside them.
Because every bank's statement format, rail (SEPA/IBAN vs local domestic transfer), and provisioning capability differs, this is build-to-order rather than a one-click marketplace download. We start with a short scoping call to confirm your banks, rails, statement formats, and matching tolerances, then build against your actual data on a staging bench. Typical delivery is 2-4 weeks from confirmed scope. You receive the installable source for your version, a documented install and configuration on staging, UAT, and a supported go-live — not a black box.
Sells to businesses that pay by wire/transfer against invoices. Needs each incoming credit tied to the right Sales Invoice automatically so orders can be released the moment funds arrive, without a clerk reconciling by hand.
Operates where cards are rare and local bank transfer or IBAN is how most customers pay. Needs reference-code reconciliation and a proof-of-payment flow that works even where the bank offers no true virtual accounts or API.
Owns the Bank Reconciliation Tool today and spends hours matching statement lines to invoices. Wants auto-matching for the obvious cases and a clean exception queue for the rest, with a full audit trail for approvals.
Runs the bench and cares about a clean, versioned Frappe app: proper DocTypes, hooks, permissions, and v15/v16 compatibility they can maintain and upgrade rather than a pile of untracked server scripts.
Achetez la licence sur ecosire.com et téléchargez le ZIP de l'application Bank Transfer & Virtual Accounts for ERPNext depuis le tableau de bord de votre compte.
Extrayez le ZIP dans le dossier d'applications de votre banc ou exécutez « bench get-app » avec le chemin d'accès à l'application extraite.
Exécutez `bench --site SITE_NAME install-app APP_NAME` suivi de `bench migrate` pour installer Bank Transfer & Virtual Accounts for ERPNext et appliquer son schéma.
Ouvrez les paramètres de licence ECOSIRE sur votre site et activez votre clé de licence. Nécessite les applications gratuites ecosire_connect et ecosire_license_client.
| Critère | ÉCOSIRE | Construction personnalisée | Concurrent | Odoo natif |
|---|---|---|---|---|
| Per-invoice virtual account / reference | Auto-minted VA or reference DocType per invoice | Possible but you design and build it | Rarely offered; generic gateway focus | |
| Statement ingestion | CSV/MT940/CAMT.053 + optional API pull | Whatever you find time to implement | Often card-only, no statement parsing | |
| Auto-reconciliation | Scored auto-match + exception queue | Depends on in-house effort | Limited or rule-light matching | |
| Proof-of-payment flow | Portal upload via REST API + review task | Must be designed from scratch | Usually absent | |
| Fit to your bank & rails | Built to your banks, IBAN/local rails | Fully bespoke if you resource it | Generic; may not fit local rails | |
| ERPNext v15/v16 fit | Versioned app pinned to your bench | You own compatibility upkeep | Varies; may lag versions | |
| Support & handover | Support window + git repo + training | Only what you document | Vendor support, no source | |
| Total cost profile | Fixed build-to-order scope | Unpredictable dev + maintenance | Subscription, uncertain fit |
No. It is build-to-order. Every bank's statement format, rail, and virtual-account capability differs, so ECOSIRE scopes, builds, and installs it against your actual ERPNext site and bank data rather than shipping a generic one-click download.
Typically 2-4 weeks from confirmed scope. After a short scoping call we build on a staging bench against your real invoices and sample statements, run UAT, then support go-live. Complex multi-bank or bank-API integrations can extend the timeline, which we flag during scoping.
Every build includes a post-go-live support window for defect fixes and reconciliation tuning. You receive the full git repository and source, so your team can maintain it; ECOSIRE also offers ongoing support and v15-to-v16 upgrade work as a separate engagement.
Yes. Where true per-invoice IBANs are not available, we use deterministic reference codes stamped on each invoice and its remittance instructions, then match incoming credits on reference, amount, and payer name. Where your bank does support virtual accounts or an API, we use those for even tighter matching.
Frappe/ERPNext v15 and v16. We support SEPA/IBAN and local domestic transfer rails, and ingest statements as CSV, MT940, or CAMT.053, with an optional scheduled bank-API pull where your bank exposes one.
The matching engine only auto-posts high-confidence matches; anything ambiguous or partial routes to a human review queue. Idempotent posting guards and duplicate-credit detection mean a re-imported statement never creates a second Payment Entry, and every posted entry links back to its source Bank Transaction for audit.
As a proper Frappe app with its own module and DocTypes, `hooks.py` doc_events for provisioning and matching, whitelisted server-side methods for posting Payment Entries, scheduler_events for statement pulls, and role-profile permissions. It integrates with your existing Chart of Accounts and bank accounts rather than replacing them.
A build-to-order ERPNext app that turns manual bank-transfer collections into an auto-reconciling flow using per-invoice virtual accounts, statement import, and reference-code matching. ECOSIRE scopes, builds, installs, and supports it for your ERPNext v15/v16 site.