Which direction does data move between QAD and BILL?

The main flow is QAD into BILL. Approved supplier invoices and their vendors move from QAD into BILL as bills for payment, while BILL payment and bill status flows back into QAD against the originating invoice. GL accounts and departments are aligned so every bill line lands on a valid account.

Can purchase orders be synced into BILL?

No. BILL is built around accounts payable and receivable and has no purchase order entity in its v3 API. ml-connector keeps purchase orders in QAD where they belong and sends only the approved supplier invoice into BILL as a bill for payment.

How does the integration handle BILL session tokens and QAD's lack of webhooks?

BILL uses a session token from a login call that expires after inactivity, so ml-connector re-authenticates automatically when a request returns a 401. Because QAD cloud has no webhooks, it polls QAD supplier invoices on a schedule, while on the BILL side it can also consume signed payment webhooks verified with HMAC-SHA256.

QADBILL

QAD and BILL integration

QAD runs manufacturing, procurement, and finance. BILL runs accounts payable, paying vendors and tracking bills. Connecting the two moves approved supplier invoices out of QAD and into BILL for payment without re-keying, and brings the payment result back so the QAD ledger reflects what was actually paid. Vendors stay aligned across both systems, so a bill in BILL always references a known supplier. ml-connector handles the different auth on each side and moves the data on a schedule you control.

How QAD works

QAD Adaptive ERP exposes suppliers, purchase orders, supplier invoices, GL accounts, cost centers, items, and goods receipts 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. 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.

How BILL works

BILL exposes vendors, bills, AP payments, recurring bills, vendor credits, AR customers and invoices, chart of accounts, and funding accounts through its v3 REST API. Authentication uses a session token: a login call with a developer key, organization ID, and account credentials returns a sessionId that is sent on every later request and expires after inactivity, so the connector re-logs in on a 401. BILL supports push webhooks signed with HMAC-SHA256 for vendor, bill, payment, and invoice events, but does not support purchase orders, since it is built around AP and AR rather than procurement. Pagination is offset based and the API allows only three concurrent calls per organization.

What moves between them

The main flow runs from QAD into BILL. ml-connector reads approved supplier invoices in QAD and creates them as bills in BILL, with each line coded to the mapped GL account and department, and it creates or updates the matching vendor first so every bill references a known supplier. Purchase orders are not sent, because BILL has no purchase order entity, so only the payable invoice moves. In the return direction, ml-connector reads BILL payment and bill status, through scheduled polling and the BILL payment webhooks where they are enabled, and writes the payment result back to QAD against the originating supplier invoice. Reference data such as GL accounts and cost centers is aligned so every bill line lands on a valid account.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For BILL it performs the login call to obtain a sessionId, sends it on every request, and re-authenticates automatically when a call returns a 401, since BILL gives no explicit session-expired code and sessions time out after 35 minutes of inactivity. On the QAD side it accepts the full tenant URL per customer, because QAD publishes no shared base address, and validates entity paths against that instance. Because QAD cloud is pull-only, it polls QAD supplier invoices on a schedule rather than waiting for a push, and on the BILL side it can also receive signed payment and bill webhooks, verified with HMAC-SHA256 against the one-time security key from the subscription. GL accounts and departments are mapped first, so every bill line references an account that already exists on both sides. BILL has no idempotency key, so ml-connector checks existing BILL entity IDs before creating a bill or payment to avoid duplicates, and it keeps in-flight calls within BILL's limit of three per organization. BILL rate limits return an hourly-cap error, so it backs off and retries, and 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 runs QAD Adaptive ERP for production, procurement, and supplier invoicing, and the accounting team pays vendors through BILL. Before the integration, a clerk exported approved supplier invoices from QAD and re-entered each one as a bill in BILL by hand, then went back into QAD after each payment run to mark which invoices were paid, which left the ledger lagging and prone to typos. With QAD and BILL connected, approved supplier invoices flow into BILL as bills coded to the right accounts, vendors stay aligned, and payment status comes back into QAD automatically. The double entry is gone and the QAD ledger matches what BILL actually paid.

What you can do

Create approved QAD supplier invoices as bills in BILL, coded to the mapped GL account and department.
Keep vendors aligned so every BILL bill references a supplier that exists in QAD.
Write BILL payment and bill status back to QAD against the originating supplier invoice.
Authenticate BILL with its session token and re-login on expiry, and QAD with its tenant-specific token.
Poll QAD on a schedule and verify signed BILL payment webhooks, with retries and a full audit trail on every record.

Questions

Which direction does data move between QAD and BILL?: The main flow is QAD into BILL. Approved supplier invoices and their vendors move from QAD into BILL as bills for payment, while BILL payment and bill status flows back into QAD against the originating invoice. GL accounts and departments are aligned so every bill line lands on a valid account.
Can purchase orders be synced into BILL?: No. BILL is built around accounts payable and receivable and has no purchase order entity in its v3 API. ml-connector keeps purchase orders in QAD where they belong and sends only the approved supplier invoice into BILL as a bill for payment.
How does the integration handle BILL session tokens and QAD's lack of webhooks?: BILL uses a session token from a login call that expires after inactivity, so ml-connector re-authenticates automatically when a request returns a 401. Because QAD cloud has no webhooks, it polls QAD supplier invoices on a schedule, while on the BILL side it can also consume signed payment webhooks verified with HMAC-SHA256.

Connect QAD and BILL

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

Get started