Which direction does data move between QAD and Zuora?

The main flow is Zuora into QAD. Posted invoices, payments, and credit memos move from Zuora into QAD as receivables and general ledger entries, and billing accounts are matched to QAD customers. Zuora is the system of record for billing, so ml-connector reads those records rather than writing financial entries back into Zuora.

Does the integration use Zuora webhooks or polling?

It can use both. Where Zuora callout notifications are enabled, ml-connector acts on events such as invoice posted or payment processed and calls back to Zuora for the full record, since the callout payload usually carries only an object ID. Because QAD cloud has no webhook system and is pull-only, it also polls Zuora invoices and payments on the schedule you set, which covers external payments that do not raise a notification.

How does ml-connector handle Zuora authentication and the tenant URL?

ml-connector requests a Zuora OAuth 2.0 client-credentials token and reuses it for its one-hour life rather than fetching a new token per call, because the Zuora auth endpoint has a strict per-IP rate limit. It also captures the customer's Zuora tenant base URL at setup, since Zuora is multi-region with no single global host and the wrong base URL causes a 404 or auth failure.

QADZuora

QAD and Zuora integration

QAD runs manufacturing and finance. Zuora runs subscription billing and revenue collection. Connecting the two moves recurring-revenue records into the ERP without re-keying. Posted invoices, payments, and credit memos from each Zuora billing run flow into QAD as receivables and general ledger entries, and the billing account in Zuora stays matched to the customer record in QAD. ml-connector handles the different APIs on each side and moves the data on a schedule you control or as Zuora callouts arrive.

How QAD works

QAD Adaptive ERP exposes customers, customer invoices, payments, GL accounts, cost centers, and items through REST business document APIs, documented in Swagger inside each customer instance. The cloud product authenticates with a JWT session or OAuth2 bearer token against a tenant-specific URL, so there is no shared hostname or public sandbox. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD has no public webhook system for cloud connectors, so finance records are read by polling on a schedule.

How Zuora works

Zuora exposes billing accounts, subscriptions, invoices, payments, payment methods, credit memos, and the product catalog through its v1 REST API as JSON over HTTPS. Every call uses an OAuth 2.0 client-credentials bearer token, cached and reused for its one-hour life against a tenant-specific multi-region base URL. Most objects support both read and write, though credit memos and refunds require the Invoice Settlement feature on the tenant. Zuora can also push callout notifications over HTTPS with optional HMAC signing, and those payloads usually carry only an event object ID, so the receiver calls back to fetch the full record.

What moves between them

The main flow runs from Zuora into QAD. As each billing run finalizes, ml-connector reads posted Zuora invoices, applied payments, and credit memos and posts them into QAD as customer invoices, receipts, and adjustments against the matching GL accounts. Billing accounts flow the same direction so each Zuora account lines up with a QAD customer, and customer master changes can be aligned so new billing accounts reference a valid QAD customer. Zuora invoices, payments, and memos are the system of record on the billing side, so ml-connector reads them rather than writing financial entries back into Zuora.

How ml-connector handles it

ml-connector stores both credential sets encrypted, requests a Zuora client-credentials token, and reuses it until shortly before its one-hour expiry rather than fetching one per call, since the Zuora auth endpoint has a strict per-IP limit. It accepts the full Zuora tenant base URL per customer because Zuora is multi-region with no shared host, and it does the same on the QAD side, which also publishes no shared base URL. Zuora accounts are matched to QAD customer numbers first, so every invoice and payment posts against a customer and GL account that already exist in QAD. Because QAD cloud is pull-only, it polls Zuora invoices and payments on the schedule you set, and where Zuora callout notifications are enabled it can act on a posted-invoice or payment-processed event and call back to Zuora for the full record. Writes into Zuora carry an idempotency key so a retry does not duplicate, Zuora rate-limit responses return HTTP 429 and trigger backoff with jitter, and credit-memo handling depends on the Invoice Settlement feature being enabled on the tenant. Note that Zuora payment notifications fire for electronic payments only, so external payments are picked up on the polling pass instead. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized SaaS company with around two hundred staff bills its recurring plans in Zuora and runs QAD Adaptive ERP for finance and operations. Before the integration, the accounting team exported invoice and payment registers from Zuora at the end of each billing cycle and re-entered the totals into QAD by hand, then reconciled receivables line by line during month-end close. With QAD and Zuora connected, each finalized invoice, payment, and credit memo posts into QAD against the right customer and GL account as the billing run completes. Month-end close starts with receivables already reconciled, and the manual export-and-rekey step is gone.

What you can do

Post finalized Zuora invoices, payments, and credit memos into QAD as receivables and general ledger entries.
Match each Zuora billing account to its QAD customer so postings land on the right account and GL code.
Authenticate Zuora with OAuth 2.0 client credentials against its tenant base URL, and QAD with its tenant-specific token.
Act on Zuora posted-invoice and payment callout notifications where enabled, and poll on a schedule otherwise.
Send an idempotency key on every Zuora write and back off on HTTP 429, with a full audit trail and replay on each record.

Questions

Which direction does data move between QAD and Zuora?: The main flow is Zuora into QAD. Posted invoices, payments, and credit memos move from Zuora into QAD as receivables and general ledger entries, and billing accounts are matched to QAD customers. Zuora is the system of record for billing, so ml-connector reads those records rather than writing financial entries back into Zuora.
Does the integration use Zuora webhooks or polling?: It can use both. Where Zuora callout notifications are enabled, ml-connector acts on events such as invoice posted or payment processed and calls back to Zuora for the full record, since the callout payload usually carries only an object ID. Because QAD cloud has no webhook system and is pull-only, it also polls Zuora invoices and payments on the schedule you set, which covers external payments that do not raise a notification.
How does ml-connector handle Zuora authentication and the tenant URL?: ml-connector requests a Zuora OAuth 2.0 client-credentials token and reuses it for its one-hour life rather than fetching a new token per call, because the Zuora auth endpoint has a strict per-IP rate limit. It also captures the customer's Zuora tenant base URL at setup, since Zuora is multi-region with no single global host and the wrong base URL causes a 404 or auth failure.

Connect QAD and Zuora

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started