Microsoft Dynamics 365 Business Central and GoCardless integration

What moves between them

The outbound flow runs from Microsoft Dynamics 365 Business Central into GoCardless. Open sales invoices and their customers are read from Business Central and used to create or match a customer and a direct debit payment against an active mandate in GoCardless, with the invoice number kept as the payment reference. The inbound flow runs the other way: GoCardless webhook events for confirmed and paid-out payments, failures, chargebacks, and refunds are turned into customer payment journal lines applied to the original invoice in Business Central. Payout events trigger reconciliation against payout items. Cadence is event-driven from GoCardless and scheduled polling from Business Central for invoices.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Business Central it requests an Entra ID client-credentials token, builds the base URL from the tenant and environment name, and pages results with the OData nextLink continuation token. For GoCardless it sends the bearer token plus the GoCardless-Version header on every call. Because a payment requires a mandate, the connector only collects invoices for customers that already have an active mandate and skips or flags the rest. Invoice totals are converted from decimals to integer minor units, and the charge date respects the scheme advance-notice rules GoCardless enforces. Inbound webhooks are verified with HMAC-SHA256 against the Webhook-Signature header and rejected with a non-200 on mismatch. A paid_out event posts a customer payment applied to the matching sales invoice; a failed or charged_back event leaves the invoice open and raises an alert. Payment creation uses an idempotency key and BullMQ jobId so a retry never double-charges. Business Central subscriptions are renewed before the three-day expiry, and pooled payouts are reconciled by reading payout items so fees and refunds are accounted for.

A real-world example

A subscription software vendor with a few hundred UK and EU business customers runs accounts receivable in Microsoft Dynamics 365 Business Central and collects by direct debit through GoCardless. Before the integration, finance exported a list of due invoices, created the matching payments in the GoCardless dashboard by hand, then weeks later tried to match a single pooled GoCardless payout back to dozens of individual invoices and re-key each receipt into Business Central. With the two connected, each open invoice becomes a GoCardless payment automatically, confirmed collections post straight to the customer payment journal applied to the right invoice, and every payout is reconciled to its payout items, so cash in the bank ties out to the ledger without manual matching.

What you can do

• •Create GoCardless direct debit payments from open Microsoft Dynamics 365 Business Central sales invoices against an active mandate.
• •Post confirmed and paid-out GoCardless payments back to Business Central as customer payment journal lines applied to the original invoice.
• •Reconcile pooled GoCardless payouts against payout items so fees, refunds, and chargebacks are accounted for in the ledger.
• •Bridge the Business Central Entra ID client-credentials token and the GoCardless bearer token plus version header, with amount conversion to minor units.
• •Verify signed GoCardless webhooks, dedupe payment creation with an idempotency key, and replay any failed step from a full audit trail.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and GoCardless?

Both directions. Open sales invoices and customers flow from Business Central into GoCardless to create direct debit payments, and confirmed payment and payout events flow back from GoCardless into Business Central as customer payment journal entries. GoCardless payouts are read-only, so ml-connector reads and reconciles them rather than writing payout records back.

What happens if a customer has no GoCardless mandate yet?

GoCardless will not let a payment be created without an existing active mandate, since links.mandate is required. ml-connector only collects invoices for customers that already have an active mandate and flags the rest so they can be set up first, for example through a GoCardless billing request hosted flow. No payment is attempted until the mandate is active.

How are confirmed payments and pooled payouts reconciled back to invoices?

ml-connector verifies each GoCardless webhook with HMAC-SHA256, then on a paid_out event posts a customer payment in Business Central applied to the matching sales invoice using the invoice number kept as the payment reference. Because GoCardless pays out many payments in one lump sum, it reads the payout items for each payout to split fees, refunds, and chargebacks, so the bank deposit ties out to the ledger.