PT60 — Off-Cycle Workbench for Individual Payroll Runs

PT60 lets a payroll administrator process one employee or a defined subset of employees outside the normal, scheduled payroll cycle. It is not a separate payroll engine: it invokes the same driver used for the regular run, but forces an off-cycle payroll type, an off-cycle reason, and a specific off-cycle date instead of using the payroll area's standard period. The one structural fact that explains most confusion is that off-cycle results are stored as their own entries in the payroll results cluster, tagged with a payroll type and sequence number, sitting alongside the regular result for the same period rather than replacing it. This means an off-cycle run can coexist with a locked regular run, but it can also trigger a retroactive recalculation if its date falls inside an already-paid period, which is where most incidents originate.

PT60 is reached for after the regular payroll run has already been executed and something needs paying to a specific employee before the next scheduled run: a signing bonus, a termination settlement, a correction found in an audit, or an advance against next month's salary. It is also used for correction runs limited to one or two personnel numbers where re-running the entire payroll area through PC00 would be wasteful and would re-lock everyone else's results. It is not used for the standard monthly or biweekly run for the whole payroll area, and it is not a substitute for infotype maintenance; the underlying master data changes still go through PA30 or the relevant infotype transaction before the off-cycle run picks them up.

Start with PA0003 for the personnel number in question: check the earliest personal retro date field and the last payroll run indicator to see whether the off-cycle run left a lock or forced a retro back further than intended. To confirm what the off-cycle run actually paid, do not query the cluster tables directly with SE16, since they are compressed; use the payroll result display transaction, filter by personnel number and in-period, and compare the off-cycle sequence entry against the regular sequence entry for the same period to see which wage types diverged.

PT60 exists unchanged in S/4HANA and in SAP Payroll running on SuccessFactors Employee Central Payroll, since the classic payroll engine and its cluster-based results were carried forward rather than replatformed. There is no functional redesign of the off-cycle logic itself. Some landscapes expose an off-cycle payroll run through a Fiori app aimed at HR administrators, but the underlying processing, off-cycle reasons, and results storage are the same as the GUI transaction, so diagnosing a problem still comes back to PA0003 and the payroll result display regardless of which front end triggered the run.

This is a functional payroll consultant's transaction end to end; ABAP involvement is only needed if a schema or payroll rule has to be changed to handle a new off-cycle wage type or reason. A clean handover to Basis or ABAP includes the personnel number, the off-cycle reason and date used, the simulation log with the exact error message, and whether the issue reproduces on simulation only or also on the live run.

PA0003 is the first table to check for any off-cycle run problem, since its lock and retro date fields explain most unexpected behavior. PA0267 holds the ad hoc payment data an off-cycle bonus or correction run actually consumes, so infotype maintenance through PA30 usually precedes a PT60 run. PC00 is the scheduled payroll driver that PT60 wraps for a single employee, useful to compare against when an off-cycle result looks inconsistent with the regular run. PT61 is worth reading alongside PT60 for the release and exit side of the same off-cycle process.