Acumatica and Rippling integration

What moves between them

The main flow runs from Rippling into Acumatica. After each pay period, ml-connector reads Rippling workers, their compensation, and the accounting dimensions assigned to them, and posts the labor cost into Acumatica as a balanced journal transaction, with each amount mapped to the matching Acumatica GL account and subaccount by Rippling dimension. Worker records flow the same direction so Acumatica headcount reflects Rippling hires, terminations, and rehires. GL accounts and cost-allocation dimensions in Acumatica are aligned first so every journal line references an account that already exists. Rippling has no general ledger of its own and is treated as a read-only payroll source, so ml-connector never writes financial entries back into Rippling.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Rippling side it uses a v2 REST bearer token, either from the App Shop authorization-code flow (where it exchanges the code inside the 300-second window and refreshes before expiry) or from a direct API key, and it expands worker, compensation, and department in one call to avoid N+1 reads. On the Acumatica side it accepts the full tenant URL and the exact endpoint version per customer, obtains an OpenID Connect token, and wraps every field value in the required value object. Because Rippling webhooks are App Shop only, the default is a scheduled poll keyed to your payroll calendar; where an App Shop listing exists, a verified HMAC-signed employee event can trigger the sync, and company_activity polling backfills anything missed. Rippling can return compensation in redacted_fields when scopes do not cover it, so ml-connector checks for redaction and surfaces a clear error rather than posting a short journal. Accounting dimensions and departments are mapped to Acumatica GL accounts and subaccounts first, so each journal line lands on a valid account. Acumatica has no idempotency-key header, so before posting it checks for an existing journal by the pay-period reference to avoid a duplicate, and it backs off on the 429 returned when either side hits a rate limit. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized technology company of about 250 employees runs Acumatica Cloud ERP for finance and project accounting and uses Rippling for payroll, HR, and IT across two legal entities. Before the integration, an accountant exported the payroll register from Rippling every pay period and hand-entered the wage and tax totals into Acumatica as a manual journal, splitting them across cost centers by reading a spreadsheet of department codes, then spent the start of month-end close chasing differences between HR headcount and the labor accounts in the ledger. With Acumatica and Rippling connected, each pay period posts into Acumatica automatically as a balanced journal allocated by accounting dimension, and worker changes keep the two systems aligned. Month-end close starts with the labor accounts already reconciled, and the manual re-keying step is gone.

What you can do

• •Post each Rippling pay period into Acumatica as a balanced journal transaction across the correct GL accounts.
• •Map Rippling accounting dimensions and departments to Acumatica GL accounts and subaccounts so labor cost lands where it belongs.
• •Keep Acumatica employee records aligned with Rippling hires, terminations, and rehires.
• •Authenticate Rippling with an App Shop OAuth bearer token or API key, and Acumatica with its OpenID Connect token and matching endpoint version.
• •Poll on a schedule tied to your payroll calendar, with pay-period dedup, retries, and a full audit trail on every record.

Questions

Which direction does data move between Acumatica and Rippling?

The main flow is Rippling into Acumatica. Worker compensation becomes balanced journal transactions in Acumatica allocated by accounting dimension, and hires, terminations, and rehires move from Rippling into Acumatica employee records. Rippling has no general ledger, vendors, or invoices of its own, so ml-connector treats it as a read-only payroll source and never writes financial entries back into Rippling.

Does the integration use Rippling webhooks or polling?

It depends on how Rippling is connected. Webhooks for employee lifecycle events are restricted to App Shop apps and signed with HMAC, so if a listing exists ml-connector verifies the signature and uses the event to trigger a sync. Direct API-key integrations get no webhooks, so the default is a scheduled poll keyed to your payroll calendar, with the company_activity endpoint used to backfill anything missed.

What happens if Rippling returns compensation as a redacted field?

Rippling returns compensation and other scoped fields in redacted_fields rather than as an error when the granted entitlements do not cover them. ml-connector checks for redaction before it posts and surfaces a clear error instead of writing a journal that is short, so a missing scope is fixed at setup rather than producing an out-of-balance ledger. Only the worker id, personal email, and role state are guaranteed on every record.