PeopleSoft HCM 9.2 — Technical Reference

PeopleSoft Payroll Compliance Controls Reference

A technical reference for the compliance controls embedded in PeopleSoft HCM v9.2 Payroll for North America. Covers effective-date architecture, PII table-layer controls, retro pay triggers, year-end balance integrity, and audit trail configuration — the controls that make payroll outputs audit-defensible.

Platform

PeopleSoft HCM 9.2

Module

Payroll for North America (PNA)

Scope

Audit defensibility controls

Technical reference only. PeopleSoft configuration varies by implementation. Validate all controls against your specific configuration and PeopleTools version before relying on them.

Official sources

Use IRS and DOL sources when validating payroll controls in PeopleSoft.

📅

Critical Control

Effective Date Architecture — The Foundation of Audit Defensibility

Critical›

The most common PeopleSoft audit finding: updating existing effective-dated rows instead of inserting new ones. When a payroll administrator corrects an error by overwriting an existing effective-dated row, the history is destroyed. The IRS cannot reconstruct what the data was before the change. This creates an unresolvable audit gap.

The Effective Date Rule

Every change to payroll-affecting configuration (earnings codes, deduction codes, tax tables, pay rates, benefit setups) must be entered as a new effective-dated row — never by updating an existing row's data fields.

Correct approach	Incorrect approach	Audit consequence
Insert a new effective-dated row with the new value and effective date	Edit the data fields of an existing effective-dated row	Prior value is lost; cannot reconstruct history; IRS cannot verify retroactivity
Correct effective date = date the change should take effect (may be past date)	Always use today's date regardless of when the change should be effective	Retro pay engine fires incorrectly; balance discrepancies
Correction rows: insert a row correcting the prior row's effective date data	Delete the incorrect row and re-enter	Deletion removes history; audit trail shows gap

Key Effective-Dated Tables in PNA

Table / Record	What it drives	Change frequency
`PS_JOB`	Employment status, pay rate, department, FLSA status	Each employment action
`PS_COMPENSATION`	Compensation rate components	Each pay rate change
`PS_EARNINGS_TBL`	Earnings code configuration	Annual or as needed
`PS_DEDUCTION_TBL`	Deduction code configuration	Annual or as needed
`PS_EMPLOYEE_TAX_DATA`	Federal/state tax withholding elections	Each W-4 change
`PS_PAY_CAL_BAL_ID`	Pay calendar setup	Annual
`PS_GARN_ORDER`	Garnishment order setup	Each new order or modification

🔒

PII Controls

PII Table-Layer Controls in PeopleSoft HCM 9.2

Security Critical›

Granting direct SELECT on PS_PERSONAL_DATA to end users is a segregation-of-duties failure. PS_PERSONAL_DATA contains SSN (NATIONAL_ID), date of birth, address, and other PII. Row-level security and role-based access must be configured to limit access to only the PII necessary for each role's function.

Key PII Tables and Access Controls

Table / Record	PII content	Access control requirement
`PS_PERSONAL_DATA`	SSN (NATIONAL_ID), DOB, address, name	Row-level security by department; role-based read restriction; no direct SQL access for non-admin users
`PS_EMPLOYEE_TAX_DATA`	Federal/state filing status, withholding amounts	Payroll role access only; employee self-service view with masking
`PS_DIR_DEP_DISTRIB`	Bank account numbers, routing numbers	Highly restricted; change requires dual authorization; bank account numbers masked in UI
`PS_GARN_ORDER`	Court order numbers, case IDs, creditor info	Payroll and legal access only; strict change control
`PS_CHECK_YTD`	Year-to-date wage and tax totals by employee	Payroll access; masking in non-production environments

Non-Production Environment PII Masking

SSN and bank account data must be masked or replaced with synthetic data in all non-production PeopleSoft environments (Development, Test, QA, Training). Failure to mask PII in non-production environments is a reportable control deficiency in SOC 2 audits and most state privacy law frameworks.

BI Publisher Reports Containing SSN

BI Publisher reports (W-2, pay stubs) that display SSN must use the PeopleCode masking function to display only the last 4 digits in end-user views. Do not hardcode SQL that bypasses the masking function. Any BIP template that exposes the full 9-digit SSN must be reviewed and restricted to the minimum necessary roles.

⏪

Retro Pay Controls

Retro Pay Trigger Analysis — Preventing Unintended Retroactive Calculations

›

PeopleSoft's retro pay engine automatically recalculates prior pay periods when it detects changes to effective-dated records with effective dates in the past. Unintended retro pay triggers are one of the most common sources of payroll calculation errors — and one of the hardest to explain to an IRS examiner.

