QuickBooks Desktop and Paylocity integration

What moves between them

The main flow runs from Paylocity into QuickBooks Desktop. Employee records, earnings, and deductions flow from Paylocity into QuickBooks as employee objects and journal entries on every payroll cycle or on a schedule you define. When Paylocity fires a Payroll Processed webhook or when the polling interval triggers, ml-connector fetches the latest employee and pay statement data from Paylocity via REST, translates it into QBXML format, and submits it through the QBWC polling cycle. Employee additions, terminations, and pay data updates land in QuickBooks without manual re-entry.

How ml-connector handles it

ml-connector stores both credential sets encrypted and handles the complete polling bridge between the two systems. On the Paylocity side, it uses OAuth2 client credentials to obtain a bearer token, refreshes the token before expiry (every 60 minutes within the 3600-second lifetime), and fetches employee and pay statement records via REST. On the QuickBooks Desktop side, ml-connector implements the SOAP Web Connector protocol: it receives poll() calls from the customer's QBWC agent, authenticates with the session-token handshake, and returns QBXML requests for QuickBooks to process. It tracks each transaction's EditSequence (QB's version counter) so concurrent edits do not create duplicates, re-queries before every modification to get the current EditSequence, and handles the sequential nature of QBWC (only one request at a time per session). Because Paylocity webhook payloads carry only identifiers, ml-connector fetches the full employee and deduction records via separate REST calls when a webhook fires. It deduplicates across polling intervals and retries failed QBXML submissions on the next QBWC cycle.

A real-world example

A mid-sized retail group with 150 employees runs QuickBooks Desktop at head office for accounting and payroll processing, and uses Paylocity Workforce Now for HCM and benefits administration across 4 locations. Before the integration, the payroll administrator exported the pay register and employee list from Paylocity each month, then manually entered employee changes and deductions into QuickBooks to update the payroll register and GL accounts. With QuickBooks Desktop and Paylocity connected, employee hires, terminations, and pay data sync automatically to QuickBooks on every payroll run, the payroll register stays current without re-keying, and the finance team has accurate headcount and labor costs at month-end close without manual workarounds.

What you can do

• •Sync Paylocity employees, earnings, and deductions into QuickBooks Desktop employee and journal entry objects via the QBWC polling cycle.
• •Authenticate Paylocity with OAuth2 bearer tokens and QuickBooks with SOAP session-token handshake.
• •Track EditSequence on every QuickBooks transaction to prevent duplicate entries from concurrent or retried writes.
• •Fetch full employee and deduction records from Paylocity when webhooks fire, since webhook payloads carry identifiers only.
• •Poll on a configurable interval (minimum 1 minute, typical 5-15 minutes) matching your payroll cycle, with deduplication and error replay on the next cycle.

Questions

Which direction does data move between QuickBooks Desktop and Paylocity?

Data flows from Paylocity into QuickBooks Desktop. Employee records, earnings, and deductions from Paylocity sync into QuickBooks as employee objects and journal entries. QuickBooks is treated as read-only for this integration, so ml-connector does not write employee or payroll changes back to Paylocity.

Why does ml-connector need to handle EditSequence and re-query before modifications?

QuickBooks tracks a version counter called EditSequence on every record to prevent concurrent edits from creating duplicates or losing updates. Before modifying an employee or journal entry in QuickBooks, ml-connector must fetch the current EditSequence value and include it in the QBXML request. If the EditSequence has changed since the last read, QuickBooks rejects the modification and ml-connector retries on the next polling cycle.

Does the integration work with Paylocity webhooks, or does it only poll?

ml-connector listens for Paylocity webhook events (New Hire, Employee Change, Termination, Payroll Processed) to trigger immediate syncs and reduces latency compared to polling alone. However, because Paylocity webhook payloads carry identifiers only, ml-connector must fetch the full employee and pay data via REST API calls. For systems without webhook registration, polling on a configurable interval remains the fallback.