Every week your AP team faces the same grind: dozens of supplier invoices come due, and paying them means exporting a spreadsheet, hand-keying amounts into the bank portal, or one-by-one entering IBANs and routing numbers. ERPNext core gives you Payment Entry and the Payment Reconciliation tools, but it has no concept of a payment run — no way to select fifty due invoices, group them by supplier and currency, get a controller to approve the batch, and hand your bank a single upload file. That gap is where transcription errors, duplicate payments, and late-payment penalties live.

This is a build-to-order Frappe app that ECOSIRE designs, builds, installs, and supports on your ERPNext v15/v16 site — it is not an off-the-shelf Marketplace download. We ship it as a proper Frappe app (its own module, versioned in a git repo) so it upgrades cleanly and never patches ERPNext core in place. The centerpiece is a Payment Run DocType with a child table of selected invoices: AP pulls in outstanding Purchase Invoices via a filtered query (due date, supplier group, currency, hold status), the app validates each supplier's bank details against a required-fields check, and a Frappe Workflow moves the run through Draft → Pending Approval → Approved states gated by role profiles, so the person who builds the run is never the person who releases it.

On approval, whitelisted server-side methods render the bank file from format-specific templates: Australian ABA (cemtext), BAI2 for reconciliation-friendly banks, ISO 20022 SEPA pain.001.001.09 XML, and US NACHA ACH (PPD/CCD entries with the correct header, batch, and file-control records). Each format is a discrete generator with its own field mapping, checksum/hash-total logic, and character-set rules, so you can enable only the rails your banks actually use. hooks.py doc events keep totals and payment status in sync, a scheduler event can auto-email remittance advice to each supplier once the batch is marked paid, and the whole flow is exposed over the Frappe REST API and whitelisted methods for treasury automation. Client scripts add the "select all due", running-total, and validation-warning behavior on the Payment Run form.

Because it is build-to-order, delivery follows a defined path rather than an instant download. It starts with a scoping call to confirm exactly which bank formats, currencies, approval tiers, and remittance templates you need — a UAE bank's SEPA profile and a US regional bank's NACHA addenda are genuinely different builds. We then develop against your requirements, test on a staging copy of your site, and run UAT with your AP team using your real bank's validation portal before go-live. Typical delivery is one working week from confirmed scope. You receive the installable source, install and configuration on your environment, documentation, a training session, a post-go-live support window, and the git repository so the code is yours to keep.