SAP ECC and Rippling integration

What moves between them

The main flow is from Rippling into SAP ECC. After each payroll cycle, ml-connector reads payroll GL documents and accounting dimensions from Rippling and posts them into SAP ECC's general ledger via BAPI_ACC_DOCUMENT_POST, mapped to the matching GL accounts and cost centers. Employee records flow the same direction, either synced as customer master records in SAP ECC or as cost center assignments so headcount and labor costs are visible to finance. Accounting dimensions (departments, legal entities) are aligned from Rippling into SAP ECC cost center fields. Because Rippling is mostly read-only for GL and employees, ml-connector only writes into SAP ECC.

How ml-connector handles it

ml-connector manages four layers of connectivity. First, it stores the on-premises SAP ECC connection details and coordinates with the customer's on-premises agent (JCo or NCo) to execute RFC calls; the agent runs locally with network access to SAP ECC, while ml-connector runs in the cloud and routes calls through the agent's callback listener. Second, it authenticates to Rippling via OAuth2 or API Key, refreshing the OAuth token on 401 responses. Third, it polls Rippling's GET /platform/api/employees endpoint with updated_at filters on a schedule tied to your payroll calendar, and it polls GET /platform/api/company_activity for GL document events. Fourth, it handles SAP ECC's BAPI write semantics: every BAPI_ACC_DOCUMENT_POST call must be followed by an explicit BAPI_TRANSACTION_COMMIT, and the integration uses the REF_DOC_NO field to detect duplicate GL documents on retry so the same journal is not posted twice. Cost centers and departments are mapped first via RFC_READ_TABLE polls to BAPI_COSTCENTER_GETLIST, so every payroll journal line references a GL account and cost center that already exists in SAP ECC. Because RFC_READ_TABLE has a 512-character row width limit, wide vendor or customer records are chunked and reassembled. The on-premises agent connection is stateful and must reconnect if the network drops; ml-connector tracks agent health and surfaces connection errors to monitoring. Every record carries a full audit trail and can be replayed if a downstream BAPI call fails.

A real-world example

A mid-market manufacturing company runs SAP ECC on-premises for finance, procurement, and operations, and uses Rippling for payroll and HR across three plants and a head office. Before the integration, the finance team manually exported employee lists and GL postings from Rippling each payroll cycle, reconciled them against SAP ECC cost centers, and re-entered the labor cost journals into SAP ECC's general ledger by hand. Organizational changes in Rippling (hires, terminations, department moves) were communicated via email and took days to reflect in SAP ECC, causing discrepancies during month-end close. With SAP ECC and Rippling connected, each payroll run's GL document flows automatically into SAP ECC and is allocated to the cost center for each plant. Employee records sync automatically, so headcount in SAP ECC reflects Rippling hires and terminations within hours. Month-end close starts with the labor accounts already reconciled to Rippling, and the manual re-keying step is gone.

What you can do

• •Post Rippling payroll GL documents into SAP ECC's general ledger after every pay cycle, allocated to the correct cost centers and GL accounts.
• •Keep SAP ECC employee records and headcount aligned with Rippling hires, terminations, and organizational changes.
• •Map Rippling accounting dimensions, departments, and legal entities to SAP ECC cost centers so payroll lands on valid GL accounts.
• •Coordinate the on-premises RFC agent with cloud OAuth2 authentication to both systems, with automatic token refresh and connection health monitoring.
• •Poll on a schedule tied to your payroll calendar, with duplicate detection via REF_DOC_NO, explicit BAPI transaction commits, and a full audit trail on every record.

Questions

What do I need on the SAP ECC side to make this work?

Your SAP Basis team must activate OData services via transaction SICF if you want to use OData polling, and they must confirm that the RFC connection details (host, port, system number, client, and username) are available. An on-premises agent (running Java Connector or .NET Connector with network access to SAP ECC) must be running before ml-connector can execute RFC calls. The agent is stateful, so if the network drops, it will reconnect on the next flow run.

Which direction does data move between SAP ECC and Rippling?

The main flow is Rippling into SAP ECC. Payroll GL documents, employee records, and accounting dimensions move from Rippling into SAP ECC. SAP ECC is mostly read for GL accounts and cost centers, so ml-connector does not write financial entries back to Rippling. Configuration and dimension tables (cost centers, GL accounts) are read from SAP ECC to ensure every payroll posting lands on a valid account.

How does ml-connector prevent duplicate GL documents in SAP ECC?

ml-connector uses SAP ECC's REF_DOC_NO field to track which Rippling GL documents have already been posted. On retry, if the same Rippling document is processed again, ml-connector checks whether a SAP ECC GL document with the same REF_DOC_NO already exists, skips the duplicate write, and records the replay in the audit log. Every BAPI_ACC_DOCUMENT_POST call is followed by an explicit BAPI_TRANSACTION_COMMIT to lock the document.