QAD and Paylocity integration

What moves between them

The main flow runs from Paylocity into QAD. After each Payroll Processed event, ml-connector reads the matching pay statement totals from Paylocity, maps the earning, deduction, and tax codes to QAD GL accounts, and posts the labor cost journal into QAD's general ledger against the correct cost centers. Employee records flow the same direction so QAD headcount reflects Paylocity hires, terminations, and rehires. Reference data such as cost centers, departments, and work locations is aligned so payroll allocations land on valid QAD dimensions. Paylocity has no GL objects, so ml-connector never writes financial entries back into payroll; it only reads pay statements and employee data from that side.

How ml-connector handles it

ml-connector stores both credential sets encrypted and requests a fresh Paylocity bearer token before the one-hour token expires, retrying with a new token when a call returns 401. Because the Paylocity client secret must be rotated annually, it tracks the rotation reminder window so a lapse does not turn into an outage. 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. Paylocity webhook payloads carry only a company ID and an employee or process ID, so on each event ml-connector calls the Paylocity API to fetch the full pay statement or employee record before posting to QAD. Cost centers, departments, and work locations are mapped first, so every payroll journal line references a GL account and cost center that already exists in QAD. Paylocity webhooks have no HMAC signature, so the connector secures the callback with HTTP Basic auth over TLS and de-duplicates by employee or process ID, since the Employee Change event can fire several times per minute. Paylocity returns HTTP 429 when its throughput limit is exceeded, so ml-connector backs off and retries with exponential backoff, and it stays under the recommended request rate to keep the partner error rate low. Where QAD cloud is pull-only, it can also poll on a schedule tied to your payroll calendar instead of waiting for a webhook. One edge case to watch: when creating or updating an employee, the effective date must be on or after the hire date, or department and location data will silently fail to associate. 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 Paylocity for payroll, HR, and time tracking across two plants and a head office. Before the integration, the finance team exported the payroll register from Paylocity 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 Paylocity connected, each Payroll Processed event flows the pay statement totals into QAD automatically, allocated to the cost center for each plant, and employee 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 Paylocity payroll totals into QAD's general ledger after every pay run, allocated to the correct cost centers.
• •Keep QAD headcount aligned with Paylocity new hires, terminations, and rehires.
• •Map Paylocity earning, deduction, and tax codes to QAD GL accounts so payroll lands on valid dimensions.
• •Authenticate Paylocity with OAuth2 client credentials and QAD with its tenant-specific token, refreshing tokens automatically.
• •React to Paylocity webhooks or poll on your payroll calendar, with retries and a full audit trail on every record.

Questions

Which direction does data move between QAD and Paylocity?

The main flow is Paylocity into QAD. Pay statement totals and employee records move from Paylocity into QAD, while cost centers, departments, and work locations are aligned so payroll lands on valid accounts. Paylocity has no GL or accounting objects, so ml-connector reads from it but never writes financial entries back into payroll.

Does the integration use Paylocity webhooks or polling?

It can use either. Paylocity pushes New Hire, Termination, and Payroll Processed webhooks, but those payloads carry only identifiers, so ml-connector calls the Paylocity API to fetch the full pay statement or employee record on each event. Because QAD cloud has no webhooks and is pull-only, the connector can also poll on a schedule tied to your payroll calendar.

How does ml-connector handle Paylocity authentication and token expiry?

Paylocity uses an OAuth2 client credentials bearer token that lasts one hour with no refresh flow, and the company ID is a path parameter on every data endpoint. ml-connector stores the credentials encrypted, requests a fresh token before expiry, and retries with a new token on a 401. It also tracks the annual client secret rotation so a lapsed secret does not cause an outage.