QAD and Airbase integration

What moves between them

The main flow runs from Airbase into QAD. As bills clear their approval workflow in Airbase, ml-connector reads them and posts the matching supplier invoices into QAD, then records the AP payment in QAD once Airbase marks the bill paid. Vendor records move the same direction so each Airbase bill maps to an existing QAD supplier, and purchase order reference numbers are carried so QAD three-way match lines up with Airbase matching. GL accounts are read-only in Airbase, so the QAD chart of accounts stays the source of truth and ml-connector does not write GL accounts back into Airbase.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the Airbase bearer token in the Authorization header against the tenant base URL, and accepts the full QAD instance URL per customer since QAD publishes no shared base address. Because a POST in Airbase does not mean a bill is approved or paid, it tracks the payment_status and approval fields and only posts a QAD supplier invoice once the bill clears approval, then records the AP payment when the status moves to paid. It carries the PO reference on each bill so Airbase auto-matching and the QAD three-way match against PO receipts stay consistent, which means goods receipts must already be posted in QAD. Vendors are mapped first so every bill lands on a valid QAD supplier. Since QAD cloud is pull-only, it polls Airbase bills, payments, and vendors on a schedule rather than waiting for a push, and where Airbase webhooks are enabled it can also receive approval events such as purchase_request_approved. Airbase does not publish rate limits, so ml-connector reads the Retry-After header on a 429 and applies conservative exponential backoff, and it tracks the manually rotated Airbase token so an expiry does not turn into a silent outage. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized contract manufacturer with roughly 300 employees runs QAD Adaptive ERP for production, procurement, and finance, and adopts Airbase to give department managers a self-service way to raise purchase orders and submit vendor bills. Before the integration, the AP team rekeyed every approved Airbase bill into QAD as a supplier invoice and then re-entered each payment after it went out, which slowed month-end close and left vendor masters drifting apart between the two systems. With QAD and Airbase connected, each approved bill flows into QAD as a supplier invoice matched to its purchase order, the payment is recorded once Airbase marks it paid, and vendor records stay aligned. The AP team stops rekeying, and the supplier ledger reconciles against both systems.

What you can do

• •Post approved Airbase bills into QAD as supplier invoices, matched to the right purchase order.
• •Record AP payments in QAD once Airbase marks a bill paid.
• •Keep vendor records aligned so every Airbase bill maps to an existing QAD supplier.
• •Authenticate Airbase with its portal bearer token and QAD with its tenant-specific login.
• •Poll Airbase on a schedule with Retry-After backoff, retries, and a full audit trail on every record.

Questions

Which direction does data move between QAD and Airbase?

The main flow is Airbase into QAD. Approved bills, payments, and vendor records move from Airbase into QAD as supplier invoices, AP payments, and suppliers. GL accounts are read-only in Airbase because the ERP is the source of truth, so ml-connector keeps the QAD chart of accounts authoritative and does not write GL accounts back into Airbase.

How does the integration handle Airbase approval workflows and three-way matching?

A POST to create a bill in Airbase does not mean it is approved or paid, so ml-connector tracks the approval and payment_status fields and only posts a QAD supplier invoice once the bill clears approval. It carries the purchase order reference on each bill so Airbase auto-matching and the QAD three-way match stay consistent. Because QAD matches the invoice against PO receipts, goods receipts must already be posted in QAD.

How does authentication work, and what about the Airbase token rotation?

ml-connector stores both credential sets encrypted, sends the Airbase bearer token in the Authorization header against the tenant base URL, and accepts the full QAD instance URL per customer. Airbase has no public OAuth2 refresh flow, so the token is rotated manually in the portal, and ml-connector tracks the token so a rotation does not cause a silent outage.