Which direction does data move between QAD and Ramp?

Records move both ways. QAD vendors and purchase orders flow into Ramp so spend codes against the right supplier, and approved bills and cleared card transactions flow from Ramp into QAD as supplier invoices and GL entries. GL accounts, departments, and cost centers are aligned across both systems so every posted line references a valid QAD dimension.

Does the integration use Ramp webhooks or polling?

It uses both, matched to each system. Ramp pushes bill, transaction, and vendor events over webhooks signed with HMAC-SHA256, which ml-connector verifies and then re-fetches through the GET endpoint for authoritative state. QAD has no webhook system, so ml-connector polls QAD suppliers, purchase orders, and goods receipts on a schedule you control.

How does the integration handle QAD's three-way match?

QAD requires a goods receipt to post before a supplier invoice. ml-connector links each Ramp bill to its originating purchase order through the shared purchase order line item ids that both objects carry, and waits for the QAD goods receipt before posting the supplier invoice. That keeps the bill, purchase order, and receipt matched the way QAD expects.

QADRamp

QAD and Ramp integration

QAD runs manufacturing and finance. Ramp runs corporate cards, bill pay, and spend management. Connecting the two keeps supplier records and purchase orders consistent across both, and moves Ramp bills and card spend into QAD's general ledger without re-keying. Vendors and purchase orders from QAD line up with Ramp so every charge codes against a real supplier, and approved bills and cleared transactions post back into QAD against valid accounts and cost centers. ml-connector handles the very different APIs on each side and runs the sync 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 or public sandbox. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD has no native webhook system for cloud connectors, so finance records are read by polling, and supplier invoices use three-way match, meaning goods receipts must post before invoices.

How Ramp works

Ramp exposes bills, card transactions, vendors, purchase orders, GL accounts, accounting dimensions, departments, and reimbursements through the Ramp Developer API, a REST API with JSON bodies and cursor-based pagination. Authentication uses OAuth2 client credentials over HTTP Basic, producing an opaque ten-day access token, so there is no certificate to manage. Vendors have no direct create endpoint and are created implicitly through bills, while bills, purchase orders, and GL accounts can be written directly. Ramp also pushes bill, transaction, and vendor events over webhooks signed with HMAC-SHA256, which are treated as triggers to re-fetch the authoritative record.

What moves between them

Records move in both directions. QAD vendors and purchase orders flow into Ramp so card spend and bills code against the correct supplier and PO, mapped through the accounting GL accounts and dimensions Ramp already holds. In the other direction, ml-connector reads approved Ramp bills and cleared card transactions and posts them into QAD as supplier invoices and general ledger entries, allocated to the matching QAD GL accounts and cost centers. GL accounts, departments, and cost centers are aligned across both systems first, so every Ramp line references a dimension that exists in QAD. Because QAD applies three-way match, bills are linked to the originating purchase order through shared purchase order line item ids before they post.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Ramp side it requests a client credentials token over HTTP Basic and refreshes it daily rather than waiting for a 401, since the token is opaque and lasts ten days. 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 suppliers, purchase orders, and goods receipts on a schedule, while Ramp pushes bill and transaction events over signed webhooks that ml-connector verifies with HMAC-SHA256 and then re-fetches through the GET endpoint for authoritative state. GL accounts, departments, and cost centers are mapped first so every posted line lands on a valid QAD account. Bills are linked to their purchase order through shared purchase order line item ids, and ml-connector waits for the QAD goods receipt before posting a supplier invoice so three-way match holds. Every POST and PATCH to Ramp carries an idempotency key, Ramp rate limits return HTTP 429 at 100 requests per minute, so ml-connector backs off and retries, and every record keeps a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized contract manufacturer with around 300 employees runs QAD Adaptive ERP for production, procurement, and finance, and rolls out Ramp cards and bill pay to control spend across its plants and offices. Before the integration, the AP team re-keyed Ramp bills and card statements into QAD by hand, suppliers existed under different names in each system, and card charges often landed on the wrong cost center or with no purchase order at all. With QAD and Ramp connected, QAD vendors and purchase orders flow into Ramp so spend codes against real suppliers, approved bills and cleared transactions post into QAD against the correct GL accounts and cost centers, and bills tie back to their purchase orders. Month-end close starts with spend already coded and reconciled instead of with a stack of statements to re-enter.

What you can do

Sync QAD vendors and purchase orders into Ramp so card spend and bills code against the correct supplier and PO.
Post approved Ramp bills into QAD as supplier invoices, linked to their purchase order for three-way match.
Read cleared Ramp card transactions and post them into QAD's general ledger against valid accounts and cost centers.
Align GL accounts, departments, and cost centers across QAD and Ramp so every line lands on a real dimension.
Authenticate Ramp with OAuth2 client credentials and QAD with its tenant-specific token, with retries and a full audit trail.

Questions

Which direction does data move between QAD and Ramp?: Records move both ways. QAD vendors and purchase orders flow into Ramp so spend codes against the right supplier, and approved bills and cleared card transactions flow from Ramp into QAD as supplier invoices and GL entries. GL accounts, departments, and cost centers are aligned across both systems so every posted line references a valid QAD dimension.
Does the integration use Ramp webhooks or polling?: It uses both, matched to each system. Ramp pushes bill, transaction, and vendor events over webhooks signed with HMAC-SHA256, which ml-connector verifies and then re-fetches through the GET endpoint for authoritative state. QAD has no webhook system, so ml-connector polls QAD suppliers, purchase orders, and goods receipts on a schedule you control.
How does the integration handle QAD's three-way match?: QAD requires a goods receipt to post before a supplier invoice. ml-connector links each Ramp bill to its originating purchase order through the shared purchase order line item ids that both objects carry, and waits for the QAD goods receipt before posting the supplier invoice. That keeps the bill, purchase order, and receipt matched the way QAD expects.

Connect QAD and Ramp

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

Get started