Microsoft Dynamics GP and ADP integration

What moves between them

The flow runs from ADP into Microsoft Dynamics GP. After each payroll run, ml-connector reads ADP's general ledger documents and posts the labor cost journals into the GP general ledger as unposted GL transactions, with each distribution line mapped to the matching GP account and cost center. Reference data such as cost centers and departments is aligned so payroll allocations land on valid GP dimensions. ADP general ledger documents are read-only and GP exposes no employee or worker object, so ml-connector reads workforce data from ADP and never writes financial entries or payroll changes back into ADP.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For ADP it presents the client certificate at the TLS layer on every request and refreshes the OAuth2 bearer token when a call returns 401. For Microsoft Dynamics GP it authenticates with the customer's Windows domain account and accepts the SBA base URL, tenant, and GP company database name per customer, remembering that the company name is the SQL Server database name and not the display name. Because GP has no webhooks, it polls ADP general ledger documents on a schedule tied to your payroll calendar, and it can also receive ADP event notifications where enabled. Cost centers and departments are mapped first, so every journal line references a GP account that already exists. GP GL transactions are created as unposted batches, since posted records are read-only through the API, and the batch is left for review. ADP rate limits return HTTP 429 per gateway node and GP can be slowed by aggressive polling, so ml-connector limits concurrency and backs off, and it tracks the ADP certificate expiry so a renewal does not turn into an outage. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized manufacturer with about 300 employees runs Microsoft Dynamics GP on a server at its head office for financials and the general ledger, and uses ADP Workforce Now for payroll across three sites. Before the integration, the accounting team exported the payroll register from ADP each pay period and hand-keyed the gross wages, employer taxes, and deductions into GP, then reconciled the labor accounts during month-end close. With Dynamics GP and ADP connected, each payroll run's GL document flows into GP automatically as an unposted batch, split by department and cost center, ready for an accountant to review and post. The manual re-keying is gone and close starts from labor accounts that already tie out.

What you can do

• •Post ADP payroll general ledger documents into Microsoft Dynamics GP as unposted GL transactions after every pay run.
• •Map ADP cost centers and departments to GP accounts and dimensions so payroll lands on valid accounts.
• •Authenticate ADP with OAuth2 and the required mutual TLS certificate, and GP with its Windows domain account.
• •Poll on a schedule tied to your payroll calendar, since Dynamics GP has no webhooks, with retries on every call.
• •Keep a full audit trail on every record and replay any posting that fails downstream.

Questions

Which direction does data move between Microsoft Dynamics GP and ADP?

The flow is ADP into GP. The general ledger documents ADP generates after each payroll run move into the GP general ledger as labor cost journals, and cost centers and departments are aligned so the lines map to valid accounts. ADP GL documents are read-only and GP exposes no worker object, so ml-connector does not write financial entries or payroll changes back into ADP.

How does ml-connector reach an on-premises Dynamics GP server?

Microsoft Dynamics GP has no cloud endpoint, so the customer exposes the SBA REST or SOAP service through their firewall over HTTPS, or runs a local agent inside the network. ml-connector authenticates with a dedicated Windows domain account mapped to a GP user, and on GP 2015 and later it targets the SBA API using the GP company database name rather than the display name.

Does ADP's mutual TLS certificate need special setup?

Yes. ADP requires a client certificate at the TLS layer on every call in addition to OAuth2 client credentials, and the connection fails without it. ml-connector stores the certificate encrypted, presents it on each request, and tracks its expiry so a renewal is handled before it can cause an outage.