Microsoft Dynamics 365 Business Central and Rippling integration

What moves between them

The main flow runs from Rippling into Microsoft Dynamics 365 Business Central. Worker lifecycle changes flow first, so Business Central employee records reflect Rippling hires, terminations, and rehires, matched on a stable key such as work email or employee number. After each payroll run, ml-connector reads the run data, compensation, and Rippling accounting dimensions and posts the labor cost into Business Central as journal lines, allocated to the matching GL accounts and dimensions. Reference data such as departments and legal entities is aligned to Business Central dimensions so every journal line references an account that already exists. Rippling holds no AP invoices, vendors, or chart of accounts, so ml-connector moves people and payroll data only and does not write financial documents back into Rippling.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Rippling side it holds either an API key or an OAuth bearer token and refreshes the OAuth token before it expires, and on the Business Central side it holds a Microsoft Entra ID client credentials token and targets the company id on the configured environment name, since the environment is part of the URL. Because Rippling webhooks are limited to App Shop listings, the default mode is polling: Rippling workers and payroll runs are read on a schedule tied to your pay calendar, filtered by update time using the v2 cursor pages or the v1 offset pages, and where an App Shop webhook is available the connector can also act on Rippling lifecycle events. Because the Business Central chart of accounts and general ledger entries are read-only over the API, each Rippling labor line is written as a journal line that references an existing GL account and dimension, so Rippling departments and accounting dimensions are mapped to Business Central dimensions first. The connector checks Rippling responses for redacted compensation in __meta.redacted_fields and skips lines it cannot value rather than posting a wrong amount. It can renew the three-day Business Central subscriptions before they expire so the employee change feed never goes dark, and before each write it filters Business Central by the worker key to avoid duplicate employees. Both sides return HTTP 429 when throttled with no documented Retry-After, so ml-connector backs off with exponential delay and jitter, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A 220-person managed IT services provider runs Microsoft Dynamics 365 Business Central for finance and uses Rippling for HR, payroll, and device management across three regional offices. Before the integration, an accountant exported the payroll register from Rippling every pay period and keyed the labor totals into Business Central by hand, then spent the start of month-end close reconciling differences between office headcount and the labor accounts in the ledger. With Microsoft Dynamics 365 Business Central and Rippling connected, each pay run posts into Business Central automatically as journal lines allocated to the dimension for each office, and worker changes keep both systems aligned. Close starts with labor already reconciled and the manual re-keying step is gone.

What you can do

• •Keep Business Central employee records aligned with Rippling hires, terminations, and rehires.
• •Post Rippling payroll run labor cost into Business Central journals against the correct GL accounts and dimensions.
• •Map Rippling departments, legal entities, and accounting dimensions to Business Central dimensions so payroll lands on valid accounts.
• •Bridge Rippling OAuth or API-key auth and the Business Central Microsoft Entra ID client credentials token.
• •Poll Rippling on your pay calendar, skip redacted compensation, and replay any failed posting from the audit trail.

Questions

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

The main flow is Rippling into Business Central. Worker records and payroll labor cost move from Rippling into Business Central, while departments and accounting dimensions are aligned to Business Central dimensions so postings land on valid accounts. Rippling has no AP invoices, vendors, or chart of accounts, so ml-connector moves people and payroll data only and does not write financial documents back into Rippling.

Does the integration rely on webhooks or polling?

It uses polling by default. Rippling only delivers webhooks to App Shop listings, so ml-connector reads Rippling workers and payroll runs on a schedule tied to your pay calendar, filtered by update time. On the Business Central side, change notifications carry no payload and expire every three days, so the connector renews the subscriptions and fetches each changed record after the notification arrives.

How does ml-connector post payroll into the ledger when the Business Central GL is read-only?

The Business Central chart of accounts and general ledger entries are read-only over the API, so labor cost is not written to those resources directly. Instead ml-connector writes journal lines that reference an existing GL account and dimension, which is why Rippling departments and accounting dimensions are mapped to Business Central dimensions first. Compensation that Rippling redacts in __meta.redacted_fields is skipped rather than posted at a wrong amount.