Microsoft Dynamics GP and Paylocity integration

What moves between them

The main flow is from Paylocity into Microsoft Dynamics GP. After each payroll run, ml-connector reads Paylocity's employee records and pay documents, transforms them to match Dynamics GP GL account and cost center dimensions, and posts them as GL journal entries in unposted Work status. Employee changes (hires, terminations, rehires) sync from Paylocity to keep headcount and organizational mappings in Dynamics GP in sync. Cost centers, locations, and departments align in both directions so payroll allocations land on valid GL dimensions. GL documents are read-only in Paylocity, so ml-connector never writes financial entries back into payroll.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Paylocity it uses OAuth2 client credentials to obtain a Bearer token valid for 3600 seconds and refreshes it before expiry. For Dynamics GP it uses a dedicated Windows domain account that the customer provides and configures in Active Directory, and presents that account to Dynamics GP's SBA REST endpoint or SOAP Web Services. Because Dynamics GP does not support webhooks, ml-connector polls both systems on a schedule tied to your payroll calendar. Paylocity webhook events supplement polling for real-time notifications of payroll completion and employee changes. ml-connector filters Dynamics GP requests using ModifiedDate to fetch only changed records, respects Dynamics GP's posted vs unposted constraint by posting payroll GL entries only in unposted Work status, and validates that GL accounts and cost centers exist before posting. Payroll GL documents are mapped line-by-line to Dynamics GP accounts and cost centers based on employee location and department. Retries use exponential backoff when either API returns errors. Every record carries a full audit trail and can be replayed if a call fails.

A real-world example

A mid-sized manufacturer with multiple locations runs Microsoft Dynamics GP on-premises for its general ledger and purchasing, and uses Paylocity for payroll across manufacturing plants and an office. Before the integration, the accounting team received payroll registers from Paylocity each pay period and manually entered labor cost totals into Dynamics GP by location and department, then spent the first week of month-end close tracking down differences between the GL labor accounts and the actual pay run totals. With Paylocity and Dynamics GP connected, each payroll run's GL documents flow automatically into unposted Work status in Dynamics GP, allocated by location and department cost center, ready for review and posting. Employee hires and terminations sync automatically so headcount in Dynamics GP stays in step with Paylocity. Month-end close now starts with labor accounts pre-populated, differences are rare, and the manual re-keying step is eliminated.

What you can do

• •Post Paylocity payroll GL documents into Microsoft Dynamics GP's general ledger after each pay run, allocated to the correct cost center and location.
• •Keep Dynamics GP employee records and headcount in sync with Paylocity hires, terminations, and rehires.
• •Map Paylocity cost centers, locations, and departments to Dynamics GP GL accounts and dimensions so payroll lands on valid accounts.
• •Authenticate Paylocity with OAuth2 client credentials and Dynamics GP with Windows domain credentials, polling both systems on a payroll-calendar schedule.
• •Audit every record, validate GL accounts and cost centers before posting, and replay failed payroll GL documents without re-keying.

Questions

Which direction does data move between Dynamics GP and Paylocity?

The main flow is Paylocity into Dynamics GP. Payroll GL documents, employee records, and pay data move from Paylocity into Dynamics GP, while cost centers and departments align in both directions. GL documents are read-only in Paylocity, so ml-connector does not write financial entries back into payroll.

How does the integration handle Dynamics GP's Windows authentication and on-premises deployment?

ml-connector requires a dedicated Windows domain account created by the customer in their Active Directory, with appropriate security roles in Dynamics GP. ml-connector presents that account to Dynamics GP's SBA REST or SOAP endpoint (both must be accessible through the customer's firewall). The customer provides the full endpoint URL and the domain account credentials, and ml-connector stores them encrypted.

Why does ml-connector poll Dynamics GP instead of waiting for webhooks?

Dynamics GP does not support webhooks or push notifications. ml-connector polls both systems on a schedule tied to your payroll calendar, filtering Dynamics GP requests with ModifiedDate to fetch only changed records. Paylocity webhooks supplement polling for real-time notifications of payroll completion and employee changes when they are enabled.