SAP S/4HANA and Rippling integration

What moves between them

The main flow is from Rippling into SAP S/4HANA. Employee records and compensation data from Rippling are synced into SAP as business partners and cost center assignments, ensuring headcount and labor cost allocations stay current. After each payroll run, ml-connector reads Rippling compensation and time data, creates GL entries in SAP S/4HANA's journal, and posts them to the corresponding cost centers. Accounting dimensions and departments are aligned in both directions so payroll-driven GL entries land on valid SAP GL accounts.

How ml-connector handles it

ml-connector stores OAuth credentials for both systems encrypted and refreshes tokens before expiry on each request. SAP S/4HANA requires the Communication Arrangement OAuth details to be copied per tenant; ml-connector does not construct the token endpoint URL manually. Rippling employee records are polled using the updated_at filter, and accounting dimensions are read to validate cost center mappings before posting GL entries into SAP. Since neither system provides webhooks for direct API integrations, ml-connector polls both on a schedule tied to your payroll calendar. GL accounts and cost centers in SAP are read-only, so ml-connector maps Rippling data to existing SAP dimensions rather than creating new accounts. Every journal entry carry a full audit trail and includes the Rippling employee ID and payroll run ID for traceability.

A real-world example

A mid-sized manufacturing company runs SAP S/4HANA for finance and procurement across three plants, and uses Rippling for payroll and HR. Before the integration, the finance team manually exported employee headcount and payroll GL summaries from Rippling every pay period and posted labor cost journals into SAP S/4HANA by hand, then spent time chasing discrepancies between HR and GL during month-end close. With SAP S/4HANA and Rippling connected, each payroll run's GL entries flow automatically into SAP, allocated to the cost center for each plant, and employee changes keep SAP business partner records aligned with current Rippling headcount. Month-end close starts with the labor accounts already complete and reconciled.

What you can do

• •Sync Rippling employee records into SAP S/4HANA business partners, keeping headcount and department assignments current.
• •Post payroll-driven GL entries from Rippling into SAP S/4HANA on a schedule tied to your payroll cycle.
• •Map Rippling accounting dimensions and compensation data to SAP cost centers and GL accounts.
• •Manage OAuth 2.0 token refresh on both sides and handle the OData and REST API differences transparently.
• •Maintain a complete audit trail on every employee record and GL entry, linked back to the Rippling payroll run.

Questions

Which direction does data move between SAP S/4HANA and Rippling?

The main flow is Rippling into SAP S/4HANA. Employee records, department assignments, and compensation data move from Rippling into SAP as business partners and cost center allocations. Payroll GL entries are created in SAP based on Rippling payroll runs. GL accounts and cost centers in SAP are read-only, so ml-connector aligns Rippling data to existing SAP dimensions rather than creating new accounts.

How does the integration handle OAuth token refresh on both sides?

ml-connector stores the OAuth credentials for both SAP S/4HANA and Rippling encrypted and refreshes tokens before expiry on each API call. For SAP, the token endpoint URL must be copied from the Communication Arrangement OAuth details by an SAP admin; ml-connector does not construct it manually. Tokens are typically short-lived (12 hours for SAP), so ml-connector caches and refreshes proactively.

Since both systems are pull-only, how does the integration stay current?

ml-connector polls both Rippling and SAP S/4HANA on a schedule you control, aligned to your payroll calendar. Rippling employees are queried using the updated_at filter to fetch only changed records, and the activity event log is checked for department and compensation changes. SAP GL account line items are read using delta tokens or LastChangeDateTime filters to minimize API calls and stay within rate limits.