Which direction does data move between QAD and Procurify?

The main flow is Procurify into QAD. Approved purchase orders and AP bills move from Procurify into QAD as purchase orders and supplier invoices, while QAD suppliers and GL accounts flow back into Procurify as vendors and account codes. Procurify payments are read-only, so ml-connector reads payment status for reconciliation but does not write financial entries back.

How does the integration get data out of Procurify without webhooks?

Procurify does not support webhooks, so ml-connector polls its REST endpoints on a schedule you set. It uses last_modified and date-range filters to read only changed records and walks pages with the metadata.next cursor. It also backs off on 429 and 503 responses, since Procurify can suspend API access on excessive requests.

Why are bills held before they post into QAD?

QAD matches supplier invoices against posted purchase order receipts in a three-way match. ml-connector holds a Procurify bill until the related QAD PO receipt exists, so the invoice posts cleanly instead of failing the match. Vendors and account codes are aligned first so every invoice line references an account that already exists in QAD.

QADProcurify

QAD and Procurify integration

QAD runs manufacturing, procurement, and finance. Procurify runs purchase requests, approvals, and spend management. Connecting the two keeps purchasing and the ledger in agreement without re-keying. Approved purchase orders and AP bills from Procurify flow into QAD as purchase orders and supplier invoices, while QAD suppliers and GL accounts flow back so Procurify buyers select valid vendors and account codes. ml-connector handles the different APIs on each side and moves 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, and supplier invoices three-way match against posted PO receipts.

How Procurify works

Procurify exposes vendors, purchase orders, requisitions, order items, AP bills, payments, account codes, locations, departments, and users through its REST API over HTTPS, split across v3 (vendors, purchase orders, account codes, users) and v2 (AP bills, payments, locations). Authentication is OAuth2 client credentials against a per-customer subdomain, returning a bearer token that lives 24 hours, and every call also requires the X-Procurify-Client header. Procurify does not support webhooks, so all records are read by polling with last-modified and date-range filters. Purchase orders cannot be created directly; they are generated when requisitions are approved.

What moves between them

The main flow runs from Procurify into QAD. ml-connector reads approved Procurify purchase orders and AP bills and posts them into QAD as purchase orders and supplier invoices, mapped to the matching QAD suppliers and GL accounts. Reference data flows the other direction: QAD suppliers and GL accounts are pushed into Procurify as vendors and account codes so buyers select valid values at request time. Procurify payments are read-only, so ml-connector reads payment status for reconciliation but never writes financial entries back. Because supplier invoices three-way match in QAD, bills post after the related PO receipt exists.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Procurify side it requests an OAuth2 client-credentials token per customer subdomain, caches it for its 24 hour life, refreshes before expiry, and sends the X-Procurify-Client header on every call, since a missing header returns 403 even with a valid token. On the QAD side it accepts the full tenant URL per customer, because QAD publishes no shared base address. Procurify purchase orders map to QAD purchase orders and Procurify AP bills map to QAD supplier invoices, with vendors and account codes aligned first so every line references an account that already exists in QAD. Because neither side offers webhooks for this pair, ml-connector polls Procurify on a schedule using last_modified and date-range filters and walks pages with the metadata.next cursor. Bills are held until the matching QAD PO receipt is posted, so the three-way match does not fail. Procurify warns that excessive requests can suspend API access, so ml-connector backs off on 429 and 503 responses and spaces page reads. 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 and finance and rolls out Procurify so plant and office staff can raise purchase requests with proper approvals. Before the integration, an AP clerk copied approved Procurify purchase orders and supplier bills into QAD by hand and chased vendor and account-code mismatches between the two systems. With QAD and Procurify connected, approved purchase orders and bills land in QAD automatically against the right suppliers and GL accounts, and QAD vendor and account changes flow back so buyers always pick valid values. The clerk reviews exceptions instead of re-typing every order, and month-end starts with purchasing and the ledger already aligned.

What you can do

Post approved Procurify purchase orders into QAD as purchase orders against the matching suppliers.
Post Procurify AP bills into QAD as supplier invoices after the related PO receipt is posted.
Push QAD suppliers and GL accounts into Procurify as vendors and account codes so buyers pick valid values.
Bridge Procurify OAuth2 client-credentials tokens, the X-Procurify-Client header, and QAD tenant login.
Poll Procurify on a schedule with last-modified filters, backoff on rate limits, and a full audit trail on every record.

Questions

Which direction does data move between QAD and Procurify?: The main flow is Procurify into QAD. Approved purchase orders and AP bills move from Procurify into QAD as purchase orders and supplier invoices, while QAD suppliers and GL accounts flow back into Procurify as vendors and account codes. Procurify payments are read-only, so ml-connector reads payment status for reconciliation but does not write financial entries back.
How does the integration get data out of Procurify without webhooks?: Procurify does not support webhooks, so ml-connector polls its REST endpoints on a schedule you set. It uses last_modified and date-range filters to read only changed records and walks pages with the metadata.next cursor. It also backs off on 429 and 503 responses, since Procurify can suspend API access on excessive requests.
Why are bills held before they post into QAD?: QAD matches supplier invoices against posted purchase order receipts in a three-way match. ml-connector holds a Procurify bill until the related QAD PO receipt exists, so the invoice posts cleanly instead of failing the match. Vendors and account codes are aligned first so every invoice line references an account that already exists in QAD.

Connect QAD and Procurify

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

Get started