Microsoft Dynamics 365 Business Central and Airbase integration

What moves between them

The main flow runs from Airbase into Microsoft Dynamics 365 Business Central. As Airbase bills, expense reimbursements, card transactions, and payments clear their approval workflows, ml-connector posts them into Business Central as purchase invoices or journal lines, each coded to the matching GL account and dimensions. Reference data runs the other direction: Business Central vendors and the read-only chart of accounts flow into Airbase so spend is coded against accounts and vendors that already exist. Cadence is event-driven where webhooks fire and scheduled polling otherwise. The Business Central chart of accounts is read-only over the API, so ml-connector never writes accounts back, and Airbase card transactions and GL accounts are read-only, so ml-connector only reads them.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Microsoft Dynamics 365 Business Central it runs the OAuth client-credentials grant against Microsoft Entra ID, caches the token, and builds the base URL from the stored environment name and company ID. For Airbase it sends the portal-generated bearer token against the tenant base URL on every request. Airbase vendors map to Business Central vendors by number, and Airbase GL codes map to Business Central GL accounts and dimensions, which are synced first so every posted line lands on a valid account. Because a posted Airbase bill arrives as a draft purchase invoice, ml-connector calls the Microsoft.NAV.post bound action to post it. Business Central webhook subscriptions expire every three days, so a renewal job runs before expiry and answers the validationToken handshake, and the clientState shared secret on each notification is checked; since notifications carry no data, the changed record is fetched after each one. Purchase orders are not webhook eligible in Business Central, so they are polled with an OData lastModifiedDateTime filter. Business Central throttling returns HTTP 429 and Airbase returns a Retry-After header, so ml-connector backs off with jitter and retries. Because the Airbase token is long-lived and rotated only in the portal, ml-connector flags it for renewal. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A roughly 250-person software company runs Microsoft Dynamics 365 Business Central for accounting and gives most of its staff Airbase corporate cards plus an Airbase workflow for vendor bills and expense reimbursements. Before the integration, an accountant exported approved bills and card transactions from Airbase each week and re-keyed them into Business Central as purchase invoices and journals, matching every line to a GL account and department by hand, and month-end close stalled while uncoded card spend was chased down. With the two systems connected, approved Airbase spend posts into Business Central automatically against the right accounts and dimensions, and the vendor list and chart of accounts stay aligned, so close starts with the spend already booked and coded.

What you can do

• •Post approved Airbase bills into Microsoft Dynamics 365 Business Central as purchase invoices and post them with the bound action.
• •Book Airbase card transactions, expense reimbursements, and payments into the Business Central general ledger against the right accounts and dimensions.
• •Sync the Business Central vendor master and read-only chart of accounts into Airbase so spend is coded to accounts that already exist.
• •Authenticate Business Central with Entra ID client-credentials OAuth and Airbase with its portal-generated bearer token against each tenant URL.
• •Renew three-day Business Central webhook subscriptions, poll non-webhook purchase orders, and keep a full audit trail with replay on every record.

Questions

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

The main flow is Airbase into Business Central: approved bills, card transactions, reimbursements, and payments post into the general ledger as purchase invoices and journal lines. Reference data runs the other way, with Business Central vendors and the chart of accounts feeding Airbase so spend is coded correctly. The Business Central chart of accounts and the Airbase card transactions are read-only over their APIs, so ml-connector does not write those back.

How does ml-connector handle Business Central webhooks expiring and purchase orders not supporting them?

Business Central webhook subscriptions expire after three days, so ml-connector runs a renewal job before expiry and answers the validationToken handshake on create and renew. Notifications carry no data, so the changed record is fetched after each one, and the clientState shared secret is checked for verification. Purchase orders are not webhook eligible in Business Central, so ml-connector polls them with an OData lastModifiedDateTime filter instead.

Does an Airbase bill post automatically once ml-connector sends it to Business Central?

Not on its own. A purchase invoice created over the Business Central API arrives as a draft, so ml-connector calls the Microsoft.NAV.post bound action to post it to the ledger. On the Airbase side, bills move through configurable approval chains, so ml-connector waits until a bill is approved before posting it, rather than acting on a record that is still pending.