Direct Debit and ACH Payment Files

Recurring collections and bulk payments are where a well-run SAP Business One installation quietly falls back on spreadsheets. The invoices are correct, the sub-ledger is clean, and then someone exports a list, retypes it into a bank portal, saves a file the bank rejects for a header field, and spends the afternoon reconciling what actually went out. When a collection fails, the return notice arrives days later as a PDF, and the reversal, the bank charge and the customer follow-up are all manual.

Mandates make it worse. A direct debit mandate is a legal instrument with a reference, a signature date, a scheme, a sequence position and an amendment history — and in most installations it exists as a scanned document in a folder, with no link to the Business Partner and nothing preventing a collection being taken against a mandate that was cancelled last quarter.

Direct Debit and ACH Payment Files is a SAP Business One add-on that ECOSIRE builds to order. It holds mandates as first-class records, builds collection and payment runs from your open sub-ledger, produces bank files in the exact format your bank publishes, and imports the resulting status and return files so the ledger reflects what the bank actually did.

What ECOSIRE builds

A mandate register

Mandates are implemented as a User-Defined Object over User-Defined Tables: unique mandate reference, signature date, scheme, status, first-use date, cancellation date and a full amendment history, each linked to the Business Partner and to a specific Business Partner bank account. User-Defined Fields on the Business Partner surface the active mandate on the master record. Sequence type is tracked and advanced automatically as collections succeed, so a first collection is presented as first and subsequent ones as recurring, with a final presentation flagged when a mandate is being closed.

Collections cannot be raised against a mandate that is cancelled, expired under your rules, or missing a validated bank account. That check happens server-side, not in a warning dialog someone can dismiss.

Collection runs

A run selects open A/R Invoices by due date, Business Partner group, payment terms and payment method, and presents the proposal for review before anything is posted or exported. You can exclude a line, split a collection, apply a pre-notification lead time, or hold a customer pending a query. On submission the add-on posts the Incoming Payments against the selected invoices, so the sub-ledger reflects the run without a second data-entry pass, and the run is locked against regeneration once the file is marked as submitted to the bank.

Bank files that the bank accepts

The add-on generates ISO 20022 pain.008 direct debit instructions and pain.001 credit transfers at the message version and profile your bank specifies, and NACHA-format ACH files with correct company and batch header records, entry detail records, batch and file control records and hash totals. Local formats your bank publishes are built to the same standard where they are named in your scope.

This matters more than it sounds: two banks on the same standard will differ on optional fields, character sets, file naming and batching rules. We build against the specification document your bank issues and we run a test file through their acceptance process as part of delivery, rather than shipping a generic template and leaving you to argue with a rejection notice.

Vendor payment runs

The same engine runs the payables side: select open A/P Invoices by due date, vendor group or currency, review the proposal, post the Outgoing Payments and produce the credit transfer file. Remittance advice is generated per vendor from a Crystal Reports layout and emailed from the run, so suppliers can apply the payment without calling your accounts payable team.

Returns, rejections and reconciliation

Status reports and return files are imported and matched back to the originating payment: pain.002 status reports, camt.054 debit and credit notifications, and ACH return files with their return reason codes. A rejected collection triggers the workflow you define — reverse or flag the Incoming Payment, post the bank charge to the account you nominate, change the mandate status or block it after a number of consecutive failures, and raise an Activity for the collections owner with the reason code attached.

Controls

Payment runs route through SAP Business One approval procedures, with dual authorisation where you require it. Every generated file is recorded with its hash, its creation user, its submission timestamp and its contents, and a submitted run cannot be regenerated without an explicit, logged override. The audit table is queryable and included in the reporting pack.

Technology and compatibility

The add-on targets SAP Business One 10.0 on Microsoft SQL Server and on SAP HANA, on-premise or cloud-hosted. Payments are posted through the Service Layer (REST), with the DI API used where the payment object requires it. Mandates, run headers and the file audit trail are User-Defined Tables and User-Defined Objects; master data extensions are User-Defined Fields on Business Partners and their bank accounts. Multi-currency and multiple company databases are supported where they are in scope. Crystal Reports layouts cover the mandate register, the collection run summary, failed-collection ageing and remittance advice.

Who this is for

Subscription, service and rental businesses collecting from a recurring customer base; wholesalers collecting on account; and any SAP Business One site paying suppliers in bulk where the current process is a manual portal upload. It is worth most where collection volume makes manual reconciliation of returns impractical.

How delivery works

Nothing here is pre-built or downloadable. Each deployment is built for one customer's bank relationships and company database.

1. Scoping call. We collect your bank's format specification documents, your schemes, your currencies, your posting accounts for charges and reversals, and your existing mandate records. 2. Fixed quote. A written scope naming each file format in and out of scope, with a fixed price, issued before any code is written. 3. Build. Typical lead time is one working week from acceptance of the quote, depending on how many formats and banks are in scope. 4. Install in test. Installation into your test company database, migration of existing mandates, and a test file cycle submitted to your bank for acceptance before go-live. 5. Install in production. After your sign-off and the bank's acceptance of a test file, we install into production and run the first live collection alongside your team. 6. Support window. A defect-fix and support period runs from the production install date, with the duration stated in your quote.