Which direction does data move between QAD and Dayforce?

The main flow is Dayforce into QAD. Payroll journals and employee records move from Dayforce into QAD, while org units, departments, and job codes are aligned so payroll posts to valid dimensions. Dayforce holds no AP or invoice data and ml-connector does not write financial postings back into Dayforce.

How does ml-connector get payroll journal data out of Dayforce?

Dayforce has no GL account or payroll journal REST endpoint, so the journal data is read through the Reports API against a payroll journal report the customer configures with GL account codes and cost dimensions. That report must be set up inside Dayforce before the connector can pull it. ml-connector reads it after each pay run and maps each line to the matching QAD account and cost center.

Does the integration use webhooks or polling?

It uses polling. Dayforce sends no outbound webhooks to external API callers, and QAD cloud is also pull-only, so ml-connector reads both systems on a schedule tied to your payroll calendar. On the Dayforce side it uses the filterUpdateDateRangeMin and filterUpdateDateRangeMax parameters to fetch only records changed since the last successful sync.

QADDayforce

QAD and Dayforce integration

QAD runs manufacturing and finance. Dayforce runs HR, payroll, and workforce management. Connecting the two moves the labor cost results of each Dayforce pay run into QAD's general ledger without re-keying, and keeps QAD departments aligned with the people Dayforce hires and terminates. Dayforce has no AP, vendor, or invoice modules, so this integration is built around payroll-to-GL posting and employee cost data rather than procurement. ml-connector handles the very different APIs on each side and reads Dayforce on a schedule, since it pushes no real-time events.

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.

How Dayforce works

Dayforce exposes employees, organizational units, jobs and positions, pay summaries, and pre-built reports through its RESTful Web Services API, a JSON REST surface over HTTPS with no SOAP, OData, or GraphQL. Authentication uses an OAuth 2.0 resource owner password grant: a dedicated web-services username and password plus a fixed client ID are sent to the Dayforce identity server to obtain a Bearer token that expires after one hour. Dayforce has no GL account or payroll journal endpoint, so payroll journal data is extracted through the Reports API against a report the customer configures with GL codes and cost dimensions. Dayforce sends no outbound webhooks for direct API callers, so changes are read by polling with date-range filters.

What moves between them

The main flow runs from Dayforce into QAD. After each pay run, ml-connector pulls the configured Dayforce payroll journal report and pay summaries and posts the earnings, tax, and deduction journals into QAD's general ledger, mapped to the matching QAD GL accounts and cost centers. Employee records flow the same direction so QAD headcount reflects Dayforce hires, terminations, and rehires. Org units, departments, and job codes are aligned so payroll allocations land on valid QAD dimensions. Dayforce has no AP or invoice data, so nothing procurement-related moves, and ml-connector never writes financial postings back into Dayforce.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Dayforce side it requests a Bearer token from the identity server using the password grant, caches it, and refreshes it before the one-hour expiry, since the password grant depends on a real user account that must be a non-expiring service login. 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 both systems are pull-only, it polls Dayforce on a schedule tied to your payroll calendar, using filterUpdateDateRangeMin and filterUpdateDateRangeMax to fetch only records changed since the last sync. Payroll journal data is read through the Reports API against the report the customer sets up, since there is no GL endpoint, and employees are keyed on XRefCode rather than an integer ID. Org units are mapped to QAD cost centers first, so every journal line references an account that already exists. Dayforce rate limits are tenant-wide and shared with the customer's other integrations, so ml-connector queues requests, backs off on a rate-limit response, and follows the cursor in the Paging.Next URL until it is empty. 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 with around 1,200 employees runs QAD Adaptive ERP for production, procurement, and finance, and uses Dayforce for payroll and workforce management across three plants and a head office. Before the integration, the finance team ran a payroll journal report in Dayforce every pay period, exported it, and re-entered the labor totals into QAD by hand, then spent the first days of month-end close reconciling headcount against the labor accounts in the ledger. With QAD and Dayforce connected, each pay run's journal report flows 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 posted, and the manual re-keying step is gone.

What you can do

Post Dayforce payroll journals into QAD's general ledger after every pay run, allocated to the correct cost centers.
Pull payroll journal data through the Dayforce Reports API, since Dayforce has no GL or journal endpoint.
Keep QAD headcount aligned with Dayforce hires, terminations, and rehires using date-range change detection.
Map Dayforce org units, departments, and job codes to QAD GL dimensions so payroll lands on valid accounts.
Authenticate Dayforce with its OAuth2 password grant and QAD with its tenant-specific token, on a polling schedule with retries and a full audit trail.

Questions

Which direction does data move between QAD and Dayforce?: The main flow is Dayforce into QAD. Payroll journals and employee records move from Dayforce into QAD, while org units, departments, and job codes are aligned so payroll posts to valid dimensions. Dayforce holds no AP or invoice data and ml-connector does not write financial postings back into Dayforce.
How does ml-connector get payroll journal data out of Dayforce?: Dayforce has no GL account or payroll journal REST endpoint, so the journal data is read through the Reports API against a payroll journal report the customer configures with GL account codes and cost dimensions. That report must be set up inside Dayforce before the connector can pull it. ml-connector reads it after each pay run and maps each line to the matching QAD account and cost center.
Does the integration use webhooks or polling?: It uses polling. Dayforce sends no outbound webhooks to external API callers, and QAD cloud is also pull-only, so ml-connector reads both systems on a schedule tied to your payroll calendar. On the Dayforce side it uses the filterUpdateDateRangeMin and filterUpdateDateRangeMax parameters to fetch only records changed since the last successful sync.

Connect QAD and Dayforce

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

Get started