A build-to-order ERPNext app that turns a completed Payroll Entry into validated, bank-specific disbursement files (NACHA, SEPA, or your local format) and reconciles their status back into ERPNext. ECOSIRE builds it to your bank's spec, installs it, and supports it. 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 a completed Payroll Entry into validated, bank-specific disbursement files (NACHA, SEPA, or your local format) and reconciles their status back into ERPNext. ECOSIRE builds it to your bank's spec, installs it, and supports it.
ابھی کوئی ادائیگی نہیں۔ یہ ہماری ٹیم کو قیمت کی درخواست بھیجتا ہے — ہم قیمت اور اگلے اقدامات کے ساتھ ای میل کے ذریعے رابطہ کریں گے۔
Payroll teams running ERPNext close each pay cycle cleanly inside the system, then hit a wall at the last step: getting the money out. ERPNext HR & Payroll produces Salary Slips and a Payroll Entry, and it can post the accounting Journal Entry, but it does not emit a file your bank will actually accept. So the team exports to a spreadsheet, hand-keys beneficiary rows into the bank portal, or fights a template that breaks on a malformed IBAN or a record-count trailer that is off by one. On a 300-employee run that is hours of manual, error-prone work every month, with no audit trail of what was sent versus what cleared.
`Payroll Bank File` DocType linked to a submitted Payroll Entry, reading Salary Slips and Employee bank details for the run
Multi-bank layout engine driven by a `Bank File Template` DocType — NACHA/ACH, ISO 20022 pain.001, SEPA SCT, and local fixed-width/delimited batch formats configured, not coded
Server-side IBAN validation (ISO 7064 mod-97 checksum) and BBAN/account-number format checks per bank before file generation
`validate` and `on_submit` `hooks.py` doc events that block generation when net-pay totals, currency, or beneficiary data fail pre-flight checks
Batch export per pay run with correct file header, detail records, and trailer (record count, hash total, control sum) matching the bank spec
Checksum / hash-total generation and optional AES encryption of the output file at rest
ECOSIRE builds a proper Frappe app that plugs this exact gap. We ship a Payroll Bank File DocType that references a submitted Payroll Entry, reads the linked Salary Slips and Employee bank details, and renders a disbursement file in the exact fixed-width or delimited layout your bank mandates — NACHA/ACH for US banks, ISO 20022 pain.001 / SEPA credit transfer for European rails, or the local batch format your bank publishes (many GCC, South Asian, and African banks have their own). Bank layouts live in a Bank File Template DocType so a new bank is a configuration record, not a code change: you define field mapping, padding, header/trailer, hash/checksum rules, and the character set. A whitelisted server method (@frappe.whitelist()) drives generation, and a validate doc event plus server-side checks enforce IBAN checksum (ISO 7064 mod-97), account-number format, currency, and net-pay totals before a single byte is written — so the bank rejects nothing.
Technically it is a clean, upgrade-safe Frappe app: DocTypes, hooks.py doc events (validate, on_submit), server scripts for the bank-specific formatting logic, and an optional client script that adds a "Generate Bank File" button to the Payroll Entry form. Role-based permissions restrict generation to a Payroll Manager / Payroll Officer role profile, and every file write is logged with the operator, timestamp, run total, and record count for audit. Files can be AES-encrypted at rest and carry the bank's required checksum/hash-total trailer. A scheduler event polls or ingests the bank's return/acknowledgement file to flag each beneficiary as paid, returned, or rejected, writing status back onto the disbursement record so reconciliation is visible in ERPNext instead of in someone's inbox. Everything is exposed over the Frappe REST API for integration, and it targets Frappe/ERPNext v15 and v16.
Because this is build-to-order, we scope it to your actual bank(s) and payroll structure first. You send us a real (redacted) sample file spec from your bank; we confirm the format, edge cases, and multi-company or multi-currency needs on a short call, then build, test on a staging copy of your data, and hand it over installed and documented. Typical delivery is 2–4 weeks from confirmed scope. You receive the full source and git repository, so you are never locked to us — we support it, but you own it.
Owns the monthly pay cycle and needs a repeatable, error-free way to turn a submitted Payroll Entry into a file the bank accepts on the first upload — without spreadsheets or manual portal entry.
Cares about audit trail, dual control, and reconciliation. Wants every disbursement file logged with operator, totals, and record counts, and each beneficiary's paid/returned status reflected back in ERPNext.
Manages employee master data and bank details across multiple companies or currencies. Needs validation that catches a bad IBAN or missing account before payday, not after a bank rejection.
Wants a clean, upgrade-safe Frappe app — proper DocTypes, hooks, and role permissions — that survives ERPNext version upgrades and ships with source and docs rather than an opaque black box.
Buy the license on ecosire.com and download the Payroll Bank Disbursement File Generator app ZIP from your account dashboard.
Extract the ZIP into your bench's apps folder, or run `bench get-app` with the path to the extracted app.
Run `bench --site SITE_NAME install-app APP_NAME` followed by `bench migrate` to install Payroll Bank Disbursement File Generator and apply its schema.
Open the ECOSIRE License settings on your site and activate your license key. Requires the free ecosire_connect and ecosire_license_client apps.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Bank format coverage | Built to your exact bank spec — NACHA, SEPA, or local — configurable via template DocType | Whatever you build; usually one bank, hardcoded | Often one region/format, may not match your bank | |
| IBAN / account validation | Server-side ISO 7064 mod-97 + per-bank format checks pre-flight | Only if you build and maintain it | Basic or absent | |
| Reconciliation of paid/returned | Scheduler ingests bank return file, writes status back to ERPNext | Rarely built — extra effort | Usually not included | |
| Audit trail & controls | Operator, totals, record count, template version logged per file; role-gated | Depends on your discipline | Varies, often thin | |
| Delivery model | Build-to-order, 2–4 weeks, tested on staging, installed by us | Weeks to months of in-house dev time | Instant install but generic fit | |
| Source ownership | Full source + git repo handover — you own it | You own it (you wrote it) | Often closed source / license-locked | |
| Upgrade safety (v15/v16) | Clean Frappe app, no core patching, tested on v15/v16 | Depends on how it was built | Varies by vendor maintenance | |
| Ongoing support | Post-go-live window + optional retainer; format changes scoped fast | You maintain it | Vendor-dependent, may be paid tier |
No. This is a build-to-order app that ECOSIRE builds specifically for your bank format(s) and payroll structure. There is no instant download — we scope, build, test on staging, and then install it on your site. That is deliberate: bank file layouts vary by bank and country, so a generic download would rarely match your bank's exact spec.
Typically 2–4 weeks from confirmed scope. The clock starts once we have agreed the bank format(s), a redacted sample spec from your bank, and your multi-company/currency requirements. Simpler single-bank NACHA or SEPA builds land toward the shorter end; multiple banks or an unusual local format sit toward the longer end. We confirm a firm date after the scoping call.
We build to the format your bank actually requires — NACHA/ACH for US banks, ISO 20022 pain.001 and SEPA credit transfer for European rails, and local fixed-width or delimited batch formats used by many GCC, South Asian, and African banks. Because layouts live in a `Bank File Template` DocType, adding a second bank later is usually a configuration record plus light testing rather than a rebuild.
Every build includes a post-go-live support window covering defect fixes and format adjustments discovered on your first live pay run. Because you receive the full source and git repository, you are never locked in — your team can maintain it, or you can engage ECOSIRE for a support/retainer arrangement. If your bank changes its file spec, that is a scoped change we can turn around quickly against the existing template.
Yes. It is built as a standard, isolated Frappe app using DocTypes, `hooks.py` doc events, server/client scripts, and role permissions — no core patching or monkey-patching of ERPNext. It targets Frappe/ERPNext v15 and v16, and clean-app architecture is what keeps it upgrade-safe across `bench` migrations.
Validation runs server-side before any file is written: IBAN checksums (ISO 7064 mod-97), account-number format, currency, and net-pay totals are all checked against the run, and the `validate` doc event blocks generation on failure. The output file carries the correct header/trailer, record count, and hash/control total your bank expects, so structural rejections are eliminated. We prove this against your bank's real spec during UAT on staging.
Yes. A scheduler event ingests your bank's return or acknowledgement file and marks each beneficiary as paid, returned, or rejected, writing the status onto the disbursement record. Your team sees reconciliation inside ERPNext instead of cross-checking a bank portal manually, and returned items are flagged for re-processing.
A build-to-order ERPNext app that turns a completed Payroll Entry into validated, bank-specific disbursement files (NACHA, SEPA, or your local format) and reconciles their status back into ERPNext. ECOSIRE builds it to your bank's spec, installs it, and supports it.