What Triggers the Retro Pay Engine

A Job Data row inserted with an effective date prior to a confirmed payroll period
A Compensation change row with a retroactive effective date
A correction to an earnings or deduction code with a retroactive effective date
A benefit enrollment change with a retroactive effective date

Retro Pay Configuration Controls

Control	PeopleSoft setup	Purpose
Retro Pay Trigger Definition	Set Up HCM > Product Related > Payroll for NA > Retro Pay	Defines which field changes on which records trigger retro calculation
Retro pay run type	On-demand vs. auto-triggered	Require manual review of retro amounts before payment; avoid auto-payment of unreviewed retro
Retro override	Paysheet level override to suppress retro for specific employees	Used when retro is triggered by a system correction, not a genuine pay change
Retroactive date limit	Configure maximum retroactive period	Prevents accidental multi-year retro calculations from old data corrections

Always review the retro pay register before confirming payroll. Run the Retro Pay Register report (PSPRTXRG) after paysheet creation and before Pay Calc. Unexpected retro entries indicate either a data entry error or a system configuration issue. Retro amounts that cannot be explained by a documented change event should not be processed without investigation.

📊

Year-End Controls

Year-End Balance Integrity Controls

›

W-2 accuracy depends entirely on the integrity of PeopleSoft's YTD balance tables. Errors in balance tables — whether from voided checks, off-cycles, balance adjustments, or retro pay — accumulate throughout the year and manifest as W-2 discrepancies at year-end.

Key W-2 Balance Controls

Run the W-2 Register report (PSPTX900) in September or October — before year-end — to identify balance discrepancies while there is still time to research and correct them
Reconcile W-2 Box 1 wages (sum of all employees) to four quarterly Form 941 Line 2 totals. Unexplained variances require investigation before W-2 production.
Reconcile W-2 Box 3/5 wages to four quarterly Form 941 Lines 5a/5c. Note: Box 3 is capped at the SS wage base; Box 5 is not.
Review W-2 Box 12 codes for accuracy — particularly GTL (Code C), HSA contributions (Code W), and 401(k) deferrals (Code D)
Verify that all balance adjustments processed during the year are reflected in the W-2 preview

Balance Accumulator Control

PeopleSoft uses accumulator tables (PS_BALANCE, PS_BAL_ADJ_DATA, PS_CHECK_YTD) to track YTD balances. Direct updates to these tables outside of delivered balance adjustment pages are not supported and can corrupt W-2 balances. All balance corrections must go through the delivered Balance Adjustment pages (Payroll for NA > Employees > Employee Payroll Data > Balance Adjustments).

🔄

Tax Update Controls

PeopleSoft Tax Update Application Controls

›

PeopleSoft delivers quarterly Tax Updates containing updated federal and state withholding tables, wage bases, and regulatory form changes. Failure to apply Tax Updates on time creates compounding compliance risk.

Tax Update Application Control Checklist

Apply Q4 Tax Update (annual year-end update) before the first payroll run of the new calendar year — this update contains the new SS wage base and withholding table rates
Apply quarterly Tax Updates within 30 days of release — state tax rate changes are often effective mid-year and must be applied before the affected pay periods
Always apply Tax Updates to a test environment first and run a parallel payroll cycle to verify no unexpected calculation changes before production apply
Document every Tax Update apply: which update number, when applied, who applied it, test results, and production deployment date
After applying a Tax Update, run a spot-check of affected state withholding calculations to confirm the tables updated correctly

Catch-up Tax Updates. Organizations that are multiple Tax Updates behind face a complex catch-up process. Each skipped update must be applied in sequence — they are not cumulative. Skipped updates mean employees have been taxed at incorrect rates, potentially requiring W-2c corrections. If behind on Tax Updates, engage PeopleSoft payroll expertise before attempting a catch-up apply.

📒

GL Interface Controls

General Ledger Interface — Control Points

›

The PeopleSoft GL Interface (also called the Payroll GL Interface) generates accounting entries from confirmed payroll and posts them to the financial system. Errors in the GL interface create reconciliation problems that cascade into financial reporting.

Key Control Points

Combination code validation: The GL interface maps earnings codes, deduction codes, and employee department/location to GL chart of accounts combinations. Unmapped combinations error out rather than posting to a default account — verify all active earnings and deduction codes have valid GL mappings before each payroll cycle
Reconciliation to payroll register: Total GL debits (wage expense) must equal the gross payroll register total. Differences indicate either a mapping error or a confirmed payroll that was not processed through the GL interface
Off-cycle reconciliation: Off-cycle checks must be separately processed through the GL interface — they are not automatically included with the regular cycle GL run
Void and reversal accounting: Voided checks must generate reversing GL entries. Verify the GL interface correctly generates offsetting entries for voided payroll

