Gross-to-Net Mismatch After a Mid-Period Pay Group Move
An employee transfers from a monthly pay group (paid on the last day of the month) to a semi-monthly pay group (paid on the 15th and last day) effective the 10th of the month. The transfer was entered with the correct effective date, but the employee was paid a full monthly salary on the prior month-end and then a full semi-monthly salary on the 15th. The employee also had a garnishment with a per-pay-period cap that was calculated against the monthly frequency. Two additional employees transferred the same day with the same result. Payroll is closing in three days, and the garnishment vendor has already been sent the monthly-cap remittance file.
1. Diagnose why the employee was overpaid and identify the configuration that most likely caused it.
Read the worked answer
The symptom - a full monthly payment and a full semi-monthly payment in the same period - points to proration not being applied at the pay group transition, not to a data-entry error (the effective date is correct).
Likely causes, in order of probability:
- The pay group change did not trigger a proration rule. Many configurations prorate on hire/termination but not on a mid-period pay group move. The monthly run calculated a full period because the employee was active for the full monthly period per the old group's calendar; the semi-monthly run then calculated a full period because the new group's calendar started fresh.
- Overlapping pay period calendars. If the monthly period end and the semi-monthly period start are not reconciled, both runs see a full period of eligibility.
Confirm by pulling the payroll results for both runs and checking the proration flag and the period start/end dates each run used. The fix is a proration rule keyed to the pay group change effective date, plus a manual recovery for the three affected employees this cycle.
2. The garnishment cap was calculated on the monthly frequency but remitted against a semi-monthly payment. What is the correct remediation, and what is the sequencing constraint given the vendor file is already sent?
Read the worked answer
The garnishment cap is a legal withholding limit, so the error is not just a rounding issue - over-withholding creates compliance exposure and under-withholding creates vendor liability. Two failures exist: the cap was computed on the wrong frequency, and the remittance file was sent before the payroll was validated.
Correct remediation:
- Recompute the cap on the semi-monthly frequency for the 15th payment. The per-period cap is generally half the monthly cap for a semi-monthly frequency - confirm against the order's terms, since some orders specify a monthly maximum that must be tracked cumulatively across periods rather than halved.
- Do not simply reverse the vendor file. Issue a corrected remittance for the next cycle and reconcile the difference (over- or under-remitted) as an adjustment line so the vendor's ledger matches payroll.
- Sequence: correct payroll first (the employee's net pay is the source of truth), then correct the remittance. Sending a corrected file before payroll is finalized risks a third mismatch.
- Prevent recurrence by tying the garnishment cap calculation to the pay frequency of the period being processed, not the employee's home frequency.