QAD and Avalara integration

What moves between them

The main flow runs from QAD into Avalara AvaTax. ml-connector reads QAD sales invoices and supplier invoices, submits them to Avalara as transactions typed SalesInvoice or PurchaseInvoice, and Avalara returns the calculated tax, rate, and jurisdiction breakdown inline. Those tax amounts are written back onto the QAD documents so the ledger reflects what was filed. Reference data moves the same direction: QAD customers map to Avalara customer codes and QAD items map to Avalara tax codes so each line is classified correctly. Voids and credit memos in QAD are sent to Avalara as void or ReturnInvoice transactions so the tax record stays in step.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Avalara side it builds the HTTP Basic header from the account ID and license key on every request, and points sandbox and production traffic at the correct base URL because sandbox keys are rejected in production. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base address, and validates entity paths against that instance. Because QAD cloud is pull-only and Avalara pushes no webhooks, the integration is driven from QAD: it polls QAD for new and changed invoices on your schedule, then calls Avalara synchronously to calculate tax. The QAD invoice number is used as the Avalara document code, which acts as the idempotency key, so a retried submission updates an uncommitted transaction in place rather than creating a duplicate. Once a transaction is committed in Avalara its code is reserved, so corrections go through void plus re-create or an adjust call rather than a fresh post. Items must carry the right Avalara tax code or taxable goods can appear exempt, so item mapping is set up first. Avalara rate limits return HTTP 429 with no documented retry header, so ml-connector backs off with exponential jitter and retries. Every record carries a full audit trail and can be replayed if a call fails.

A real-world example

A mid-sized industrial equipment manufacturer runs QAD Adaptive ERP for order management, procurement, and finance, and ships to customers across many US states. Before the integration, the billing team kept tax rate tables by hand and re-keyed jurisdiction rates onto invoices, which left them exposed during audits and slowed month-end as someone reconciled what was billed against what was actually owed. With QAD and Avalara AvaTax connected, each QAD invoice is sent to Avalara for real-time calculation, the correct tax and jurisdiction detail come back onto the document, and the committed transaction is ready for Avalara to file. Manual rate maintenance is gone and the filed tax record matches the QAD ledger line for line.

What you can do

• •Calculate sales and use tax on QAD sales and supplier invoices in real time through Avalara AvaTax.
• •Write Avalara's calculated tax, rate, and jurisdiction detail back onto the matching QAD documents.
• •Use the QAD invoice number as the Avalara document code so retries never create duplicate transactions.
• •Map QAD items to Avalara tax codes and QAD customers to Avalara customer codes for correct line classification.
• •Commit transactions and send voids and credit memos so Avalara reporting and returns stay aligned with QAD.

Questions

Which direction does data move between QAD and Avalara?

The main flow is QAD into Avalara AvaTax. QAD sales and supplier invoices are submitted to Avalara as transactions, and the calculated tax is written back onto the QAD documents. QAD customers and items are also mapped into Avalara customer codes and tax codes so each line is classified correctly.

How does the integration avoid filing the same QAD invoice twice in Avalara?

ml-connector uses the QAD invoice number as the Avalara document code, which AvaTax treats as the idempotency key. Posting the same code for an uncommitted transaction updates it in place, so a retry is safe. Once a transaction is committed its code is reserved, so corrections go through a void and re-create or an adjust call rather than a duplicate post.

Does Avalara push events back to QAD, or is everything polled?

Avalara AvaTax does not push webhooks, and QAD cloud has no webhook system either, so the flow is driven from QAD. ml-connector polls QAD for new and changed invoices on a schedule you set, then calls Avalara synchronously, which returns the calculated tax inline. Committed transactions and Avalara notifications can also be read by polling when you need to reconcile.