Microsoft Dynamics NAV and Paylocity integration

What moves between them

The main flow runs from Paylocity into Microsoft Dynamics NAV. After each payroll run, ml-connector reads Paylocity employee records, pay statements, deductions, and earnings, then posts the labor cost journals into NAV's general ledger, allocated to the correct GL accounts and cost centers. Employee additions, changes, and terminations from Paylocity sync into NAV to keep headcount and cost center assignments aligned. Cost centers and departments are validated against NAV before payroll entries are posted.

How ml-connector handles it

ml-connector stores OAuth 2.0 credentials for both systems encrypted and obtains bearer tokens on demand for each request. Paylocity webhooks notify on employee changes and payroll runs, but ml-connector also polls to catch missed webhook events and fetch full records (since Paylocity webhook payloads contain only identifiers). On the NAV side, ml-connector uses the tenant-specific base URL and accepts both online (Business Central) and on-premises deployments. NAV general ledger accounts are read-only, so ml-connector posts entries via the journal entry API rather than trying to update accounts directly. Because NAV webhooks expire after 3 days, ml-connector tracks expiry and renews before it lapses. Paylocity employee records are matched to NAV employees by employee ID, and pay statements are accumulated and rolled up to the cost center level for GL posting. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-market professional services firm runs Microsoft Dynamics NAV for accounting and project cost tracking, and uses Paylocity for payroll across three regional offices. Before the integration, the finance team exported payroll registers from Paylocity, manually allocated labor costs to the correct cost centers and GL accounts in NAV, and ran month-end reconciliation across two systems. With Paylocity and NAV connected, each payroll run posts directly to the correct GL accounts in NAV, allocated by cost center, and employee records stay in sync. Month-end close starts with labor accounts already reconciled, and manual entry is eliminated.

What you can do

• •Post Paylocity payroll GL entries into Microsoft Dynamics NAV's general ledger after each pay run, allocated to the correct cost centers and GL accounts.
• •Keep NAV employee records, cost center assignments, and headcount aligned with Paylocity hires, changes, and terminations.
• •Authenticate both systems via OAuth 2.0 client credentials and accept NAV's tenant-specific URL for online and on-premises deployments.
• •Renew NAV webhook subscriptions before the 3-day expiry, and poll Paylocity to catch missed webhook events and fetch full employee and payroll records.
• •Validate cost centers and GL accounts against NAV before posting payroll entries, with retries and a full audit trail on every record.

Questions

Which direction does data flow between Microsoft Dynamics NAV and Paylocity?

The main flow is Paylocity into NAV. Payroll GL entries, employee records, deductions, and earnings move from Paylocity into NAV, where they are posted to the general ledger and allocated to cost centers. NAV GL accounts are read-only via the API, so ml-connector does not write financial entries back into Paylocity.

How does ml-connector handle NAV's webhook 3-day expiry and Paylocity's webhook identifier-only payloads?

ml-connector tracks NAV webhook subscription expiry and renews subscriptions before they lapse to avoid missing updates. For Paylocity, webhook events carry only employee IDs and record identifiers, so ml-connector automatically fetches the full employee record, pay statement, and earnings data via API calls to ensure complete and accurate GL posting.

Does the integration work with NAV on-premises and Dynamics 365 Business Central online?

Yes. ml-connector accepts the tenant-specific URL for Business Central online and the server and instance name for on-premises deployments. On-premises requires an administrator to enable OData services and open the firewall to the OData port (7048 by default), but once enabled, the integration works identically to the cloud version.