⚖️

Garnishment Configuration

Garnishment Setup Controls — Disposable Earnings Definition

›

PeopleSoft's garnishment calculation depends entirely on how "disposable earnings" are configured in the Garnishment Rule. An incorrectly configured rule will under- or over-garnish — both of which create liability.

Disposable Earnings Configuration Controls

Deduction type	Include in disposable earnings reduction?	Configuration
Federal income tax withholding (required portion)	Yes — reduces disposable earnings	Deduction class must be marked as legally required
State income tax withholding (required)	Yes	Same as federal — legally required deduction class
FICA (Social Security + Medicare)	Yes	Delivered — automatically reduces disposable earnings
W-4 Step 4(c) additional withholding	No — voluntary election	Must be configured as voluntary, NOT as legally required withholding
Health insurance premiums	No — voluntary deduction	Benefit deductions are voluntary; do not reduce disposable earnings
401(k) deferrals	No — voluntary deduction	Voluntary; do not reduce disposable earnings
FSA contributions	No — voluntary deduction	Voluntary
Union dues	No — voluntary deduction	Voluntary unless mandatory by collective bargaining — verify

Test garnishment calculations for employees with Step 4(c) additional withholding. Run a test garnishment calculation for a hypothetical employee with (a) a creditor garnishment order and (b) W-4 Step 4(c) additional withholding. The garnishment amount should be identical whether or not additional withholding is elected. If the garnishment amount changes, the disposable earnings configuration is incorrect.

📝

Audit Trail

PeopleSoft Audit Trail Configuration

›

PeopleSoft's delivered audit trail capability uses the PeopleTools Auditing Framework, which logs changes to specific record fields to the audit tables (PS_AUDIT_*). This must be explicitly configured for each table and field to be audited — it is not on by default.

Enable Auditing for Critical Payroll Tables

Enable field-level auditing on PS_JOB for COMPRATE, DEPTID, EMPL_STATUS, and FLSA_STATUS
Enable record-level auditing on PS_EMPLOYEE_TAX_DATA — captures all W-4 changes with timestamp and user ID
Enable record-level auditing on PS_DIR_DEP_DISTRIB — essential for detecting direct deposit fraud
Enable record-level auditing on PS_GARN_ORDER — garnishment changes must be traceable
Enable record-level auditing on PS_ADDITIONAL_PAY — standing additional pay setups are high-risk

Audit records are written to PSAUDIT or custom audit tables depending on configuration. These records must be retained per IRS 4-year minimum. Configure the PeopleTools purge process accordingly.

🛡️

Process Security

Process Scheduler Security — Who Can Run What

›

PeopleSoft Process Scheduler controls which users can run which batch processes. For payroll, the ability to confirm payroll, run the GL interface, or generate W-2s must be restricted to authorized roles only.

Critical Process Security Rules

Process	Who should be authorized	Segregation requirement
Pay Confirmation (PAYCONF)	Payroll Manager and above	Cannot be same person who entered paysheet data
GL Interface (PAYGL001)	Payroll Manager + Finance approval	Requires post-confirmation authorization
W-2 Production Print	Payroll Director only	Final authorization after W-2 register review
Balance Adjustment (PAYBALAD)	Payroll Manager minimum; Director for prior-year	Requires documentation and secondary authorization
Tax Update Apply	IT + Payroll Director	Requires documented regression testing before apply
Direct Deposit file generation	Payroll Manager + dual authorization	Never single-person authorization for ACH file creation

🔧

Customization Controls

Custom Code — Control Requirements for Payroll Modifications

›

PeopleSoft customizations (custom PeopleCode, modified Application Engine programs, custom SQR reports) in payroll require specific controls because they can override delivered compliance logic.

Customization Control Requirements

Every custom object affecting payroll calculation must have a written technical specification retained in the project library
Custom PeopleCode that modifies withholding amounts, garnishment calculations, or FICA must be reviewed by a qualified payroll tax expert before production deployment
Custom Application Engine programs that update pay balance tables directly (bypassing the delivered calculation engine) must be documented and reviewed annually
Maintain a customization inventory — a register of all custom objects, what they do, and when they were last tested against the current PeopleTools and Tax Update levels
During Tax Update applies, the delivered regression test plan must include testing any custom objects that interact with the updated tables

Configuration over customization. Before building a custom solution for any payroll compliance requirement, verify whether delivered PeopleSoft functionality addresses the need. Custom code is a tax on every future upgrade and Tax Update apply. Where delivered functionality solves the problem, use it. Document the decision.