Retro Pay Processing

Summary Retro Process

A retroactive payment is a payment made to an employee or group of employees as a result of a salary/rate increase applied to a past time frame containing paid periods. For example: Assume a monthly payroll, and the current month is March. A union or bargaining unit negotiates a new contract with a pay increase of 5 percent for a certain position. The increase is to be applied retroactively starting July 15 of last year only for pay in that position. We must calculate what has already been paid for that position (July 15 through February), the amount that should have been paid (5% more), and give the employee the difference, proportionally distributed, in the current period.

The Summary Retro Process (PYUTRTRT) utility creates a list of pay periods that are within the retro payment time frame. CDHs and payments in history that are to be retroactively paid against are accumulated from those periods; this accumulation is what makes up the Retro Pay Base (PB) and Hour Base (HB). Once accumulated, the Retro PB is multiplied by a percentage increase, or the HB is multiplied by a flat dollar amount, giving the actual retro payment. The retro payment may be either:

• Associated with the original hour codes that made up the PB/HB.
• Summarized into a single hour code.
• Mapped to entirely new hour codes.

Once the pay is associated with an hour code or codes, it is spread proportionally across the pay lines that made up the PB/HB, thus retaining the original distribution. The entries are then placed in a timecard batch that may then be distributed and paid. There is also a method that multiplies the difference between new and old salaries by the number of periods in the time frame. The process will detect if an employee is daily timecard or summary timecard and create the appropriate batch.

The Retro Pay and Hour Bases

There has been a Pay Base and Hour Base set aside solely for this process. These are Pay Base 18 and Hour Base 18. Any CDH that is to affect Retro Pay should affect these bases. The purpose of these bases is to accumulate the hours and dollars that are to be used in the calculation. Any payment amount to be included in the retro payment calculation should add to the Retro PB, and any hour should add to the Retro HB.

Common Code PYFG / PY220C

Set up PYFG/PY220C to set retro set processing parameters.

Patch by Pay Line Retro

Patch by Payline Retro (PYUTRTRP) is the standard retro utility that is run when there is a salary, rate or hours change. What this utility does is compute the dollar difference when a salary or rate change occurs, and the hour difference when there is a hour change. It does this by computing the new estimated salary.

Earnings Correction

Use the Earnings Correction utility (PYUTRTEC) to generate earnings on a contract if earnings patched do not equal the Total Contract Value. The periods remaining to earn must be zero and the latest Calc End date on the Contract must be prior to the period begin date.

Troubleshoot a Retro Problem

Investigate the Pay Assignment (HRPYPA), Contract tab.

Confirm the Pay Assignment has been sent to Payroll.

• Look up the pay assignment in payroll (PYUPEP). Does the per period amount match the per period amount in HR? If no, send pay assignment to Payroll and recalculate.

Confirm the Total Contract Value "TCV."

• What is the TCV? Is it correct? If no, then recompute the contract and recalculate the pay and retro.
• How much has already been paid on that period? Has it already met the TCV? If no, then recompute the contract and recalculate the pay and retro.
• How many periods are remaining? If 1 period is remaining, then the contract is trying to pay off the amount in the TCV. Is the TCV amount correct? If no, then recompute the contract and recalculate the pay and retro. If still no, then is the actual days x actual hours x hourly rate correct?
• Override the TCV if unable to resolve timely. Contact PowerSchool for assistance.

Is the Payroll setup correct?

• Is the pay class set up for retro (PYUPPY)? If no, then add the hour codes to the pay class and recalculate.

FAQ

Q: Why can't I have a calculation based on the rate, like:
Retro Pay = (Retro HB * New rate) - (Retro HB * Old rate) ?
A: The primary reason is that there is no way to ensure that the payments associated with the original hours that make up the Retro HB were calculated using the old rate given in the above fora different rate may have been used, yielding an erroneous retro payment. Thus, except when the user wants to use a flat dollar amount to multiply the Retro HB by, the Retro PB must be used.

Q: Why do I have to use selection criteria to derive a salary or rate ratio? Why can't the system link each history record used for the Retro PB/HB with the correct pay assignment?
A: The system has no way of ensuring that a pay line in a history record will ever match a current pay assignment. The pay line from history may be an overridden pay line from a timecard that never was part of an assignment. For this reason, the retro process uses selection criteria both to derive the percentage increase from the pay assignments, and to select the history records which are used to accumulate the Retro Pay/Hour Base.