Secure host-to-host bank file exchange for Dynamics 365 Finance & Operations: outbound payments, positive pay, acknowledgements and statement pickup. Built to order for your specific banks — not a shelf product. Built to order by ECOSIRE for Dynamics 365 F&O (build-to-order) — indicative price from $1499.00 USD; request a quote for a scoped proposal.
Secure host-to-host bank file exchange for Dynamics 365 Finance & Operations: outbound payments, positive pay, acknowledgements and statement pickup. Built to order for your specific banks — not a shelf product.
Built to order
Treasury and AP teams running Dynamics 365 Finance & Operations generate a payment file, download it to a workstation, log in to a bank portal, upload it, and then wait. Nobody in Finance knows whether the bank accepted the file until someone logs back in and reads a status page. Rejected payments surface days later. Positive pay issue files are assembled in Excel. Bank statements are downloaded by hand for reconciliation. Multiply that by three or four banking relationships and several legal entities and it becomes a daily manual ritual that cannot be audited and cannot be delegated.
Host-to-host connectivity replaces the browser and the workstation with a direct, scheduled, authenticated channel between F&O and each bank. ECOSIRE builds that channel for your specific bank list, your specific file formats, and your specific approval flow.
This is a build-to-order engagement. We write an X++ extension package for Finance and Supply Chain Management — extension classes, table extensions, form extensions, event handlers and chain-of-command augmentations, with no overlayering of Microsoft code. It is delivered as a deployable package through your LCS pipeline and installed first in a sandbox, then in production.
A new bank channel setup form, extending the existing Cash and bank management area, holds one record per bank relationship: host, port, protocol (SFTP with SSH key or password authentication, or HTTPS with mutual TLS), remote directories for outbound, inbound, archive and error, file naming masks, and the legal entities the channel serves. Credentials and private keys are held outside the transactional tables and referenced by handle, so a key rotation is a configuration change rather than a code change.
The extension hooks the existing payment journal generation path. When a payment file is produced by an electronic reporting format or a method of payment file format, the resulting artifact is captured, stamped with a transmission record, and queued. A batch job picks up queued transmissions, opens the channel, writes the file to the bank's inbound directory, verifies the write, and moves the local copy to an archive location. Every step writes to a transmission log table with the user, timestamp, byte count and checksum.
Banks answer in several layers: a transport-level receipt, a syntax acknowledgement, and a business acknowledgement per payment. A polling batch job reads the bank's outbound directory, parses acknowledgement files into a normalized status table, and links each status back to the originating payment line. Statuses roll up onto the payment journal and vendor transaction so an AP clerk can see accepted, rejected or pending without leaving F&O. Rejections raise an alert and can optionally reverse the payment journal posting through a controlled process rather than a silent failure.
A positive pay issue file is generated from cheque and payment data at a configurable cadence — on posting, on a schedule, or on demand. Void and stop-payment records are included so the bank's file reflects the current state, not just new issues. Formats differ by bank, so the layout is built as a configurable mapping over the check and bank transaction tables rather than hard-coded, and payee-name-inclusive variants are supported where the bank requires them.
Inbound bank statements (BAI2, MT940, CAMT.053 or a bank-proprietary layout) are collected on a schedule, staged, and handed to the standard bank statement import so advanced bank reconciliation continues to work exactly as it does today. Files that fail parsing are moved to an error directory and logged rather than dropped.
Everything runs on the F&O batch framework, so scheduling, recurrence, batch groups and server allocation are managed the way your administrators already manage them. Retries use bounded exponential backoff with a dead-letter state that stops after a configured number of attempts rather than looping forever. A monitoring workspace shows channel health, last successful contact, queue depth, and unacknowledged transmissions. Security is enforced through new privileges and duties added to your existing security roles, so setting up a channel, transmitting, and viewing logs can be separated.
Organizations running F&O with more than one banking relationship, or with a single bank but a real payment volume; shared service centres that pay from several legal entities; and finance teams under audit pressure to remove manual file handling from the payment cycle. It is equally relevant where an existing manual process works but cannot scale, and where an acquisition has added a bank that nobody wants to onboard by hand.
1. Scoping call. We walk through your bank list, the file formats each bank has published for you, the protocols and authentication they support, your legal entity structure, and how payments are approved today. We ask for the bank's technical specification documents; without them, formats are guesswork. 2. Fixed quote. You receive a written scope covering the channels, formats, acknowledgement layers and reports included, with a fixed price and a delivery window. Typical lead time is two to four weeks, driven mainly by how quickly the bank's specifications and test credentials become available. 3. Build. Development happens in our own F&O development environment against your target platform version. You get progress checkpoints, not a black box. 4. Install in test. The deployable package goes into your sandbox through LCS. We configure the channels against the bank's test endpoints, run test transmissions, and work through the bank's certification or penny-test process with your treasury team. 5. Production. After your sign-off, the same package is applied to production through your normal release pipeline, live credentials are configured, and we monitor the first live cycles with you. 6. Support. A warranty window follows go-live for defect correction, with optional ongoing support for new banks, new formats and platform updates.
It is not a hosted service, it is not a payment processor, and it does not move money — it moves files on your behalf, using your bank agreements and your credentials, inside your tenant. It is not downloadable today; each build is scoped to the banks and formats you actually use.
A short call to confirm the workflow, your platform version and where the integration boundaries sit.
You receive a written scope and a fixed price. Nothing is built until you approve it.
We develop against a copy of your configuration and test it there. Typically two to four weeks.
We install on your instance, hand over the source, and support it for twelve months.
Spends part of every day moving payment files between F&O and multiple bank portals, with no single view of which payments the banks actually accepted. This gives one queue, one status per payment and an alert when a bank rejects something, instead of a portal check the next morning.
Fields questions about whether a vendor was paid and has to reconcile bank feedback against payment journals by hand. Acknowledgement statuses land directly on the vendor payment journal and vendor transaction, so the answer is in F&O rather than in a bank portal or an inbox.
Is asked to add a new bank and does not want another one-off integration built on file shares and scheduled scripts outside the ERP. Gets an extension-model component that uses the batch framework, standard security, and the existing bank statement import path, so it survives platform updates.
| Criterion | ECOSIRE | Custom Build | Competitor |
|---|---|---|---|
| Automated SFTP/HTTPS transmission from inside F&O | Included | Included | Included |
| Multi-layer acknowledgement parsing mapped to payment lines | Included |
From $1499.00
Starting point — quoted to your scope
| Partial support |
| Positive pay issue file including voids and stop payments | Included | Partial support | Included |
|---|
| Scheduled statement pickup feeding Advanced bank reconciliation | Included | Partial support | Included |
|---|
| Built as an extension with no overlayering | Included | Partial support | Included |
|---|
| Fixed price agreed before build starts | Included | Not included | Partial support |
|---|
| Source code handed to the customer | Included | Included | Not included |
|---|
| No recurring per-transaction or per-bank subscription fee | Included | Included | Not included |
|---|
An X++ extension that imports bank statements into Dynamics 365 F&O and fuzzy-matches lines against payments, deposits and fees. Built to order for your legal entities after a scoping call and fixed quote.
A behaviour-aware treasury forecasting app for Dynamics 365 Finance & Operations. Built to order as an X++ extension after a scoping call and a fixed quote — nothing is pre-built or downloadable today.
A built-to-order forecasting and planning layer for Dynamics 365 Finance & Operations, with external demand signals, explainable forecasts and scenario comparison. Scoped and built by ECOSIRE after a fixed quote.
A build-to-order X++ extension that captures vendor invoices, extracts line data, matches them against purchase orders with tolerance rules and routes exceptions through F&O workflow. ECOSIRE builds it for your entity structure after a fixed quote.