Microsoft Dynamics 365 F&O and Ramp integration

What moves between them

The main flow runs from Ramp into Microsoft Dynamics 365 F&O. ml-connector reads approved Ramp bills and posts them as D365 vendor invoice headers and lines, and reads cleared card transactions and posts them as journal entries against the matching main account and financial dimension. Reference data moves the other direction: D365 vendors, main accounts, and departments are pushed to Ramp so bills and transactions are coded to accounts that already exist in the ledger. Vendors and GL accounts are aligned first, then transactional records flow on each sync. D365 vendor invoices are writable only before posting, so Ramp is treated as the upstream source and the ledger is never written back into Ramp.

How ml-connector handles it

ml-connector stores both credential sets encrypted, requests a D365 Bearer token from Microsoft Entra ID using client credentials with the environment-scoped .default scope, and refreshes it when a call returns 401. The D365 environment host is tenant-specific with no shared base URL, so it is taken as a credential field per customer and entity keys are fully specified, including dataAreaId for the correct legal entity. The Ramp opaque token lasts ten days and is refreshed on a daily schedule rather than waiting for expiry. Ramp bill and transaction webhooks signed with HMAC-SHA256 trigger work as spend settles, and because they are non-authoritative each object is re-fetched by GET before posting. Every Ramp POST and PATCH carries an Idempotency-Key, and on the D365 side natural-key duplicates such as a repeated InvoiceNumber are caught and handled rather than retried blindly. Ramp GL codes map to D365 main accounts, and financial dimensions are passed as the formatted display string that the customer configures under the integrating-applications dimension setup, so a wrong format does not fail silently. A scheduled OData poll backfills anything a webhook missed, and both sides return HTTP 429 under load, so requests back off and retry. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A growing technology services firm of around three hundred staff runs Microsoft Dynamics 365 F&O for finance and gives employees Ramp corporate cards and Ramp bill pay for vendor invoices. Before the integration, an accountant exported Ramp transactions and bills each week and keyed the totals into D365 by hand, then spent the start of month-end close matching card spend to the right accounts and chasing miscoded charges. With the two systems connected, approved bills post as D365 vendor invoices and cleared transactions post as journal entries automatically, each coded to the account and dimension carried over from the ledger. Close starts with spend already recorded against valid accounts, and the weekly export-and-rekey step is gone.

What you can do

• •Post approved Ramp bills into Microsoft Dynamics 365 F&O as vendor invoice headers and lines.
• •Record cleared Ramp card transactions as D365 journal entries against the correct main account and financial dimension.
• •Push the D365 chart of accounts, vendors, and departments to Ramp so spend is coded to valid accounts before it posts.
• •Bridge Ramp OAuth2 client-credential tokens and the D365 Microsoft Entra ID login for each tenant environment.
• •Act on Ramp bill and transaction webhooks verified by HMAC-SHA256, with retries and a full audit trail on every record.

Questions

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

The main flow is Ramp into Microsoft Dynamics 365 F&O. Approved bills and cleared card transactions move from Ramp into D365 as vendor invoices and journal entries. Reference data such as the chart of accounts, vendors, and departments moves the other way so spend is coded correctly. D365 vendor invoices are writable only before posting, so the ledger is not written back into Ramp.

How does the integration handle authentication on each side?

D365 uses OAuth2 client credentials through Microsoft Entra ID, with a scope tied to your tenant-specific environment host and a Bearer token that expires hourly and is refreshed automatically. Ramp uses OAuth2 client credentials sent as HTTP Basic auth, returning an opaque ten-day token that ml-connector refreshes on a daily schedule. Both credential sets are stored encrypted and presented on every request.

Does the integration rely on webhooks or polling?

Both. Ramp pushes HMAC-SHA256 signed webhooks for bills and transactions, so work starts as spend settles, but because Ramp webhooks are non-authoritative each object is re-fetched by GET before it is posted. D365 reference data is read by polling its OData entities on a schedule, and that poll also backfills any Ramp event a webhook missed.