Payroll Run Stopping On One Employee Only

Payroll reports it as 'the run failed for one person again' or 'this employee never goes through with everyone else'. It surfaces during period-end processing: the batch job for the whole payroll area finishes, the exception list shows a single personnel number in red, and everyone downstream (finance posting, payslip generation, bank file) is held up waiting on that one record. HR admin usually insists nothing changed for the employee, or mentions in passing that the person was transferred, went on leave, or had a correction backdated a few months. The payroll team's first instinct is to rerun the whole batch, which does nothing because the error is specific to that personnel number and reproduces identically every time. By the time it reaches a consultant, the deadline pressure is high because the exception is blocking the exit-to-finance step.

Pull the payroll log for the exact personnel number and period, not the summary log, and capture the operation name and message text at the point of failure. Alongside it, pull the infotype history for basic pay, organizational assignment, and payroll status for a window spanning several months before the current period, sorted by effective date, to expose gaps or a retro date sitting inside a recently corrected record. This pairing, log message plus infotype timeline, is what makes the root cause visible rather than assumed.

If the cause is a retro limit, either correct the infotype record so the effective date falls within the allowed window (a data fix, no transport) or extend the retro-accounting limit for the employee or payroll area through configuration, which requires a transport and sign-off since it changes recalculation exposure for the whole group. If the payroll status record is inconsistent or locked, correcting the dates or clearing the lock is a data-level fix done directly on the record, not a config change. Infotype gaps or overlaps are closed by delimiting or inserting the missing record; this is data maintenance and should mirror exactly what the business event actually was, not an arbitrary date chosen to make the error disappear. A PCR or schema defect triggered by an edge case is a configuration fix: correct the rule in the development client, test against the specific employee's data in simulation, then transport through the landscape in the normal sequence. Wage type valuation gaps are closed by adding the missing entry for the relevant grouping, again a transportable config change. Integration-sourced data gaps are fixed at the source in Employee Central and re-replicated, not patched directly in the target system, or the next sync will overwrite the manual correction.

The reflex is to force the employee through: manually reset the payroll status lock, push the earliest retro date forward past the problem area, or delete the failed cluster result so the exception disappears from the list. This clears the symptom for the current run but does not fix the underlying data inconsistency, and it often produces a payroll result that is technically valid but financially wrong, since the retroactive change that should have been recalculated gets skipped entirely. The next retro-relevant change on that employee reopens the same window and the error returns, usually worse, sometimes with an underpayment or overpayment that only surfaces at year-end reconciliation.

First triage sits with the payroll processing team running the period. If the log points to a PCR, schema, or wage type valuation defect, it moves to the payroll technical or configuration consultant, since the fix needs a transport. If the employee originates from Employee Central, the integration team is looped in to confirm whether the source data was ever correct before it reached payroll. The handover note should carry the personnel number, period, exact log message, and whether the fix applied was data-level or config-level requiring transport.