Oracle PeopleSoft and Rippling integration

What moves between them

The primary data flow is from Rippling into Oracle PeopleSoft. After each payroll run, ml-connector reads Rippling payroll runs and employee records, then posts corresponding GL entries and compensation mappings into PeopleSoft's general ledger and employee directory. Employee hire, termination, rehire, and department change events sync from Rippling to PeopleSoft so headcount and cost allocations remain aligned. Accounting dimensions such as cost centers and legal entities from Rippling map to PeopleSoft cost center and department values. Because PeopleSoft is primarily a source for read-only inquiry operations, reference data such as departments and compensation types may be validated against PeopleSoft but rarely written back to it.

How ml-connector handles it

ml-connector stores both credential sets encrypted and uses HTTP Basic Auth or OAuth2 to authenticate against the customer's unique PeopleSoft hostname and port. On the Rippling side, it uses the provisioned API key and maintains OAuth2 token refresh when needed. Because both systems are pull-based for this integration (PeopleSoft Integration Broker webhooks are optional and customer-configured), ml-connector polls both on a schedule aligned with your payroll calendar, with date-range filters to avoid processing the same records twice. When a Rippling webhook is enabled, ml-connector can listen for employee lifecycle events in real time instead of polling. Payroll GL entries are mapped to PeopleSoft journal entries against matching GL accounts and cost centers pulled from PeopleSoft reference data. Employee compensation from Rippling is cross-referenced with PeopleSoft job codes and cost center assignments so that payroll allocations land on valid dimensions. Because PeopleSoft service operations must be explicitly activated by the customer's PeopleSoft administrator and REST endpoints vary by PeopleTools version, ml-connector validates the availability of required endpoints before attempting writes. The on-premise nature of PeopleSoft requires either firewall rules allowing outbound access from the connector or a reverse proxy to expose the endpoints securely. Every record is logged with full audit trail, timestamps, and source/target IDs so failed or missed syncs can be replayed without duplication.

A real-world example

A mid-sized multinational corporation runs Oracle PeopleSoft on-premise for global finance, procurement, and employee records, while using Rippling in the cloud for consolidated payroll across multiple countries and legal entities. Before the integration, the payroll team exported spreadsheets from Rippling, manually allocated GL amounts to the correct cost centers based on Rippling compensation mappings, and posted the entries into PeopleSoft through the general ledger subledger. Headcount mismatches between Rippling and PeopleSoft surfaced monthly during close. With Oracle PeopleSoft and Rippling connected, each payroll run's GL posting flows directly into the ledger with cost centers pre-mapped, and employee changes in Rippling automatically sync to PeopleSoft employee records. Month-end close consolidation now starts with the payroll GL and employee records already reconciled, and the manual re-entry step is eliminated.

What you can do

• •Sync Rippling payroll GL postings into Oracle PeopleSoft's general ledger, allocated to the correct cost centers and legal entities.
• •Keep PeopleSoft employee records aligned with Rippling hires, terminations, rehires, and department transfers.
• •Map Rippling compensation types and cost centers to PeopleSoft GL accounts and job codes so payroll allocations land on valid dimensions.
• •Authenticate Oracle PeopleSoft with HTTP Basic Auth or OAuth2 against the unique customer hostname, and Rippling with API key or OAuth2, handling both cloud and on-premise architectures.
• •Poll on a schedule tied to your payroll calendar, with full audit trails on every record and replay capability if a sync is interrupted.

Questions

Which direction does data move between Oracle PeopleSoft and Rippling?

The primary flow is Rippling into Oracle PeopleSoft. Payroll GL documents, employee records, and compensation mappings move from Rippling into PeopleSoft. Reference data such as GL accounts, cost centers, and job codes are pulled from PeopleSoft to validate incoming payroll records, but are rarely written back from Rippling. This one-way design reflects that PeopleSoft is the system of record for your general ledger and organizational hierarchy.

How does the integration handle PeopleSoft's on-premise architecture and tenant-specific URLs?

ml-connector accepts the full unique hostname and port for each PeopleSoft customer's instance, since each deployment is self-hosted and has its own URL. Because PeopleSoft has no webhooks for this integration, ml-connector polls the configured endpoints on a schedule tied to your payroll calendar. If your PeopleSoft environment is behind a corporate firewall, you must either whitelist the connector IP or expose the REST endpoints through a reverse proxy so the connector can reach them securely.

Does the integration work if PeopleSoft webhooks are enabled?

Yes. If your PeopleSoft administrator has enabled Integration Broker asynchronous publish/subscribe and configured outbound routing to the ml-connector endpoint, ml-connector can listen for business events in real time instead of polling. The primary integration still polls Rippling for payroll GL and employee records, so webhooks accelerate PeopleSoft-to-Rippling change notification but do not replace the schedule-based sync from Rippling into your ledger.