Microsoft Dynamics GP and Rippling integration

What moves between them

The primary flow runs from Rippling into Dynamics GP. After each payroll run, ml-connector reads Rippling's employees, departments, and accounting dimensions, then posts labor cost allocations and compensation GL journal entries into Dynamics GP's general ledger, mapped to the matching GL accounts and cost centers. Departments and cost centers are aligned bi-directionally so Rippling payroll allocations land on valid Dynamics GP GL dimensions. Rippling employee lifecycle events (hires, terminations, department changes) keep Dynamics GP headcount and organizational structure in sync. Dynamics GP payables and vendor records are read-only in this direction; they may optionally flow to Rippling for visibility but do not update back.

How ml-connector handles it

ml-connector stores both credential sets encrypted: the Windows domain account required by Dynamics GP and the Rippling API key. On the Dynamics GP side, ml-connector presents the Windows credentials via NTLM/Kerberos negotiation against the customer's on-premises SBA endpoint (the customer must expose the SBA through the firewall or via a local agent with a valid SSL certificate). It accepts the full GP server URL, tenant name, and company database name per customer, since GP publishes no shared base URL. Because Dynamics GP is pull-only, ml-connector polls both Rippling and Dynamics GP on a schedule tied to the payroll calendar. For Rippling, it uses the updated_at filter on the /employees endpoint and tracks the latest company activity event to avoid re-polling. It maps Rippling departments and accounting dimensions to Dynamics GP GL dimensions first, so every labor cost journal line references a GL account and cost center that already exists. Payroll GL postings are wrapped in Dynamics GP's required top-level Payload key format and posted to unposted (Work) journal entries only; posted historical records are left read-only. ml-connector retries failed API calls against both systems and tracks the full audit trail, allowing any record to be replayed if a downstream validation fails.

A real-world example

A mid-sized services company runs Dynamics GP on premises for accounting and payables, and uses Rippling for payroll across three offices and remote workers. Before the integration, the accounting team received payroll registers from Rippling each pay period and spent hours manually allocating labor costs to Dynamics GP GL accounts and cost centers by office, then re-entered the totals into GL journals by hand. With Rippling and Dynamics GP connected, each payroll run triggers ml-connector to read the department and compensation data from Rippling, validate it against Dynamics GP's cost centers and GL accounts, and post the labor cost journals automatically, allocated to each office. Month-end close starts with payroll GL entries already in place and cost allocation no longer a manual bottleneck.

What you can do

• •Post Rippling payroll GL journals into Dynamics GP general ledger after each pay run, allocated to the correct cost centers and GL accounts.
• •Keep Dynamics GP organizational structure and headcount aligned with Rippling employee lifecycle (hires, terminations, department changes, rehires).
• •Map Rippling departments and accounting dimensions to Dynamics GP GL dimensions so payroll and cost allocations land on valid accounts.
• •Authenticate Rippling with API key bearer tokens and Dynamics GP with Windows domain credentials via NTLM or Kerberos negotiation.
• •Poll on a schedule tied to your payroll calendar with full retries, idempotency checks, and audit trail on every record.

Questions

How does ml-connector handle Dynamics GP being on premises and Rippling being cloud?

ml-connector accepts the full URL and credentials for the customer's on-premises Dynamics GP server. The customer must expose the Service Based Architecture endpoint through the firewall or via a local agent with a valid SSL certificate. ml-connector presents the Windows domain account credentials via NTLM or Kerberos negotiation on every call. Rippling is accessed via its cloud REST API with the provided API key.

Which direction does data move between Dynamics GP and Rippling?

The main flow is Rippling into Dynamics GP. Payroll GL journals, employee records, departments, and accounting dimensions move from Rippling into Dynamics GP after each payroll run. Dynamics GP vendors and payables records are read-only from the integration; they may optionally be read for visibility but do not update back to Rippling. Cost centers and departments are aligned in both directions to ensure payroll allocations land on valid GL accounts.

What happens if Rippling employee or department changes occur mid-cycle?

ml-connector polls Rippling on a schedule tied to your payroll calendar, using the updated_at timestamp and company activity log to detect changes. When employee terminations, rehires, or department transfers are found, they are posted into Dynamics GP's GL and organizational structure in the next scheduled poll. This keeps the two systems aligned through the pay cycle.