Acumatica and Avalara integration

What moves between them

The main flow runs from Acumatica into Avalara. As Acumatica sales invoices and AP bills are created or released, ml-connector reads them and posts each as an AvaTax transaction, a SalesInvoice type for sales and a PurchaseInvoice type for AP bills, carrying the line amounts, item tax codes, and ship-from and ship-to addresses. AvaTax calculates the tax synchronously and returns it, and ml-connector writes the tax amount and the committed document code back onto the Acumatica record. Item-to-tax-code and company-code reference data is aligned so every line is classified. AvaTax stores no ERP master data, so vendors, purchase orders, and GL accounts stay in Acumatica and are only referenced by code.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the AvaTax Account ID and License Key as an HTTP Basic header, and uses an Acumatica OAuth token that it refreshes when a call returns 401. It accepts the full Acumatica instance URL and endpoint version per customer, since a wrong version returns 404, and it wraps all Acumatica field values in value objects. Because Acumatica drives the workflow, ml-connector polls Acumatica documents on LastModifiedDateTime, or consumes Push Notifications where the customer has configured them, rather than waiting on AvaTax, which never pushes. Each transaction reuses the Acumatica reference number as the AvaTax document code, so a retry updates the uncommitted transaction in place instead of creating a duplicate; for committed documents it uses createOrAdjust. Addresses are pre-checked with the AvaTax resolve endpoint so an invalid address does not fail calculation. Both sides return HTTP 429 under load, so ml-connector backs off with jitter, and every record carries a full audit trail and can be replayed.

A real-world example

A mid-sized distributor running Acumatica across several state warehouses sells into dozens of tax jurisdictions. Before the integration, the finance team looked up rates by hand or trusted static tax tables, which drifted as rates and nexus rules changed, leading to under-collected tax and correction work at filing time. With Acumatica and Avalara connected, each sales invoice is sent to AvaTax as it is released, the correct jurisdiction tax comes back on the document, and AP bills are run through AvaTax for self-assessed use tax. The team stops maintaining rate tables, and the numbers that feed the tax returns are already determined by Avalara.

What you can do

• •Send Acumatica sales invoices to Avalara AvaTax as SalesInvoice transactions and write the calculated tax back onto the document.
• •Run Acumatica AP bills through AvaTax as PurchaseInvoice transactions for self-assessed use tax.
• •Map Acumatica items to Avalara tax codes and align company codes so every transaction line is classified correctly.
• •Authenticate Acumatica with OAuth 2.0 and AvaTax with the Account ID and License Key Basic header.
• •Reuse the Acumatica reference number as the AvaTax document code so retries adjust in place instead of double-posting.

Questions

Which direction does data move between Acumatica and Avalara?

The main flow is Acumatica into Avalara. Sales invoices and AP bills are read from Acumatica and posted to AvaTax for tax calculation, then the calculated tax and committed document code are written back onto the Acumatica record. AvaTax holds no vendors, purchase orders, or GL accounts, so that master data stays in Acumatica and is only referenced by code.

How does the integration avoid double-posting tax transactions?

AvaTax uses the document code on a transaction as its idempotency key, so ml-connector reuses the Acumatica reference number as that code. If a transaction is still uncommitted, re-sending the same code updates it in place, and for committed documents ml-connector uses the createOrAdjust call. This makes a retry after a timeout safe rather than a source of duplicate tax lines.

Does Avalara push events back to Acumatica when tax is calculated?

No. AvaTax does not push webhooks and has no outbound callback, and its CreateTransaction call is synchronous, returning the calculated tax inline. ml-connector therefore gets the result on the same request it sends, and for reconciliation it polls ListTransactionsByCompany on a schedule rather than waiting for a push from Avalara.