Microsoft Dynamics 365 Business Central and Brex integration

What moves between them

The main flow runs from Brex into Microsoft Dynamics 365 Business Central. When a Brex accounting record is coded and ready for export, ml-connector reads it and posts the spend into Business Central as a draft purchase invoice against the matching vendor, GL account, and dimensions, then marks the Brex record exported. Vendor records flow the other way: Business Central vendors are synced into the Brex vendor directory so Brex bill payments reference real payees. Completed Brex transfers are reconciled against the corresponding Business Central documents. Brex accounting records and transactions are the read source for spend, so ml-connector does not write expense data back into Brex beyond the exported flag.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Business Central side it builds the base URL from the stored tenant and environment name and obtains an Entra ID client-credentials token, refreshing it on a 401. On the Brex side it sends the bearer token and verifies inbound webhooks using the Svix signing scheme over the webhook-id, webhook-timestamp, and raw body. It subscribes to the Brex ACCOUNTING_RECORD_READY_FOR_EXPORT event so coding completion triggers a pull and post, and it polls Brex accounting records on a schedule to backfill anything a webhook missed. Brex merchant names rarely match Business Central vendor names exactly, so a fuzzy-match and cache layer resolves each merchant to a real vendor before posting, and Brex accounting fields map to Business Central dimensions. Posted invoices stay as drafts unless your flow runs the post action. Brex transfer creation carries an Idempotency-Key, Business Central uses a stable jobId keyed to the record so a retry never double-posts, and HTTP 429 from either side triggers exponential backoff with jitter. Because Business Central subscriptions expire after three days, ml-connector renews them before expiry, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A 150-person software company runs Microsoft Dynamics 365 Business Central for finance and issues Brex cards to its engineering and sales teams. Before the integration, an accountant exported Brex expenses each month, matched merchants to vendors by hand, and keyed the totals into Business Central, with software subscriptions and travel landing on the wrong GL accounts until someone caught it at close. With Business Central and Brex connected, each coded Brex accounting record posts into Business Central as a draft purchase invoice on the correct account and department dimension, and the merchant-to-vendor matching is handled automatically. Month-end close starts with card spend already booked, and the manual export-and-rekey step is gone.

What you can do

• •Post coded Brex accounting records into Microsoft Dynamics 365 Business Central as draft purchase invoices on the right GL account and dimensions.
• •Sync Business Central vendors into the Brex vendor directory so bill payments reference real payees.
• •Resolve fuzzy Brex merchant names to existing Business Central vendors with a match-and-cache layer.
• •Bridge Brex bearer-token auth with the Entra ID client-credentials login Business Central requires.
• •React to the Brex ready-for-export webhook, backfill by polling, and mark each record exported so nothing posts twice.

Questions

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

The main flow is Brex into Business Central. Coded Brex accounting records become draft purchase invoices in Business Central, while vendors sync the other way so Brex bill payments reference real payees. Brex accounting records are the read source for spend, so ml-connector marks each record exported rather than writing expense data back.

How does ml-connector avoid posting the same Brex spend twice?

Each Brex accounting record carries an export status. After ml-connector posts a record into Business Central it sets that status to exported, and it keys the Business Central job to the record id so a retry re-runs under the same id and deduplicates. The Brex ready-for-export webhook and a scheduled poll only ever act on records still marked ready for export.

Does the connector handle Business Central webhook expiry and the Entra ID login?

Yes. ml-connector obtains an Entra ID client-credentials token for Business Central and refreshes it on a 401. Business Central push subscriptions expire after three days, so the connector renews them before expiry and completes the validation-token handshake; because notifications carry only a change signal, it fetches the changed record afterward.