QAD and TaxJar integration

What moves between them

The main flow runs from QAD into TaxJar. ml-connector reads finalized QAD sales invoices and posts them to the TaxJar orders endpoint as transactions, and posts QAD credit memos to the refunds endpoint, each linked back to the original order. Transactions are sent only after an order is finalized and shipped, because states receive this reporting data directly. Reference data moves the same direction: QAD customers map to TaxJar customer records carrying the exemption type so taxable and exempt lines are handled correctly. Nexus regions, location rates, and tax categories are read from TaxJar on a schedule so QAD billing reflects the merchant's current obligations.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the TaxJar side it sends the API token in the Authorization header on every request and pins the x-api-version header so response shapes stay stable, pointing test traffic at the sandbox base URL where a separate token is configured. 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 TaxJar pushes no webhooks, the flow is driven from QAD: it polls QAD for newly finalized invoices and credit memos on your schedule, then posts them to TaxJar. The QAD invoice number is used as the TaxJar transaction_id, which acts as the dedup key, so a retry follows TaxJar's upsert pattern: a 422 conflict falls back to PUT and a 404 falls back to POST, and a duplicate is never filed. The shipping amount is always sent, including zero, because omitting it causes calculation errors, and zero-tax orders are still reported because states want gross sales. Customer exemption types are mapped first, since a customer-level exemption overrides order-level settings. Reported transactions are not modified afterward, so corrections go through a refund rather than an edit. TaxJar rate limits return per minute, so ml-connector backs off and retries, and every record carries a full audit trail and can be replayed if a call fails.

A real-world example

A mid-sized consumer goods manufacturer runs QAD Adaptive ERP for order management, inventory, and finance, and ships direct to customers across many US states. Before the integration, the finance team exported shipped orders each period and re-keyed them into TaxJar by hand to build the filing data, which was slow and left gaps when an order was missed or a credit was not recorded. With QAD and TaxJar connected, each finalized QAD invoice is reported to TaxJar automatically as a transaction, credit memos flow through as refunds, and the nexus regions TaxJar tracks come back into view so billing reflects current obligations. The manual export step is gone and the reported transactions match the QAD ledger.

What you can do

• •Report finalized QAD sales invoices to TaxJar as order transactions after shipment.
• •Send QAD credit memos to TaxJar as refunds linked back to the original order.
• •Use the QAD invoice number as the TaxJar transaction_id and upsert on conflict so retries never double-file.
• •Map QAD customers to TaxJar customer records with the right exemption type for accurate handling.
• •Read TaxJar nexus regions, rates, and tax categories on a schedule so QAD reflects current tax obligations.

Questions

Which direction does data move between QAD and TaxJar?

The main flow is QAD into TaxJar. Finalized QAD sales invoices are posted to TaxJar as order transactions and QAD credit memos as refunds, and QAD customers are mapped to TaxJar customer records with their exemption type. Nexus regions, rates, and tax categories are read back from TaxJar on a schedule so QAD reflects current obligations.

How does the integration avoid reporting the same QAD invoice twice in TaxJar?

ml-connector uses the QAD invoice number as the TaxJar transaction_id, which TaxJar treats as the natural dedup key. It follows TaxJar's recommended upsert pattern, so a POST that returns 422 because the transaction exists falls back to PUT, and a PUT that returns 404 falls back to POST. That makes a retry safe and prevents a duplicate filing.

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

TaxJar pushes no webhooks and has no event subscription mechanism, and QAD cloud has no webhook system either, so the flow is driven from QAD. ml-connector polls QAD for newly finalized invoices and credit memos on a schedule you set, then posts them to TaxJar. Nexus regions and rates are also read from TaxJar by polling so QAD billing stays current.