Microsoft Dynamics 365 F&O and Wise integration

What moves between them

The main flow runs from Microsoft Dynamics 365 F&O into Wise. ml-connector reads approved vendor payment journal lines, and the underlying vendor invoices and vendor master, then creates and funds matching Wise transfers so suppliers are paid in their local currency. Each D365 vendor maps to a Wise recipient, and the journal amount and currency drive the Wise quote. Transfer status and the settled source and target amounts flow the other direction to mark the payment journal in D365 and support reconciliation against the balance statement. Wise has no GL or invoice objects, so ml-connector never writes ledger entries or invoices back into Wise; the chart of accounts and posting stay entirely in Microsoft Dynamics 365 F&O.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the D365 side it requests an Entra ID client-credentials token scoped to the environment host, accepts the full tenant URL per customer since there is no shared base address, and refreshes the bearer token when a call returns 401. On the Wise side it caches the business profile_id and runs the mandatory four steps in order: quote, recipient, transfer, then fund from balance, because skipping the funding step leaves the transfer stuck in incoming_payment_waiting and it never executes. Vendors are mapped to Wise recipients first, and since recipients are immutable a changed bank detail means delete and recreate, so ml-connector caches recipient IDs and handles stale keys. Quotes carry an expirationTime, so a fresh quote is created if one lapses before funding. Every transfer is sent with a generated customerTransactionId and a BullMQ jobId, so a retried D365 payment line cannot pay the supplier twice. A signed transfer state-change webhook, verified against Wise's public key, updates the journal as the payout sends or fails, and a scheduled poll backfills any missed event since D365 itself offers no payment-status push. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized engineering firm of roughly 300 staff runs Microsoft Dynamics 365 F&O for procurement and accounts payable and buys components from suppliers across Europe and Asia. Before the integration, once an AP clerk approved a payment run, someone logged into Wise and rekeyed each supplier's bank details, amount, and currency by hand, which was slow, prone to a wrong IBAN or transposed figure, and left the payment journal in D365 showing paid before the money had actually sent. With Microsoft Dynamics 365 F&O and Wise connected, each approved payment line becomes a funded Wise transfer automatically, the recipient and amount come straight from the vendor record, and the journal is marked only once Wise confirms the outgoing payment. The double entry is gone and the ledger reflects real payout status.

What you can do

• •Turn approved Microsoft Dynamics 365 F&O vendor payment journal lines into funded Wise transfers in the supplier's currency.
• •Map each D365 vendor to a Wise recipient and drive the quote from the journal amount and currency.
• •Run the required Wise quote, recipient, transfer, and fund sequence so payments actually execute.
• •Post Wise transfer status and settled amounts back to mark the D365 payment journal for reconciliation.
• •Bridge Entra ID client-credentials auth to Wise OAuth, with customerTransactionId dedup, retries, and a full audit trail.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and Wise?

The main flow is D365 into Wise. Approved vendor payment journal lines, with their vendor and invoice context, drive Wise transfers, and the transfer status and settled amounts flow back to mark the journal. Wise has no GL accounts or invoices, so ml-connector never writes ledger entries back, and the chart of accounts stays entirely in Microsoft Dynamics 365 F&O.

How does the integration avoid paying a supplier twice?

Every Wise transfer is created with a generated customerTransactionId, which Wise deduplicates on, plus a BullMQ jobId on the ml-connector side. If a D365 payment line is re-read or a call is retried after a timeout, the same identifiers prevent a second payout. ml-connector also marks the journal only after Wise confirms the outgoing payment, so the ledger does not show paid before money has sent.

Does Wise execute a transfer as soon as ml-connector creates it?

No. Wise requires a fixed four-step sequence: get a quote, create or look up a recipient, create the transfer, then fund it from a balance. A transfer that is created but not funded stays in incoming_payment_waiting and never sends. ml-connector runs all four steps in order and creates a fresh quote if the previous one passes its expirationTime before funding.