Microsoft Dynamics 365 Business Central and Paychex integration

What moves between them

The main flow runs from Paychex into Microsoft Dynamics 365 Business Central. ml-connector reads Paychex workers and keeps Business Central employee records aligned with Paychex hires, terminations, and demographic changes. After each processed payroll, it reads the Paychex checks and posts the labor cost into Business Central general ledger journal lines, mapped to the matching GL accounts and dimension values. Reference data such as Paychex organizations, locations, and cost centers is aligned to Business Central dimensions so every payroll line lands on a valid account. Paychex compensation and tax elections are owned in payroll, so ml-connector reads them and does not write financial postings back into Paychex.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two separate OAuth 2.0 client credentials flows: one against Microsoft Entra ID for the Business Central scope, and one against the Paychex token endpoint. Neither side issues a refresh token under client credentials, so it re-acquires each token before expiry and retries once on a 401. On the Business Central side it stores the environment name and company id per customer to build the tenant URL, and it writes employee changes and payroll journal lines through server actions rather than touching the chart of accounts, which is read-only over the API. Because Paychex pages with offset and limit and can skip or duplicate rows if the worker set changes mid-crawl, it paginates sequentially at the recommended limit of 100 and carries the page ETag to hold collection consistency. Paychex worker webhooks and Business Central subscriptions are notification-only, so each event triggers a follow-up GET to fetch the current record. Business Central subscriptions expire after three days and are renewed on a cron before expiry, and Paychex organizations and cost centers are mapped to Business Central dimension values first so every journal line references an account and dimension that already exists. Paychex returns HTTP 429 without published limits and Business Central throttles at its own per-environment ceiling, so calls back off with exponential jitter, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A regional facilities services firm with about 400 hourly staff across several sites runs Microsoft Dynamics 365 Business Central for finance and Paychex Flex for payroll. Before the integration, HR added and terminated workers in Paychex while a clerk separately maintained the employee list in Business Central, and after each pay run the finance team exported the payroll register and keyed the labor totals into the general ledger by site. Headcount drifted between the two systems and month-end close stalled while the team reconciled labor accounts by hand. With the two systems connected, Paychex hires and terminations keep the Business Central employee records current, and each processed payroll posts labor cost into the ledger allocated to the right site dimension, so close starts with labor already reconciled.

What you can do

• •Keep Microsoft Dynamics 365 Business Central employee records aligned with Paychex hires, terminations, and demographic changes.
• •Post labor cost from each processed Paychex payroll into Business Central general ledger journals, allocated to the right accounts.
• •Map Paychex organizations, locations, and cost centers to Business Central dimension values so payroll lands on valid accounts.
• •Run separate Microsoft Entra ID and Paychex OAuth token flows and re-acquire each token before it expires.
• •Paginate Paychex workers sequentially with ETag consistency, with retries and a full audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and Paychex?

The main flow is Paychex into Business Central. Worker records and payroll labor cost move from Paychex into Business Central, while cost center and organization mappings are aligned to Business Central dimensions. Paychex owns compensation and tax data, so ml-connector reads it and does not write financial postings back into Paychex.

How does ml-connector handle authentication for both systems?

It runs two separate OAuth 2.0 client credentials flows, one against Microsoft Entra ID for the Business Central API scope and one against the Paychex token endpoint. Neither side issues a refresh token, so ml-connector re-acquires each token before expiry and retries once on a 401. Both credential sets are stored encrypted.

Does the integration rely on webhooks or polling?

Both Paychex worker events and Business Central subscriptions are notification-only and carry no data, so each event triggers a follow-up GET to fetch the current record. Business Central subscriptions expire after three days and are renewed on a schedule, and a scheduled poll tied to your pay calendar backfills anything a webhook misses.