Oracle PeopleSoft and UKG integration

What moves between them

The main flow is from UKG into Oracle PeopleSoft. After each payroll run, ml-connector reads UKG's payroll GL export and GL account segment data from the third-party pay endpoint, maps each payroll line to the matching GL account and cost center in PeopleSoft, and posts payroll journal entries into PeopleSoft using SOAP Component Interface services. Employee records including hires, terminations, and role changes flow from UKG into PeopleSoft so the HR master file stays current. Cost centers and departments are synced bidirectionally to ensure payroll allocations land on existing dimensions. Reference data such as pay groups and direct deposit settings are also synchronized. UKG GL data is read-only, 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 distinct authentication models on each side. For UKG, it refreshes the OAuth token every hour (tokens expire after 1 hour) and implements the two-pass employee fetch pattern: first call to get employee IDs and UUIDs, then per-employee calls for full profile data. Because UKG webhook retention is only 14 days and PeopleSoft has no webhooks, ml-connector polls both systems on a schedule tied to your payroll calendar, using date-range filters to manage PeopleSoft's lack of standard pagination. For PeopleSoft, it accepts the customer's unique hostname, port, and node name configuration and routes all service operation calls to the correct instance URL. Payroll journals are posted to PeopleSoft via SOAP Component Interface calls with the GL account and cost center already validated to exist, so failed writes are isolated to unmapped dimensions rather than invalid accounts. UKG GL data includes GL account segments and debit/credit amounts that map directly to PeopleSoft journal line fields. ml-connector tracks processed payroll IDs to prevent duplicate postings, since PeopleSoft has no idempotency keys at the API level, and maintains a full audit trail so any failed journal can be replayed once the underlying dimension is corrected.

A real-world example

A mid-sized professional services firm runs Oracle PeopleSoft for its general ledger, accounts payable, and HR records across a main office and three regional branches. Payroll is processed by UKG for the entire company. Before the integration, the accounting team ran a monthly export from UKG after payroll was finalized, manually mapped each payroll line to the correct cost center and GL account, and typed journal entries into PeopleSoft, a process that took 3 to 4 hours and often produced reconciliation errors when employees moved between cost centers. With Oracle PeopleSoft and UKG connected, each month's payroll GL data flows directly into PeopleSoft's general ledger pre-mapped to cost centers and divisions, and employee changes in UKG automatically update the HR master in PeopleSoft the next day. The manual mapping step is gone, month-end payroll close starts with the GL already correct, and the accounting team spends that time on analysis instead of data re-entry.

What you can do

• •Post UKG payroll GL journals into Oracle PeopleSoft's general ledger after each pay run, allocated to the correct cost centers and departments.
• •Sync employee records including hires, terminations, and role changes from UKG into PeopleSoft so the HR master stays current.
• •Map UKG pay groups, cost centers, and GL account segments to PeopleSoft GL accounts and dimensions so payroll lands on valid accounts.
• •Handle OAuth token refresh on UKG's 1-hour expiry, two-pass employee fetches, and PeopleSoft's unique hostname and node configuration per customer.
• •Poll on a schedule tied to your payroll calendar with date-range filtering, and track processed payroll IDs to prevent duplicate postings.

Questions

How does ml-connector handle the GL data from UKG when UKG has no native GL accounts endpoint?

UKG exposes GL data through the third-party pay API endpoint with GL account segments and debit/credit amounts. ml-connector reads these GL segments, maps them to the matching GL accounts and cost centers already configured in Oracle PeopleSoft, and writes the journal lines via SOAP Component Interface calls. This way the GL structure is defined once in PeopleSoft and UKG payroll data is routed to existing accounts without replication.

Why does ml-connector use polling instead of webhooks for both systems?

UKG supports webhooks but with only 14-day event retention, so ml-connector uses secondary polling as a fallback for zero-tolerance integrations. Oracle PeopleSoft has no webhooks at all, so polling is required there. ml-connector polls both systems on a schedule tied to your payroll calendar using date-range filters, which is reliable and handles both systems' constraints uniformly.

What happens when an employee ID or cost center does not exist in Oracle PeopleSoft?

ml-connector validates cost centers and GL accounts against PeopleSoft before posting payroll journals. If a cost center or dimension does not exist, the journal posting fails on that line and the record is flagged in the audit trail with the validation error so the dimension can be added to PeopleSoft and the journal replayed. This isolation prevents invalid entries from posting while making the fix straightforward.