Retro Pay

Retro Adjustment, Retro Pay, and Missed Pay

Retro Pay

Difference in pay owed to an employee from a prior pay period. Should not be processed as off-cycle. Retro pay transactions include those that are automatically triggered via the Retro Pay module and those that must be submitted by the location via file/transaction.

  • For example: Employee receives a retroactive promotion and is owed money due to the difference between pay in current job and new job

Retro Adjustments 

Certain changes adjustment such as comp rate, comp frequency, Other pay, earnings end date, made to employees’ data with retroactive dates that may result in a retroactive pay either under or over-pay they have previous received.

Missed Pay

Hours or earnings due but not paid to employee. Non-retro earn codes used to process pay.

  • For example: Employee is biweekly hourly. Hours were submitted late and did not generate pay. Because these hours were not previously paid, it is considered missed pay. These hours should be submitted with regular earn codes, not retro earn codes.

Roles and Responsibilities for Department/Service Channel, Payroll, and UCPath Center

Department/Service Channel

  • Identities the need to update an employee’s information with a retroactive effective date
  • Submits Job Data and/or Additional Pay transaction via PayPath or Smart HR template
  • Submits pre-conversion retro, missed pay, and/or overpayment requests for transactions that will not be paid via the Retro module
  • Reviews Retro reports and reaches out to the UCPath Center with any issues

Payroll

  • Validates and denies/approves Overpayment request for E-078 transactions
  • Coordinates overpayment transactions with departments/service channels

UCPath Center

  • Approves Job Data and Additional Pay Requests* (except PayPath transactions) submitted via Smart HR Template and commits them to UCPath
  • Ensures downstream impact of retro changes to employee eligibility and benefits elections/contributions, accruals are updated if retro transaction results in changes
  • Reviews pay requests in Retro module for validity and provides the Loaded Retro Results report to locations
  • Manages the overpayment recovery process

There are two ways to process retro pay:

Retro Pay Module

Retro Transactions

  • Retroactive Job Data or Additional Pay changes that trigger the Retro module are reviewed/validated by the UCPath Center. Retro Job Data changes that trigger in UCPath
    • Comp Rate
    • Comp Frequency
    • Other Pay (increase in additional pay)
    • Earnings End Date
  • For transactions that can be processed completely through the Retro module, no/minimal location intervention is required
  • Paid via on-cycle check
  • Retro transactions are used for items that do not trigger pay in the retro module
  • Retro transactions are submitted via:
    • Flat Dollar Amounts (I-618)
    • Payroll Request (E-078) for Overpayment only
    • Non-recurring Flat Dollar Amounts (E-353)
  • Retro transactions are processed using the overpayment process if a retro transaction results in a negative result
  • Money due to an employee as a result of a retro transaction is paid via on or off-cycle check, depending on file used

Refer to UCD’s Retro Pay Matrix Job Aid to review detailed scenarios and applicable submission methods

If a correction needs to be made to Job Data/Additional Pay data that already created a retro trigger, one of three scenarios may result:

  • If the change is made within the same pay cycle, and the original calculated retro amount has not been loaded, it will re‐trigger within the module and move to a “Re‐calculate Request” status. Once PY runs the retroactive pay calculation, it will recalculate that request and a new retro amount will be available to review.
  • If the original calculated retro amount is already loaded (and the check has not been confirmed), and a new Job Data change is made (increase or decrease), UCPath will create a new trigger but will only generate a new calculation based off of prior confirmed checks in UCPath. The problem with this is that it won’t account for the loaded retro amount because that check is not confirmed yet.
  • If the original calculated retro amount is already loaded (and check is confirmed), and a new Job Data change is made after confirmation (increase or decrease), the system will create a new trigger and calculate a retro payment based off of prior confirmed checks and it will take into account prior paid retro.

Submitting Retro Adjustments for changes before and after conversion

Process

Pre-Conversion Dated Trans*

Post-Conversion Dated Trans

Additional Pay - Hours

I-181 File

1-181

Additional Pay - Amounts

E‐330 (Additional Pay)

E‐353 (One‐Time Payment)

I‐618 (Flat Dollar Amount) File

E‐330 (Additional Pay)

E‐353 (One‐Time Payment)

I‐618 (Flat Dollar Amount) File

Retro Payments

E‐353 (One‐Time Payment)

I‐618 (Flat Dollar Amount) File

Update UCPath data

*Only use Earn Codes that start with a 9 if using it for pre-conversion retro pay

Review UC_PY Loaded Retro_Trans

  • This report is sent to locations for review once it is loaded
  • Review UC_PY_LOADED_RETRO_TRANS query that is sent prior to payday before submitting retro request transaction otherwise it may lead to an overpayment
    • If duplicate entries are found, inform UCPath Center via:
      • QCU for urgent processing or Case, if time permits

Retro Pay

The report breaks down the total retro amount paid by pay code to the employee

  • Pay Period End date displays the payroll that the retro amounts were loaded to
  • Earns Begin and End dates display the time frame for which the employee is owed retro
  • Other Pay displays the total retro amount paid to the employee
  • Total is the total retro due/paid to the employee

Other Considerations

  • Before submitting retro payment, ensure that Job Data reflects correct information
    • Submit Job Data form if data needs to be updated with effective dates prior to conversion
  • If retro transactions lead to a negative amount, UCPC will notify of this via Case.  An Overpayment transaction will be required to recover funds