QAD and Rippling integration

What moves between them

The main flow runs from Rippling into QAD. After each pay run, ml-connector reads worker, compensation, and accounting dimension data from Rippling and posts the labor cost journals into QAD's general ledger, mapped to the matching QAD GL accounts and cost centers. Worker records flow the same direction so QAD headcount reflects Rippling hires, terminations, and rehires. Reference data such as departments, legal entities, and accounting dimensions is aligned so payroll allocations land on valid QAD dimensions. Rippling holds no GL accounts or AP records, so ml-connector never writes financial entries back into Rippling.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Rippling side it supports either the App Shop OAuth flow, refreshing the bearer token before it expires, or a single-tenant API key sent as a Bearer header, and it requests only the scopes the flow needs, such as employees:read, compensation:read, and dimensions:read. 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. It follows offset pagination on the Rippling v1 base API and cursor pagination with next_link on the v2 REST API, and uses the expand parameter to pull manager, legal entity, compensation, and department in one call rather than issuing N+1 requests. Because QAD cloud is pull-only and Rippling webhooks are App Shop only, it polls Rippling workers and the company_activity log on a schedule, or consumes employee lifecycle webhooks where an App Shop listing is in place. Accounting dimensions and departments are mapped first, so every payroll journal line references a GL account and cost center that already exists in QAD. Compensation and other entitlement-gated fields can come back under __meta.redacted_fields rather than as errors, so ml-connector checks that list and only maps fields the scopes allow. Rippling throttling returns HTTP 429 with no Retry-After header, so ml-connector backs off exponentially and retries, and the three-way match in QAD means goods receipts post before any related supplier invoice. 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 about 600 employees across two plants runs QAD Adaptive ERP for production, procurement, and finance, and uses Rippling for HR and payroll. Before the integration, the finance team exported the payroll register from Rippling every pay period and re-entered the labor totals into QAD by hand, then spent the first days of month-end close chasing differences between HR headcount and the labor accounts in the ledger. With QAD and Rippling connected, each pay run's labor cost journal flows into QAD automatically, allocated to the cost center for each plant from Rippling accounting dimensions, and worker changes keep the two systems aligned. Month-end close starts with the labor accounts already reconciled, and the manual re-keying step is gone.

What you can do

• •Post payroll cost journals derived from Rippling pay runs into QAD's general ledger, allocated to the correct cost centers.
• •Keep QAD headcount aligned with Rippling hires, terminations, and rehires.
• •Map Rippling accounting dimensions, departments, and legal entities to QAD GL dimensions so payroll lands on valid accounts.
• •Authenticate Rippling with OAuth 2.0 in the App Shop flow or a single-tenant API key, and QAD with its tenant-specific token.
• •Sync on a schedule with offset and cursor pagination, retries on HTTP 429, and a full audit trail on every record.

Questions

Which direction does data move between QAD and Rippling?

The main flow is Rippling into QAD. Worker, compensation, and accounting dimension data move from Rippling into QAD, where they become labor cost journals and headcount updates. Rippling holds no GL accounts, invoices, or AP records, so ml-connector does not write financial entries back into Rippling.

Does this integration need a Rippling App Shop listing?

No. A single-tenant Bearer API key generated in the Rippling admin console is enough to read workers, compensation, and dimensions for GL export. An App Shop listing with OAuth is only required if you want Rippling to push employee lifecycle webhooks; without it, ml-connector polls workers and the company_activity log on a schedule instead.

How does the integration handle QAD's tenant-specific URL and lack of webhooks?

ml-connector accepts the full QAD instance URL per customer, since QAD publishes no shared base address. Because QAD cloud is pull-only, it polls QAD and Rippling on a schedule rather than relying on a push from QAD, and QAD's three-way match means goods receipts post before any related supplier invoice.