QAD and ServiceNow integration

What moves between them

Procurement data flows from QAD into ServiceNow. ml-connector reads QAD suppliers, purchase orders, and goods receipts and writes them into the ServiceNow Source-to-Pay supplier and purchase order staging tables so buyers and AP staff can see live order and receipt status. Accounts Payable data flows the other direction: approved supplier invoices entered or coded in ServiceNow Accounts Payable Operations are pulled back into QAD, where they post against the matching purchase order and receipt for three-way match. Cost centers and GL accounts are aligned in both directions so invoice lines reference dimensions that already exist in QAD. The cadence is a scheduled poll on each side, typically every few minutes for receipts and invoices and less often for supplier master data.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the ServiceNow side it requests an OAuth2 client credentials token from {instance}/oauth_token.do and refreshes it before the 30-minute expiry or when a call returns 401. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base URL, and validates entity paths against that instance. Because neither system exposes a registerable webhook, both sides are polled: ServiceNow with sysparm_query on sys_updated_on for incremental reads and offset paging up to the limit, QAD on its business document endpoints. QAD invoices only post after the matching receipt exists, so receipts are synced before invoices are pulled back. ServiceNow has no native idempotency key, so the connector queries on the QAD external id before writing to avoid duplicate staging records. ServiceNow rate limits return HTTP 429 with a Retry-After header, so the connector backs off and retries. Module tables such as the APO invoice table require the service account to hold the right ServiceNow roles, which is verified at onboarding. 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 around 600 employees runs QAD Adaptive ERP for production, procurement, and finance, and has rolled out ServiceNow Source-to-Pay so its shared-services team can manage purchasing requests and AP invoice approvals in one place. Before the integration, buyers raised orders in QAD but tracked approvals in ServiceNow, and AP clerks re-keyed coded invoices from ServiceNow back into QAD, where they often stalled because the matching receipt had not been confirmed. With QAD and ServiceNow connected, purchase orders and goods receipts flow into ServiceNow so approvers see real receipt status, and approved invoices flow back into QAD only after the receipt is posted, so the three-way match clears on the first try. The re-keying step is gone and invoice exceptions drop.

What you can do

• •Sync QAD suppliers, purchase orders, and goods receipts into ServiceNow Source-to-Pay staging tables.
• •Pull approved supplier invoices from ServiceNow Accounts Payable back into QAD for three-way match against PO receipts.
• •Align cost centers and GL accounts across both systems so invoice lines reference valid QAD dimensions.
• •Authenticate ServiceNow with OAuth2 client credentials and QAD with its tenant-specific token, refreshing before expiry.
• •Poll both systems on a schedule by update time, with backoff on rate limits, retries, and a full audit trail on every record.

Questions

Which direction does data move between QAD and ServiceNow?

Both directions. Suppliers, purchase orders, and goods receipts move from QAD into ServiceNow Source-to-Pay staging tables, and approved supplier invoices move from ServiceNow Accounts Payable back into QAD. Cost centers and GL accounts are aligned in both directions so invoice lines land on valid QAD dimensions.

Does ServiceNow support webhooks for real-time sync?

ServiceNow has no built-in outbound webhook registration that an external service can subscribe to, so ml-connector defaults to polling the Table API by sys_updated_on on a schedule. A ServiceNow admin can optionally configure a Business Rule and Outbound REST Message to push events to the connector for near-real-time delivery, but that setup is done on the instance, not registered through an API.

What does the ServiceNow side need configured before the integration works?

The Source-to-Pay and Accounts Payable modules must be licensed and active, since a base ITSM instance does not include the procurement and invoice tables. For OAuth2 client credentials, an admin must enable the inbound client credentials system property and assign the service account the module roles for procurement and Accounts Payable, otherwise calls to those tables return 401 or empty results.