Microsoft Dynamics 365 F&O and SAP Concur integration

What moves between them

The main flow runs from SAP Concur into Microsoft Dynamics 365 F&O. ml-connector reads approved documents from Concur's Financial Integration v4 feed, expense reports and invoices, and posts them into Dynamics 365 F&O as vendor invoice headers and lines or ledger journals, mapped to the matching D365 vendor accounts, main accounts, and financial dimensions. After D365 posts a document, ml-connector sends a posting confirmation back to Concur, and a payment confirmation once the vendor payment clears, so the Concur document moves to its posted and paid state. Vendor master records flow from Dynamics 365 F&O into Concur so Concur references valid vendor codes. The cadence is a scheduled poll of the Concur feed, with Concur events used as an optional trigger.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Concur side it runs the company-level password grant, exchanges the one-time auth token for a refresh token before the 24-hour window closes, then rotates access tokens from the refresh token and always calls the geolocation base URL the token returns rather than a fixed datacenter. On the D365 side it requests an Entra ID client credentials token against the environment scope, refreshes it on expiry, and targets the customer's tenant-specific OData host, which it treats as a credential because there is no shared base URL. It scopes writes to the right legal entity with the dataAreaId, since OData returns only the default entity unless cross-company is set, and it formats financial dimensions as the display string D365 requires, which must be configured for integrating applications first or the write fails silently. It reads approved documents from the Financial Integration v4 endpoint with page and limit paging, and because that endpoint reports previously acknowledged documents, it acknowledges each one to avoid reprocessing. Neither side offers an idempotency key, so ml-connector dedupes on the Concur document id plus a BullMQ jobId and relies on the D365 natural key, the invoice number plus vendor account, catching the duplicate-key error if a document is re-read. D365 service protection returns HTTP 429 with a Retry-After header, so it honors the wait and backs off. Posted D365 ledger entries are read-only, so it never writes finished journals back, only confirmations to Concur. Where Concur ESS subscriptions are enabled it can take a status-change push as a trigger while verifying the Concur-Signature, but the scheduled poll remains the backbone. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized professional services firm of about six hundred staff runs Microsoft Dynamics 365 F&O for finance and accounts payable and uses SAP Concur for employee travel, expense, and supplier invoice capture. Before the integration, the accounting team exported approved expense and invoice batches from Concur each week and keyed the totals into Dynamics 365 F&O by hand, which delayed reimbursements, produced posting errors against the wrong cost center, and left Concur showing documents as approved long after they were actually paid. With the two systems connected, each approved Concur document posts into D365 as a vendor invoice or journal allocated to the correct account and dimension, and a posting and payment confirmation flows back so Concur reflects the true state. The weekly re-keying step is gone and the expense backlog clears within the polling window.

What you can do

• •Post approved SAP Concur expense reports and invoices into Microsoft Dynamics 365 F&O as vendor invoices and ledger journals.
• •Send posting and payment confirmations back to Concur so each document closes to its posted and paid state.
• •Map Concur cost objects to D365 main accounts and financial dimensions, scoped to the correct legal entity.
• •Bridge Concur company-level OAuth and refresh-token rotation with the Entra ID client credentials token for D365.
• •Poll the Concur Financial Integration feed on a schedule with document and jobId dedup, Retry-After handling, and a full audit trail.

Questions

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

The main flow is SAP Concur into Microsoft Dynamics 365 F&O. Approved expense reports and invoices move from Concur into D365 as vendor invoices and ledger journals, and posting and payment confirmations flow back to Concur. Vendor master records move from D365 into Concur, and because posted D365 ledger entries are read-only, ml-connector never writes finished journals back to either side.

Why does the integration use Concur's Financial Integration Service rather than the older invoice APIs?

The Financial Integration Service v4 is purpose-built for ERP sync. It lists only approved documents ready for posting, pages through them with page and limit parameters, and accepts acknowledgements, posting confirmations, and payment confirmations back from the ERP. It also reports documents that were previously acknowledged, which gives the integration protection against reprocessing the same expense or invoice twice.

How does the connector handle authentication and the lack of an idempotency key on both sides?

ml-connector runs Concur's company-level OAuth, exchanging the one-time App Center auth token within its 24-hour window for a six-month refresh token, and uses the geolocation the token returns. For D365 it uses an Entra ID client credentials token against the tenant-specific environment. Since neither side offers an idempotency key, it dedupes on the Concur document id plus a BullMQ jobId and on the D365 natural key of invoice number and vendor account.