Microsoft Dynamics 365 F&O and Airbase integration

What moves between them

The main flow runs from Airbase into Microsoft Dynamics 365 F&O. As bills, expense reimbursements, and card transactions clear their Airbase approval chains, ml-connector reads them and writes vendor invoices and journal lines into Dynamics against the matching main accounts and financial dimensions. Reference data runs the other direction: the Dynamics chart of accounts, vendor master, and dimension values feed Airbase so spend is coded against valid GL accounts. Posted general ledger entries are read-only in Dynamics, so ml-connector creates them through journal entities and never writes financial postings back into Airbase.

How ml-connector handles it

ml-connector stores both credential sets encrypted and presents the right one per side. For Dynamics it runs the Entra ID client credentials flow, caches the bearer token, and refreshes it when a call returns 401, accepting the tenant environment host as a credential field since there is no shared base URL. For Airbase it sends the portal-generated bearer token against the tenant base URL and tracks the token so a manual rotation does not become an outage. Airbase approval chains mean a created bill is not yet payable, so ml-connector reads on a polling schedule and checks status fields rather than acting on the first event, and it can consume Airbase webhooks where they are enabled. GL accounts and financial dimensions are mapped first, so every vendor invoice and journal line references a Dynamics main account and dimension combination that already exists. Dynamics writes use natural keys such as InvoiceNumber plus VendorAccount with no idempotency key, so ml-connector deduplicates before each write to avoid duplicate-key errors, formats dimensions as the display string Dynamics expects, and respects HTTP 429 with Retry-After. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A roughly 300-person software company runs Microsoft Dynamics 365 F&O for finance and uses Airbase for corporate cards, employee reimbursements, and vendor bill payments. Before the integration, the accounting team exported spend from Airbase each week and hand-keyed bills and journal entries into Dynamics, then reconciled card and reimbursement totals against the ledger during month-end close. With the two connected, approved bills, reimbursements, and card transactions post into Dynamics automatically, coded to the correct main account and department dimension, while the Dynamics chart of accounts and vendor list keep Airbase coding accurate. The weekly re-keying disappears and close starts with spend already reconciled.

What you can do

• •Post approved Airbase bills, reimbursements, and card transactions into Microsoft Dynamics 365 F&O as vendor invoices and journal lines.
• •Feed the Dynamics chart of accounts, vendor master, and financial dimensions back to Airbase so spend is coded to valid accounts.
• •Bridge Airbase's portal-generated bearer token and the Entra ID OAuth2 client credentials that Dynamics requires.
• •Poll Airbase on a schedule and check approval status so only cleared spend posts to the ledger.
• •Deduplicate writes against Dynamics natural keys and honor HTTP 429 Retry-After, with a full audit trail and replay on every record.

Questions

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

The main flow is Airbase into Dynamics. Approved bills, expense reimbursements, and card transactions move from Airbase into Dynamics as vendor invoices and journal lines, while the chart of accounts, vendor master, and financial dimensions flow back to Airbase. Posted general ledger entries are read-only in Dynamics, so ml-connector writes through journal entities and never posts financial entries into Airbase.

How does the integration bridge the two different auth methods?

Dynamics uses OAuth 2.0 client credentials through Microsoft Entra ID with an hourly bearer token, while Airbase uses a long-lived bearer token generated in its portal. ml-connector stores both encrypted, runs the Entra ID flow and refreshes the Dynamics token on a 401, and presents the Airbase token against the tenant base URL. It also tracks the Airbase token so a manual rotation is handled before it can break the sync.

How are Airbase approval workflows and duplicate postings handled?

A created bill or expense in Airbase is not automatically approved or paid, so ml-connector polls status fields and posts to Dynamics only once spend has cleared its approval chain. Because Dynamics writes use natural keys such as InvoiceNumber and VendorAccount with no idempotency key, ml-connector deduplicates before each write to avoid duplicate-key errors. Failed downstream calls are retried and can be replayed from the audit trail.