Microsoft Dynamics 365 F&O and Zuora integration

What moves between them

The main flow runs from Zuora into Microsoft Dynamics 365 F&O. After each billing run, ml-connector reads Zuora posted invoices, electronic payments, and credit memos and books the receivables and cash into D365 customer payment journals and general journal entries, mapped to the matching D365 customers, GL accounts, and financial dimensions. Billing accounts flow the same direction so the D365 customer master reflects new and updated Zuora accounts. Reference data such as customers, currencies, and dimension values is aligned so every posting lands on a valid D365 account and dataAreaId. Posted ledger entries are read-only in D365, so ml-connector never writes financial entries back into Zuora.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two separate logins: a Microsoft Entra ID client-credentials token scoped to the D365 environment host, and a Zuora client-credentials token against the region-specific tenant URL, each refreshed when a call returns 401 and the Zuora token reused until just before its one-hour expiry to respect the lower auth rate limit. Zuora Callout Notifications carry only the object ID, so on each callout ml-connector calls Zuora back for the full invoice, payment, or credit memo, then posts it into D365. Because the Business Events payload is also a stub, the same call-back pattern applies on the D365 side. Zuora accounts map to D365 customers and dataAreaId, and revenue and cash accounts map to D365 main accounts and dimensions before any posting, so journal lines reference accounts that already exist. Only electronic Zuora payments raise notifications, so external payments are picked up by polling. Both sides return HTTP 429, so ml-connector backs off with jitter, sends a Zuora idempotency-key on every POST, and dedupes D365 writes on natural keys and the callout ControlNumber. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized SaaS company bills several thousand recurring subscriptions in Zuora and keeps its books in Microsoft Dynamics 365 F&O. Before the integration, the finance team exported invoice and payment registers from Zuora each billing cycle and re-entered the receivables and cash totals into D365 by hand, then spent the first days of month-end close chasing differences between billed revenue and the AR balance in the ledger. With Microsoft Dynamics 365 F&O and Zuora connected, each billing run's posted invoices, payments, and credit memos flow into the D365 general ledger automatically, allocated to the right customer and dimensions, and account changes keep the customer master aligned. Month-end close starts with receivables already reconciled, and the manual re-keying step is gone.

What you can do

• •Book Zuora posted invoices, electronic payments, and credit memos into the Dynamics 365 F&O general ledger and AR after every billing run.
• •Keep the D365 customer master aligned with new and updated Zuora billing accounts.
• •Map Zuora accounts and currencies to D365 customers, dataAreaId, main accounts, and financial dimensions.
• •Run separate Entra ID and Zuora OAuth client-credential logins and reconcile each callout against the source record before posting.
• •Poll on a schedule for external Zuora payments, with 429 backoff, idempotency keys, and a full audit trail on every record.

Questions

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

The main flow is Zuora into Microsoft Dynamics 365 F&O. Posted invoices, payments, and credit memos move from Zuora into the D365 general ledger and AR, while billing accounts sync the same direction to the D365 customer master. Posted ledger entries are read-only in D365, so ml-connector does not write financial entries back into Zuora.

How does the integration handle two separate OAuth logins?

D365 uses OAuth 2.0 client credentials through Microsoft Entra ID scoped to the environment host, and Zuora uses its own client-credentials token against the region-specific tenant URL. ml-connector stores both credential sets encrypted, refreshes each token on a 401, and reuses the Zuora token until just before its one-hour expiry to stay under the lower Zuora auth rate limit.

Does ml-connector rely on Zuora webhooks for everything?

No. Zuora Callout Notifications fire for billing, account, and electronic payment events, and their body usually carries only an object ID, so ml-connector calls Zuora back for the full record before posting. External or manual payments do not raise notifications, so those are picked up by polling on a schedule, with 429 backoff and replay on failure.