Direct Debit, SEPA & ACH Processing

The problem

If you collect from customers by direct debit, the collection run is the most repetitive and least forgiving process in your finance function. Dynamics 365 Finance gives you the building blocks — customer payment methods, payment journals, the electronic reporting framework for file formats, and SEPA direct debit mandate fields on the customer bank account. What it leaves to you is everything around them.

Mandates get scanned into a folder and their sequence type is tracked by memory. Pre-notification deadlines are counted on a calendar. Someone builds a payment proposal, exports a file, uploads it to the bank portal, then waits. Returns come back as a bank statement line or a PDF, get keyed in by hand as a reversal, and the reason code — insufficient funds versus mandate cancelled versus account closed — is lost, so the same failing customer is collected again next month. When you run both SEPA in Europe and ACH in the US, you maintain two disconnected manual processes.

What ECOSIRE builds

This is a build-to-order X++ extension package for Dynamics 365 Finance and Supply Chain Management. Nothing is pre-built or downloadable — we scope your banks, schemes and file formats, quote a fixed price, and deliver the solution into your own LCS pipeline.

Mandate lifecycle management

We build a mandate register that treats a mandate as a governed object rather than a text field. Each mandate carries its unique reference, the creditor identifier for the collecting legal entity, the debtor account and bank details, the signature date and place, the scheme (core or business-to-business for SEPA; the corresponding authorisation type for ACH), the sequence type, and its status through the full lifecycle: draft, active, suspended, expired, cancelled and revoked.

The register enforces the rules that people usually track by hand. First collections are marked as first sequence and flip to recurring automatically once a collection settles. A mandate that has not been used within your dormancy window is flagged before it lapses. Amendments — a changed IBAN, a changed debtor name, a migrated creditor identifier — create an amendment record carrying the original reference so the file can report the change correctly rather than silently sending a new mandate as if nothing happened. Signed mandate documents attach to the record through DocuRef.

Pre-notification

We build pre-notification as a scheduled step, not a reminder. For each planned collection the system computes the notification deadline from the mandate scheme, your configured lead days and the banking calendar, generates the notice with amount, due date, mandate reference and creditor identifier, and records that it was sent, when, to which contact and through which channel. Collections whose notification deadline has not been satisfied are held out of the run rather than submitted and disputed later. Notices go out through the standard print management and email infrastructure so they follow your existing document templates.

Collection runs and file generation

A collection workbench builds the run from open customer transactions: filter by legal entity, payment method, due date window, customer group, currency and collection calendar; preview the selection with mandate validity, sequence type and pre-notification status shown per line; exclude lines with a recorded reason; then generate.

File generation uses the Electronic reporting framework, so the formats are configurable rather than hard-compiled. We build and configure the formats your banks actually require — SEPA direct debit pain.008 in the version and country variant your bank accepts, and ACH NACHA files with the correct entry class for your collections, batch and file control totals, and any addenda your bank specifies. Runs post to a customer payment journal so the ledger effect is the standard one, and the generated file, its hash and its submission status are stored against the run for audit.

Where your bank offers host-to-host transfer, we can wire submission and acknowledgement retrieval into a batch job instead of a manual portal upload, using the connection method your bank supports.

Returns, rejections and reversals

This is where most manual processes break. We build return processing that ingests the bank's return advice — pain.002 rejection and status reports, ACH return entries, or a structured file your bank provides — matches each return to the originating collection line, and applies the outcome: reverse the settlement, reopen the customer invoice, post any bank return charge to the account you nominate, and record the reason code.

Reason codes drive behaviour. We configure a policy per code: retry after a set number of days for insufficient funds; suspend the mandate immediately for account closed or mandate cancelled; escalate to collections for a dispute; and count consecutive failures so a customer is moved off direct debit automatically after your threshold. Every return is visible on the customer, the mandate and the run, so the next collection cycle knows what happened in the last one.

Multi-entity, multi-bank, multi-scheme

Creditor identifiers, bank accounts, file formats, lead days and calendars are configured per legal entity and per bank account, so a group running SEPA collections in several European entities and ACH collections in the US operates one process with the correct file and the correct rules on each side. Ledger dimensions on the resulting journal follow your existing posting profiles.

Data and integration surface

Data entities cover mandates, amendments, pre-notifications, collection runs, run lines and returns, exposed through the Data management framework and OData. That supports mandate migration from a legacy system, Power BI reporting on collection success and return reasons, and a Power Platform surface for customer service to check a mandate without opening F&O.

Who this is for

Subscription, membership, utility, insurance and services businesses collecting recurring payments from a large customer base. Shared-service credit teams running collections for several legal entities across SEPA and ACH. Finance systems owners who have configured the standard payment method and electronic reporting formats and are still handling mandates, pre-notification and returns by hand.

How delivery works

1. Scoping call. We identify your legal entities, banks, creditor identifiers, schemes, the exact file specification each bank accepts, your return advice format, your pre-notification lead times and your F&O version. 2. Fixed quote. A written scope covering the mandate model, pre-notification rules, collection workbench, each file format, return processing and reason-code policies, with a fixed price and delivery timeline. 3. Build. Development as X++ extensions in a dedicated model plus Electronic reporting configurations for the file formats — extension classes, chain of command, event handlers, table and form extensions. No overlayering. 4. Install in test. Deployment to your sandbox through your LCS or Azure DevOps release pipeline. We generate real files against your bank's specification, run them through your bank's validation or test channel where one is available, and process a return file end to end before anyone touches production. 5. Production. After your sign-off and your bank's file acceptance, the package goes to production in your normal deployment window, with configuration steps, security assignments and a runbook covering the first live collection. 6. Support. A defined support window after go-live for defect fixes, format adjustments your bank requests, and a compatibility check at your next platform update.

Typical lead time from signed quote to sandbox delivery is one working week, driven mainly by how many bank formats and return advice variants are in scope.

What this is not

We do not act as your bank, payment scheme participant or payment service provider, and we do not hold funds or credentials. Scheme registration, creditor identifier issuance, bank connectivity approval and mandate legal wording remain yours. What we build is the process inside Dynamics 365 Finance & Operations that produces files your bank accepts and handles what comes back.