PU03 — Maintain Payroll Status Infotype 0003

PU03 opens infotype 0003 for direct editing. Infotype 0003 is unusual among HR infotypes because most of its content is not typed in by an administrator during normal master data maintenance, it is written automatically by the payroll driver and by other infotype changes, tracking the earliest date from which retroactive accounting must run for the employee, and any lock that prevents payroll from processing that employee at all. Because the record is system-maintained, PA30 typically shows it read-only or does not surface it in the normal action menu. PU03 is the back door for a payroll administrator to correct the earliest retro date directly, release a locked employee, or reset a correction-run indicator without waiting for another master data change to trigger the recalculation naturally.

PU03 gets used when a payroll run fails or produces unexpected results tied to retroactive accounting scope for one employee, when an employee appears locked out of the payroll driver despite no obvious infotype lock elsewhere, or when a correction run needs to be forced back to a specific period without re-triggering every change since hire. It sits in payroll support and incident resolution, not in day-to-day HR administration. A functional payroll consultant reaches for it after diagnosing that the retro date on infotype 0003 does not match expectation, not as a first troubleshooting step. Time administrators and HR generalists rarely touch it; in most authorization concepts it is restricted to payroll support roles because a wrong edit here changes the scope of a live payroll run.

Pull PA0003 by SE16 or a query, filter on the personnel number, and sort by BEGDA descending. Compare the earliest retro date and lock field across the last two or three time slices. A manual PU03 edit shows as a delimited record with a BEGDA that does not correspond to any obvious master data event, hire action, or organizational change. If the retro date jumps backward with no corresponding infotype 0000 or 0001 change on the same day, that record was set directly rather than derived by the system, which is the signature of a PU03 edit.

PU03 and infotype 0003 are unchanged on S/4HANA on-premise payroll, this remains a backend technical transaction with no dedicated Fiori equivalent, since it is a support tool rather than an administrative process. In a SuccessFactors Employee Central landscape running side-by-side or replicated payroll, infotype 0003 still lives in the on-premise payroll system that actually calculates results, so PU03 remains the correction point there even though master data itself is maintained in Employee Central and replicated in.

This is a payroll functional problem, escalated to a payroll support consultant with production access, not a generalist HR administrator issue. A clean handover states the personnel number, the current and target values of the relevant infotype 0003 field, the payroll period affected, and whether a payroll run has already executed since the discrepancy was noticed. Basis involvement is only needed if the block turns out to be an authorization object or a stuck payroll control record lock.

PA20 and PA30 are the natural comparison points, since infotype 0003 typically shows read-only there, which is what sends a consultant looking for PU03 in the first place. PC00 and the payroll driver transactions matter because the payroll run is both the automatic writer of infotype 0003 and the process that reveals whether a PU03 correction actually held. Reading up on retroactive accounting logic and payroll control record status rounds out the diagnostic picture, since infotype 0003 exists specifically to serve that mechanism.