Microsoft Dynamics 365 F&O and BILL integration

What moves between them

The primary flow runs from Microsoft Dynamics 365 F&O into BILL. Vendor master records sync first so a payee exists in BILL before any invoice references it. Approved, posted vendor invoices in D365 are then created as bills in BILL, with each line mapped to a BILL chart-of-accounts entry and department. Payment status flows the other direction: once BILL processes a payment, ml-connector reads the payment record and writes it back as a vendor payment journal line in D365 so the ERP ledger reflects what was paid. Purchase orders stay in D365, since BILL has no purchase order entity; only the resulting bills move.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the ERP side it requests an Entra ID client-credentials token scoped to the customer environment host and refreshes it when a call returns 401, and it accepts the full tenant URL per customer since D365 publishes no shared base address. On the BILL side it logs in for a sessionId and silently re-authenticates on the auth error BILL returns when a session lapses. Vendors map by account number to BILL vendor, and GL accounts and financial dimensions map to BILL chart-of-accounts and departments before any bill is written, so every bill line references an account that already exists. Because D365 vendor invoices are read-only once posted and BILL has no idempotency key, the connector reads posted invoices by polling on your schedule, optionally triggered by a Business Event stub, and checks BILL entity IDs before creating a bill so a re-run never double-posts. D365 returns HTTP 429 with Retry-After under service protection limits and BILL caps concurrency at three per org, so ml-connector throttles, backs off, and retries, with a full audit trail and replay on every record.

A real-world example

A mid-sized professional services firm of about 300 staff runs Microsoft Dynamics 365 F&O for finance and uses BILL to route vendor bills through approval and pay them by ACH. Before the integration, an AP clerk re-keyed every approved D365 invoice into BILL to schedule payment, then logged back into the ERP after each payment run to mark the invoices paid. The double entry caused mismatched vendor records and a backlog at month-end close. With the two systems connected, approved invoices flow into BILL as bills against the right GL accounts, and BILL payment status posts back to the D365 vendor payment journal, so the ledger reconciles without manual re-keying.

What you can do

• •Sync vendor master records from Microsoft Dynamics 365 F&O into BILL so every payee exists before a bill references it.
• •Create BILL bills from approved, posted D365 vendor invoices, with each line mapped to the correct BILL account.
• •Record BILL payment status back to the D365 vendor payment journal so the ERP ledger reflects what was paid.
• •Map D365 main accounts and financial dimensions to BILL chart-of-accounts entries and departments.
• •Bridge Entra ID OAuth2 and BILL session-token login, with throttling, retries, and a full audit trail on every record.

Questions

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

Vendors and approved vendor invoices move from D365 into BILL, where the invoices become payable bills. Payment status moves the other way, from BILL back into the D365 vendor payment journal. Purchase orders stay in D365 because BILL has no purchase order entity, so only the resulting bills are synced.

How does the integration bridge the different authentication methods?

Microsoft Dynamics 365 F&O uses Entra ID OAuth2 client credentials scoped to the tenant environment host, while BILL uses a session token from a developer key and org login. ml-connector stores both encrypted, requests and refreshes the Entra ID token on a 401, and re-runs the BILL login when its session expires after inactivity. Each customer supplies their own D365 environment URL and BILL organization ID.

How are duplicate bills avoided without an idempotency key?

Neither system offers a native idempotency key, so ml-connector tracks the BILL entity ID returned when a bill is created and checks it before posting again. D365 vendor invoices are read-only once posted, and Business Event payloads carry a ControlNumber for deduplication, so a re-run or a replayed event never creates a second bill for the same invoice.