Microsoft Dynamics 365 F&O and Gusto integration

What moves between them

The main flow runs from Gusto into Microsoft Dynamics 365 F&O. After each payroll is processed, ml-connector reads the Gusto payroll totals and per-employee gross pay, employer taxes, and deductions, and posts them into Dynamics as a general journal mapped to the matching main accounts and financial dimensions. Employee hires and terminations flow the same direction so Dynamics worker and vendor-style records reflect Gusto onboarding and offboarding, and contractor payments can post to accounts payable. Reference data such as departments, locations, and cost dimensions is aligned so every journal line lands on a dimension that already exists in Dynamics. General ledger entries are read-only in Dynamics and Gusto holds no GL, so ml-connector never writes financial entries back into payroll.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two unlike OAuth flows side by side. For Gusto it completes the authorization-code grant per company, holds one access and refresh token set for each company, and rotates the single-use refresh token on every refresh. For Dynamics it requests a client-credentials bearer token from Microsoft Entra ID against the tenant environment host and re-requests it when a call returns 401, since there is no refresh token. Gusto can push a webhook such as payroll.paid, whose HMAC-SHA256 X-Gusto-Signature is verified before processing, but the payload is only a stub, so the connector reads the full payroll back over the API; Dynamics is read over OData on a schedule tied to your pay calendar. Gusto dollar amounts arrive as string decimals and are parsed with decimal precision before they become journal amounts, and financial dimensions are formatted as the display string Dynamics expects so posting does not fail silently. Departments and dimensions are mapped first so each journal line references a valid main account and dimension. Gusto rate limits at 200 requests per minute and Dynamics returns HTTP 429 with Retry-After, so ml-connector backs off and retries, and every record carries a full audit trail and can be replayed if a downstream call fails. Because each Gusto token covers one company, a customer with several Gusto companies authorizes each one separately.

A real-world example

A 120-person specialty contractor runs Microsoft Dynamics 365 F&O for project finance and procurement and uses Gusto for payroll across two divisions. Before the integration, the finance team downloaded the payroll register from Gusto every pay period and keyed the labor totals into Dynamics by hand, then spent the first days of month-end close reconciling headcount against the wage accounts in the ledger. With Microsoft Dynamics 365 F&O and Gusto connected, each processed payroll run posts into Dynamics automatically as a journal split across the right divisions and accounts, and employee changes keep both systems aligned. Month-end close begins with the wage accounts already reconciled, and the manual re-keying step is gone.

What you can do

• •Post each processed Gusto payroll into Microsoft Dynamics 365 F&O as a general journal mapped to the correct main accounts.
• •Split gross pay, employer taxes, and deductions across the right financial dimensions and divisions.
• •Keep Dynamics worker and vendor-style records aligned with Gusto hires and terminations.
• •Run Gusto per-company authorization-code OAuth alongside Dynamics Entra client credentials from one place.
• •Parse Gusto string dollar amounts with decimal precision, with retries and a full audit trail on every record.

Questions

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

The main flow is Gusto into Dynamics. Processed payroll totals and employee records move from Gusto into Microsoft Dynamics 365 F&O, while departments and cost dimensions are aligned so journal lines land on valid accounts. General ledger entries are read-only in Dynamics and Gusto has no GL, so ml-connector does not write financial entries back into payroll.

How are the two different logins handled?

Gusto uses OAuth2 authorization code with one token per company and a single-use refresh token, while Dynamics uses OAuth2 client credentials from Microsoft Entra ID with no refresh token. ml-connector runs both flows, rotating the Gusto refresh token on every use and re-requesting the Dynamics bearer token when a call returns 401. A customer with several Gusto companies authorizes each company separately.

How does the integration deal with Gusto webhooks and string amounts?

Gusto can push a signed webhook such as payroll.paid, and ml-connector verifies its HMAC-SHA256 signature, then reads the full payroll back over the API because the webhook payload is only a stub. Gusto returns dollar values as string decimals, so the connector parses them with decimal precision before they become Dynamics journal amounts to avoid rounding errors.