Microsoft Dynamics 365 F&O and Avalara integration

What moves between them

The main flow runs from Microsoft Dynamics 365 F&O into Avalara and back. ml-connector reads sales invoices and vendor invoices from Dynamics, posts each as an AvaTax SalesInvoice or PurchaseInvoice for tax calculation, and writes the returned tax amounts back onto the matching Dynamics document. Item numbers are mapped to Avalara tax codes and the document addresses are sent as ship-from and ship-to so each line is rated for the right jurisdiction. Customer references are carried as the AvaTax customer code so exemptions resolve correctly. Avalara has no ledger or vendor master, so ml-connector never writes accounts or vendors back, and the general ledger stays in Dynamics.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Dynamics side it requests an Entra ID client-credentials token scoped to the environment host and refreshes it before the roughly one-hour expiry, and it accepts the full tenant URL per customer since there is no shared base address. On the Avalara side it builds the Basic header from the account ID and license key and targets the sandbox or production host per environment. Because Avalara is pull-only and synchronous, ml-connector triggers calculation from Dynamics, either from a posted-invoice Business Event or by polling invoices on a schedule, then calls CreateTransaction and gets the tax back inline. It reuses the Dynamics document number as the AvaTax code, so a re-read uncommitted invoice is updated in place rather than duplicated, and it uses CreateOrAdjustTransaction where a document may already be committed. Item numbers are mapped to tax codes first, since a wrong tax code can make taxable goods look exempt, and addresses are pre-validated through addresses/resolve because an invalid address fails the calculation. Dynamics returns HTTP 429 with a Retry-After header and Avalara returns 429 without one, so ml-connector honors Retry-After where present and otherwise applies exponential backoff with jitter. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized distributor with about 400 employees runs Microsoft Dynamics 365 F&O for order management, procurement, and finance, and sells into customers across many states. Before the integration, a clerk looked up tax rates by hand for each invoice, which meant rates were sometimes stale, exempt customers were occasionally charged, and use tax on purchases was reconciled only at quarter end. With Microsoft Dynamics 365 F&O and Avalara connected, each posted sales invoice is rated by Avalara within the trigger window and the calculated tax is written back to the Dynamics document, while purchase invoices are sent as PurchaseInvoice for self-assessed use tax. The rate lookups are gone, exemptions are applied from the customer code, and the tax accounts reconcile without a quarter-end scramble.

What you can do

• •Post Dynamics sales and purchase invoices to Avalara for sales and use tax calculation and write the result back to the document.
• •Map Dynamics item numbers to Avalara tax codes so each invoice line is rated correctly.
• •Send document ship-from and ship-to addresses to Avalara, pre-validated, so tax is calculated for the right jurisdiction.
• •Bridge Microsoft Entra ID OAuth on the Dynamics side and Avalara account ID and license key Basic auth on the other.
• •Reuse the Dynamics document number as the AvaTax code with CreateOrAdjustTransaction so a re-read invoice is updated, not duplicated.

Questions

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

Invoices move from Dynamics into Avalara for calculation, and the returned tax moves back onto the Dynamics document. Avalara holds no chart of accounts, vendor master, or payments, so those stay in Dynamics. ml-connector never writes accounts or vendors back into Avalara; it only sends transactions to be rated and records the tax that comes back.

Does Avalara push tax results, or does ml-connector trigger the calculation?

Avalara does not push webhooks; its CreateTransaction call is synchronous and returns the calculated tax inline. ml-connector triggers the calculation from Dynamics, either from a posted-invoice Business Event or by polling invoices on a schedule, then calls Avalara and writes the result back. To reconcile what Avalara has processed, it can poll ListTransactionsByCompany on a schedule.

How does the integration avoid double-counting a tax transaction?

ml-connector reuses the Dynamics document number as the AvaTax code, which Avalara treats as the idempotency key. Posting the same code for an uncommitted transaction updates it in place, and CreateOrAdjustTransaction handles documents that may already be committed. This means a re-read or retried invoice is corrected rather than duplicated in Avalara.