PA03 — Maintain Payroll Status (Infotype 0003)

PA03 maintains infotype 0003, Payroll Status, the record that tells the payroll driver how far back a personnel number needs to be recalculated and whether the number is locked for payroll processing. The structural fact that explains most confusion: these fields are normally set automatically by the system whenever a master data change or a payroll run occurs. PA03 opens a back door to edit them directly, bypassing the automatic logic that keeps them consistent. PA30 displays infotype 0003 but greys most of these fields out; PA03 does not. That difference is exactly why PA03 exists as its own transaction rather than being folded into PA30, and exactly why editing through it demands more care than editing any other infotype.

PA03 is reached for during payroll troubleshooting, not during routine master data maintenance. Typical triggers: an employee is excluded from the current payroll run because the personnel number is locked, or the earliest retroactive accounting date is wrong and either suppresses a needed retro recalculation or forces one that should not happen. It also comes up after a manual correction to a payroll result outside the normal run, where the status record needs to be reset to match. In a SuccessFactors Employee Central Payroll landscape, core HR master data lives in Employee Central, but payroll status still lives in the infotype 0003 record inside ECP, so PA03 remains the tool for this correction even though hiring and organizational changes happen in the cloud HR system.

Pull PA0003 by personnel number and compare the earliest master data change date and earliest retroactive accounting date against the last payroll run date for that employee. If the earliest MD change date is later than a master data change that should have triggered retro, the trigger was suppressed. Cross-check PA0001 for the payroll area and pay period assigned at the same validity date; if the payroll area on PA0001 does not match what payroll actually processed, the PA03 edit was applied against the wrong context and the run will not reflect it.

PA03 is unchanged on S/4HANA on-premise HCM and in Employee Central Payroll, since payroll status is still stored as classic infotype 0003 regardless of where core master data is edited. There is no dedicated Fiori app for this correction; it remains a GUI transaction. In a pure SuccessFactors Employee Central deployment without ECP, payroll status of this kind does not exist in the same form, since payroll runs in a different downstream system.

This is a payroll functional problem, not Basis or ABAP, but access to PA03 is usually restricted more tightly than PA30 and any authorization change goes through the security owner, not the payroll consultant directly. A good handover includes the personnel number, payroll area, affected period, the before and after values of the changed field, and the business reason for the change written down outside the system.

Read PA30 first to understand why the same fields appear locked there and why PA03 is needed at all. PC00 is the payroll driver that actually consumes the earliest retroactive accounting date set here, so understanding what PC00 does with that date explains what a PA03 correction is meant to achieve. PU03 configures the reason codes offered when a field in PA03 is changed, which is worth checking when the reason list on screen looks wrong or incomplete. PA20 is useful for a read-only check of the current infotype 0003 values before touching anything in change mode.