QAD and Paychex integration

What moves between them

The main flow runs from Paychex Flex into QAD. ml-connector reads Paychex workers and organization units and keeps QAD headcount and cost centers aligned with hires, terminations, rehires, and department moves. Paychex organizations and locations map to QAD cost centers and dimensions so every workforce record references a QAD value that already exists. Because Paychex Flex holds no GL accounts, invoices, or supplier data, no financial documents move on this connection; the scope is HR and cost-center alignment, not payroll journal posting. QAD cost-center definitions can seed the Paychex organization mapping so both sides agree on department codes.

How ml-connector handles it

ml-connector stores both credential sets encrypted and acquires a fresh Paychex OAuth2 client-credentials token before the prior one expires, since Paychex issues no refresh token. It resolves the Paychex companyId through GET companies at the start of every run, because there is no global worker namespace and each company-scoped path needs that id. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base URL. Paychex worker webhooks for added, demographic, compensation, and employment-status changes carry no data, so ml-connector receives the event and then calls the matching GET endpoint to fetch the current worker, while QAD cloud is polled on a schedule because it has no webhooks. Worker lists are paged with offset and limit up to one hundred records, and the ETag is carried between pages to avoid skipped or duplicated rows when the dataset shifts mid-crawl. Organizations and locations are mapped to QAD cost centers first, so every headcount update lands on a valid dimension. Paychex rate limits return HTTP 429 with a Retry-After header, so ml-connector backs off with jitter and paginates sequentially rather than in parallel, and because Paychex has no idempotency-key scheme it checks for an existing record before any create. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized discrete manufacturer runs QAD Adaptive ERP for production, procurement, and finance, and uses Paychex Flex for payroll and HR across two plants and a head office. Before the integration, the operations team maintained department and headcount data in Paychex but had to re-enter cost-center and staffing changes into QAD by hand, so labor allocations in the ERP drifted out of step with who actually worked where. With QAD and Paychex Flex connected, worker and organization changes flow into QAD automatically, mapped to the cost center for each plant, and the two systems stay aligned without manual re-keying. Cost reporting in QAD reflects the current workforce, and the duplicate data entry is gone.

What you can do

• •Keep QAD headcount aligned with Paychex Flex hires, terminations, rehires, and department moves.
• •Map Paychex organizations and locations to QAD cost centers and dimensions so workforce records land on valid values.
• •Authenticate Paychex with OAuth2 client credentials and refresh the token before expiry, and QAD with its tenant-specific login.
• •React to Paychex worker webhooks by fetching the changed record, and poll QAD on a schedule because it has no webhooks.
• •Page Paychex workers with offset and limit and the ETag for consistency, with backoff on HTTP 429 and a full audit trail on every record.

Questions

Which direction does data move between QAD and Paychex?

The main flow is Paychex Flex into QAD. Workers and organization units move from Paychex into QAD to keep headcount and cost centers aligned, while QAD cost-center definitions can seed the Paychex organization mapping so both sides agree on department codes. Paychex Flex holds no GL accounts or invoices, so no financial documents move on this connection.

Does this integration post payroll journals into QAD?

No. The Paychex Developer API exposes HR and payroll data such as workers, organizations, and payroll checks, but it has no general ledger, supplier, or invoice entities. This connection handles workforce and cost-center alignment, not GL posting, so labor journals are not written into QAD's general ledger from Paychex.

How does ml-connector handle Paychex webhooks and token expiry?

Paychex worker webhooks are notification-only and carry no changed data, so ml-connector receives the event and then calls the matching GET endpoint to fetch the current record. Paychex tokens expire with no refresh token under client credentials, so ml-connector acquires a new token proactively before expiry and re-authenticates once on a 401. Because QAD cloud has no webhooks, QAD is read by polling on a schedule you control.