With more than 10 years of experience supporting large-scale payroll and HR systems across the United States and Canada, Sri Bhavyanath Chennapragada brings a practitioner’s perspective to one of the less visible risks in payroll transformation: earnings code configuration.
In this article for ERP Today, he explains how a misconfigured setting in PeopleSoft HCM can affect overtime calculations at scale and outlines the review disciplines teams should put in place before those issues reach production.
A configuration issue in payroll rarely stays small for long. In the ERP world, a single earnings code setting can become a compliance problem that scales across every pay cycle until someone spots what the system is missing.
I have seen this scenario play out firsthand while supporting payroll operations for a large enterprise retailer with more than 225,000 employees across 35 states. The error was easy to miss in normal operations. The potential exposure was not.
This is how a seemingly minor setup decision can turn into a much larger implementation and compliance issue.
How Do Payroll Teams Spot an Overtime Calculation Error in UAT?
You almost never find this kind of error by auditing the configuration directly. You find it by looking at a calculated result that looks too clean.
In this case, I was conducting a post-payroll UAT — User Acceptance Testing — and running a parallel payroll cycle to validate the system’s outputs before go-live. I pulled a payroll register for a group of store associates who had worked significant overtime that week.
Each of them had also received a Production Bonus and a Night Shift Differential.
The overtime rate was exactly 1.5 times their base hourly rate. Clean. Precise. Wrong.
The signal: In a correctly configured system, that overtime rate should not remain a clean number when the employee has earned a non-discretionary bonus that week. If an associate earns a $200 Production Bonus on top of their base rate, the Regular Rate of Pay — the FLSA-mandated baseline for overtime calculations — must incorporate that bonus. The overtime rate should reflect that added amount rather than staying at a round figure like $27.00. When it stays too clean, that is usually a sign the bonus was ignored.
Pro tip — the UAT trap: Most teams test that the bonus pays. Fewer test whether the bonus changes the overtime rate. If your UAT scripts do not include an employee who has both a bonus and overtime in the same week, you are not fully testing compliance. That gap in the test scenario can leave a significant FLSA issue undiscovered until much later.
At that point, I paused the parallel run and flagged the issue to the team as a likely systemic calculation problem.
How Can a PeopleSoft Query Reveal Overtime Calculation Issues?
The first move in any FLSA earnings code investigation is a direct query against the EARNINGS_TBL — PeopleSoft’s central earnings code setup table. The two fields that matter are EFFECT_ON_FLSA — which controls whether hours and amounts affect the FLSA rate calculation — and FLSA_CATEGORY, which classifies each earnings code as Regular, Overtime, or Excluded.
sql
SELECT ERNCD, DESCRSHORT, EFFECT_ON_FLSA, FLSA_CATEGORY, ADD_GROSS, EFFDT
FROM PS_EARNINGS_TBL
WHERE ERNCD IN (‘PRODBNS’,’NIGHTDIFF’,’WKNDPREM’)
AND EFF_STATUS = ‘A’
The finding: The Night Shift Differential earnings code — NIGHTDIFF — had EFFECT_ON_FLSA set to ‘N’. The code had been created by the Compensation team to pay store associates an additional $2.50 per hour for overnight shifts. It was taxable, it mapped correctly to the general ledger, and it calculated correctly in gross pay. But it was invisible to PeopleSoft’s FLSA overtime engine.
To confirm the impact, I joined PS_PAY_OTH_EARNS to PS_PAY_EARNINGS, comparing FLSA_RT against HOURLY_RT for employees who had earned the shift differential and worked overtime in that pay period.
sql
SELECT P.EMPLID, E.ERNCD, E.OTH_HRS, E.OTH_EARNS, P.HOURLY_RT, P.FLSA_RT
FROM PS_PAY_OTH_EARNS E
JOIN PS_PAY_EARNINGS P
ON E.COMPANY = P.COMPANY
AND E.PAYGROUP = P.PAYGROUP
AND E.PAY_END_DT = P.PAY_END_DT
AND E.OFF_CYCLE = P.OFF_CYCLE
AND E.PAGE_NUM = P.PAGE_NUM
AND E.LINE_NUM = P.LINE_NUM
AND E.SEPCHK = P.SEPCHK
WHERE E.PAY_END_DT = [current period]
AND E.ERNCD IN (‘OT’,’OT1HLF’)
The FLSA_RT matched HOURLY_RT exactly for every employee who had worked overtime and earned the shift differential. That confirmed the problem: the system was calculating overtime based only on the base hourly rate, as if the differential did not exist.
Analysis
What This Means for ERP Insiders
Configuration is policy in payroll systems. This case shows that an earnings code setting is not just a technical field; it can shape whether the system applies labor rules correctly across every pay cycle. For ERP teams, that means payroll configuration needs the same governance discipline as any other compliance-sensitive control.
Why It Happened — The Communication Gap
The root cause of this error is almost always the same, and it has nothing to do with the technology.
The person who creates a new earnings code is typically an HR or Compensation analyst.
Their frame of reference is simple: this is extra pay for working an undesirable shift. They configure the code correctly from their perspective — it adds to gross pay, it taxes correctly, it maps to the right cost center.
What they do not consider — because it is not their area of expertise — is the FLSA implication. Under 29 CFR § 778.115, any non-discretionary payment to a non-exempt employee must be included in the Regular Rate of Pay calculation. A Night Shift Differential of $2.50 per hour is not a bonus — it is compensation for time worked. It increases the value of every hour that employee worked that week, including the overtime hours.
The gap: The HR analyst may view the payment as an extra $2.50 for the overnight shift. The FLSA calculation treats that same $2.50 as part of the employee’s regular rate of pay for the week, which means it also affects the overtime rate. When those two perspectives never connect, the EFFECT_ON_FLSA field can remain set to None, and the organization begins accruing underpayment risk without realizing it.
At enterprise scale, this gap is not a theoretical risk. Across a retail workforce where thousands of store associates regularly work overnight shifts and earn overtime, a single misconfigured earnings code compounds into a material compliance exposure with every passing pay cycle.
What Happens When an Overtime Calculation Error Reaches Production?
The damage assessment in this scenario required answering three questions immediately.
- How long has this been live? In a new implementation, catching this in UAT is the best possible outcome — the error is caught before it has touched a single live paycheck. If this surfaces six months into production, the organization is looking at potentially hundreds of thousands of incorrect paychecks and a retroactive correction obligation that spans the entire period.
- How many employees are affected? In a 225,000-employee retail environment where overnight shifts are standard across distribution centers, fulfillment operations, and 24-hour store locations, the population of affected employees can be enormous. We are not talking about edge cases.
- What is the penalty exposure? Under the FLSA, underpayment of overtime is not resolved simply by paying the difference. Employers may also owe an equal amount in liquidated damages, effectively doubling the liability. If the issue is deemed willful, the lookback period can extend from two years to three.
Scale matters: Across 10,000 employees working overtime in a single pay period, a Night Shift Differential that is incorrectly excluded from the FLSA calculation can produce more than $3,000 in weekly underpayment before liquidated damages are considered. Extend that across multiple pay periods and a longer lookback window, and the exposure becomes material enough to draw audit and finance attention.
Analysis
What This Means for ERP Insiders
UAT has to test interactions, not just transactions. It is not enough to confirm that bonuses, shift differentials, and overtime all calculate on their own. Implementation teams need test scenarios that validate how those elements interact, because that is often where compliance gaps appear.
The Fix — What Has to Change
The technical correction itself is straightforward. In PeopleSoft, you navigate to Set Up HCM > Product Related > Payroll for North America > Compensation and Earnings > Earnings Table.
For each affected earnings code, the FLSA Effect field must be updated from None to the correct classification — typically Add to Regular Rate for non-discretionary pay types like shift differentials and production bonuses.
But the technical fix addresses only the symptom. The more important fix is procedural.
What Should Teams Review Before Activating a New Earnings Code?
Every new earnings code created in the system — regardless of which team initiates the request — should go through a mandatory FLSA impact review before activation. That review should answer four questions:
- Is this payment non-discretionary?If the employee can reasonably expect to receive it based on a predetermined formula or schedule, it should be included in the FLSA calculation.
- Does this payment compensate for time worked?Shift differentials, on-call premiums, hazard pay, and production bonuses are not discretionary gifts; they are compensation tied to working conditions or performance.
- What is the correct FLSA Effect setting?In PeopleSoft, the relevant options include Add to Regular Rate, Add to Straight Time, or None. Most non-discretionary pay types belong in Add to Regular Rate.
- Has Payroll and Legal signed off?The compliance review cannot sit only with Compensation. Payroll and Legal should review and approve new earnings codes before they go live.
- The rule:If HR creates the code and Payroll never reviews it, the configuration gap can remain in place while the liability continues to build. The FLSA impact review needs to function as a required gate, not an optional step.
What Every PeopleSoft Team Should Do This Week
If you are running PeopleSoft Payroll for North America and have not recently audited your earnings codes for FLSA compliance, this is a useful query to start with:
sql
SELECT ERNCD, DESCRSHORT, EFFECT_ON_FLSA, FLSA_CATEGORY, ADD_GROSS, EFFDT
FROM PS_EARNINGS_TBL
WHERE EFF_STATUS = ‘A’
AND ADD_GROSS = ‘Y’
AND EFFECT_ON_FLSA = ‘N’
AND FLSA_CATEGORY = ‘X’
ORDER BY ERNCD
Every earnings code that adds to gross pay and is marked EFFECT_ON_FLSA = N and FLSA_CATEGORY = X is a potential compliance gap.
Review each one. Ask the question — is this payment non-discretionary? If the answer is yes, the configuration is wrong and the clock is ticking.
The checkbox is small. The liability is not.
Analysis
What This Means for ERP Insiders
Ownership cannot stop with HR or Compensation. This is a familiar enterprise problem: one team creates the pay element, but the downstream compliance impact sits with Payroll and Legal. ERP leaders should treat earnings code design as a cross-functional governance issue, not a single-team setup task.
