Oracle JD Edwards and Paylocity integration

What moves between them

The main flow is Paylocity into Oracle JD Edwards. After each payroll run, ml-connector reads Paylocity payroll GL postings (derived from earnings, deductions, and withholdings) and posts the labor cost journals into JD Edwards' General Ledger (table F0911) at the correct GL accounts (F0901) and cost centers, mapped from Paylocity pay statements and employee assignments. Employee records (hires, terminations, rehires) flow from Paylocity into JD Edwards Address Book (F0101) to keep headcount aligned. Cost centers, departments, and job codes are synchronized in both directions so payroll allocations land on existing JD Edwards dimensions. Paylocity payroll data is read-only in the direction of GL postings, so ml-connector never writes pay statement or earning details back to Paylocity; it only reads and moves the aggregated GL impact. The integration uses Paylocity webhooks when available (for immediate event notification) and polls as a fallback or on a secondary schedule aligned with payroll cycles.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For JD Edwards, it exchanges the JDE username and password for a session token via the AIS Server tokenrequest endpoint, caches the token for its 30-60 minute lifetime, and monitors HTTP 444 responses to detect expiry and refresh before a request fails. For Paylocity, it refreshes the OAuth2 bearer token every 3600 seconds using the stored client_id and client_secret. The connector accepts the full AIS Server URL from the customer, since JD Edwards publishes no shared base hostname. When Paylocity sends a Payroll Processed webhook (or the connector polls on the payroll calendar), it fetches the corresponding pay statement and employee cost allocation data, maps each pay statement line to the corresponding GL account and cost center in JD Edwards, and posts the aggregated labor cost journal via an AIS Server orchestration. Cost centers must exist in JD Edwards before payroll posting, so the integration synchronizes cost center reference data from Paylocity Employees (WorkLocation, Position) into JD Edwards cost center tables on a weekly or ad-hoc schedule. Employee changes (new hire, department move, termination) are read from Paylocity Employee Change and Termination webhooks (or polled) and upserted into the JD Edwards Address Book (F0101) so HR is the authoritative record. Because JD Edwards pagination uses maxPageSize and moreRecords, the connector tracks the continuation point for multi-page queries. Every record carries a full audit trail with source identifier, timestamp, and status; failed GL postings are queued for replay when the AIS Server recovers or credentials rotate.

A real-world example

A regional staffing and recruiting firm runs Oracle JD Edwards on-premises for accounting and operational reporting, and uses Paylocity as its cloud payroll system for managing employee time sheets, benefits, and pay for 200 people across five regional offices. Before the integration, the finance team exported Paylocity payroll registers each pay period, manually entered labor totals into JD Edwards by office location (cost center), and then spent days chasing reconciliation differences between Paylocity headcount and the labor expense accounts in the JD Edwards general ledger. During rapid hiring seasons, employee moves between cost centers were delayed reaching JD Edwards, creating payroll accrual errors. With Paylocity and JD Edwards connected, each payroll run's labor costs post automatically into the correct cost center in the ledger, and employee transfers sync immediately, so the ledger always reflects current headcount and allocation. Month-end close reconciles in hours rather than days, and the manual re-entry step is entirely gone.

What you can do

• •Post Paylocity payroll GL impacts into Oracle JD Edwards General Ledger after each pay run, allocated to the correct cost centers and GL accounts.
• •Keep Oracle JD Edwards Address Book aligned with Paylocity employee hires, terminations, and departmental changes.
• •Synchronize cost centers and departments from Paylocity into Oracle JD Edwards cost center tables so payroll allocations land on valid GL dimensions.
• •Authenticate Paylocity with OAuth2 client credentials and Oracle JD Edwards with session tokens via the AIS Server REST API.
• •Ingest Paylocity webhooks for immediate event notification, with polling as a fallback, and maintain a full audit trail on every GL posting and employee record.

Questions

Which direction does data move between Oracle JD Edwards and Paylocity?

The main flow is Paylocity into Oracle JD Edwards. Payroll GL postings and employee records move from Paylocity into JD Edwards, while cost centers are synchronized in both directions. GL postings are read-only in Paylocity, so ml-connector does not write pay statement or earning details back into payroll.

Why does the integration synchronize cost centers separately from payroll posting?

Paylocity does not expose GL accounts or cost center master data as objects; cost allocation is implicit in employee assignments and pay statements. ml-connector extracts cost center associations from Paylocity employees and positions, synchronizes them into Oracle JD Edwards cost center tables, and then uses those validated dimensions when posting the GL journal from payroll. This ensures every labor cost line lands on a valid GL account and cost center.

How does the integration handle Oracle JD Edwards' session tokens and lack of outbound webhooks?

JD Edwards session tokens expire after 30-60 minutes and must be refreshed. ml-connector caches the token and monitors HTTP 444 (invalid token) responses to detect expiry; it monitors the HTTP 444 response to detect token expiry and refreshes before the next request. Because JD Edwards has no outbound webhooks, ml-connector ingests Paylocity payroll webhooks and polls JD Edwards on a schedule tied to your payroll calendar. Every transaction includes a full audit trail and can be replayed if the AIS Server is temporarily unavailable.