IFS Cloud and Rippling integration

What moves between them

The main flow runs from Rippling into IFS Cloud. After each payroll run, ml-connector reads Rippling payroll run data and employee compensation records and posts corresponding GL entries into IFS Cloud's journal entries (VoucherSet), mapped to the matching GL accounts and accounting dimensions. Employee records flow from Rippling to IFS Cloud so headcount and organizational structure stay aligned. Accounting dimensions such as cost centers and departments are synced in both directions to ensure payroll-related GL postings land on valid IFS Cloud dimensions. GL postings in Rippling are read-only from the API perspective, so ml-connector never writes financial entries back into payroll.

How ml-connector handles it

ml-connector stores both credential sets encrypted and handles the different OAuth2 patterns: IFS Cloud client credentials on the IFS side and Rippling API key bearer authentication on the Rippling side. On IFS Cloud, it constructs the full tenant-specific OData URL per customer (https://<tenant>.ifs.cloud) and caches the OAuth2 token for approximately 60 minutes, refreshing on 401. When posting GL entries to IFS Cloud, ml-connector reads the target VoucherSet record first to capture its OData ETag, then submits the PATCH or POST with the ETag header to enforce optimistic concurrency. On Rippling, it polls the employees endpoint with updated_at filters to detect changes since the last sync, and retrieves payroll run summaries on a schedule tied to your pay calendar. IFS Cloud enforces a 5000-element page-size limit and a rate limit of approximately 1000 requests per minute per tenant, so ml-connector pages results and backs off on 429 with exponential jitter. Accounting dimensions must be matched and validated in both directions before GL postings are created. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized manufacturing company runs IFS Cloud for production, procurement, and finance across two plants, and uses Rippling for payroll and HR. Before the integration, the finance team collected payroll cost allocations from Rippling weekly and manually coded them into IFS Cloud journal entries, matching them to plant-specific GL accounts and cost centers. This re-keying step delayed month-end close and created reconciliation issues when plant headcount in HR didn't match the labor accounts. With IFS Cloud and Rippling connected, each payroll summary automatically flows into IFS Cloud as properly coded GL entries, and employee changes in Rippling are reflected in IFS Cloud's headcount. The month-end close process now begins with labor accounts already reconciled, and manual coding is gone.

What you can do

• •Post Rippling payroll GL data into IFS Cloud journal entries (VoucherSet), allocated to the correct GL accounts and cost centers.
• •Keep IFS Cloud headcount and organizational structure aligned with Rippling employee records, hires, terminations, and rehires.
• •Sync accounting dimensions and cost centers between Rippling and IFS Cloud so payroll-related GL postings land on valid accounts.
• •Authenticate both systems using their respective OAuth2 and API key patterns, with token refresh and rate-limit backoff.
• •Poll Rippling and IFS Cloud on a schedule tied to your payroll calendar, with retries, concurrency control via ETag, and a full audit trail.

Questions

Which direction does data move between IFS Cloud and Rippling?

The main flow is Rippling into IFS Cloud. Payroll GL data and employee records move from Rippling into IFS Cloud's journal entries and headcount, while accounting dimensions and cost centers are aligned in both directions. GL postings in Rippling are read-only from the API, so ml-connector does not write financial entries back into payroll.

How does ml-connector handle IFS Cloud's tenant-specific URL and OData concurrency requirements?

ml-connector accepts the full IFS Cloud tenant URL per customer (https://<tenant>.ifs.cloud) and stores it in the connection configuration. When posting or updating GL entries, it reads the target record first to capture its OData ETag, then submits mutations with that ETag header to enforce optimistic concurrency and prevent conflicts.

What happens when Rippling webhooks are not available for a direct API integration?

Direct API-key integrations on Rippling do not receive webhook delivery, so ml-connector polls the employees endpoint with updated_at filters and the company activity event log on a schedule tied to your payroll calendar. IFS Cloud also has no webhook API, so polling is the standard pattern for both systems.