Microsoft Dynamics 365 Business Central and Avalara integration

What moves between them

The flow runs from Microsoft Dynamics 365 Business Central into Avalara, with results returning to Business Central. When a sales order or sales invoice is created or changed, ml-connector reads it from Business Central and submits it to Avalara as a transaction of the matching type using the document number as the Avalara code. Avalara returns the calculated tax, which ml-connector writes back onto the Business Central document lines and header. Item-to-tax-code and customer mappings move from Business Central into Avalara so each line carries a valid tax code. Sales orders are sent uncommitted for estimation; when the invoice posts in Business Central, the connector commits the corresponding Avalara transaction so it is recorded for filing.

How ml-connector handles it

ml-connector stores both credential sets encrypted, requesting a Business Central bearer token from Microsoft Entra with the client credentials grant and refreshing it on a 401, while sending the Avalara account ID and license key as an HTTP Basic header on every call. Business Central sales orders and sales invoices support push webhooks, so the connector registers subscriptions, answers the mandatory validation-token handshake, and renews them before the three-day expiry; because the notification carries no data, it then fetches the changed document by id. Where push is unavailable it polls with an OData filter on lastModifiedDateTime. Each document maps to an Avalara transaction whose code is the Business Central document number, which makes retries safe: an uncommitted code is updated in place, and the createOrAdjust call keeps repeated submissions idempotent. Business Central item numbers map to Avalara tax codes, and addresses are validated through the Avalara resolve endpoint before calculation so a bad address does not fail the call silently. A committed Avalara transaction cannot be overwritten, so a later change to a posted invoice triggers a void and re-create or an adjustment rather than a blind resend. Avalara returns HTTP 429 without a documented retry header, so the connector backs off 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 online and wholesale retailer with roughly 150 staff sells across several states from a single Microsoft Dynamics 365 Business Central tenant. Before the integration, staff maintained tax rates by hand inside Business Central and reconciled them against filing software each month, which led to wrong rates on shipments into newer states and slow, error-prone month-end close. With Business Central connected to Avalara, every sales order is rated by Avalara as it is entered, the invoice carries Avalara-calculated tax at the line level, and the transaction is committed in Avalara when the invoice posts, so the filing data already matches the ledger and no one re-keys rates.

What you can do

• •Calculate sales and use tax on Business Central sales orders and invoices through the Avalara AvaTax service in real time.
• •Write Avalara-calculated tax amounts back onto Business Central document lines and headers.
• •Commit the Avalara transaction automatically when the matching Business Central invoice is posted.
• •Map Business Central items and customers to Avalara tax codes and customer codes so every line is classified correctly.
• •Keep submissions idempotent by using the Business Central document number as the Avalara transaction code with createOrAdjust.

Questions

Does Avalara send tax results back to Business Central automatically?

No. Avalara has no outbound webhooks and its Notifications resource is pull-only. ml-connector drives the exchange: it sends each Business Central document to the AvaTax transaction endpoint, receives the calculated tax inline in that same synchronous call, and writes it back onto the Business Central document. There is no waiting on a callback from Avalara.

How does the connector know when a Business Central sales document changes?

Sales orders and sales invoices support Business Central push webhooks, so the connector registers a subscription, completes the validation-token handshake, and renews it before the three-day expiry. Because the notification carries only a change signal and no data, the connector then fetches the document by id. Where push is not used, it polls with an OData filter on lastModifiedDateTime.

What happens if the same invoice is sent to Avalara twice?

Each Avalara transaction uses the Business Central document number as its code, which acts as the idempotency key. Resending an uncommitted transaction updates it in place, and the connector uses the createOrAdjust call so repeats are safe. Once a transaction is committed it cannot be overwritten, so a later change to a posted invoice is handled with a void and re-create or an adjustment instead.