PT61 — Correction of Time Data Transaction
PT61 is the correction transaction for Time Management infotypes (absences, attendances, substitutions, availability). It behaves like PA30 but is scoped to time-relevant infotypes and, critically, sets the earliest retroactive accounting date on infotype 0003 when a record is changed, forcing time evaluation to reprocess the period. Use it instead of PA30 whenever a correction must trigger recalculation.
This page covers PT61, the dedicated correction screen for time infotypes used after time evaluation has already run for a period. It focuses on why edits made here differ from the same edit made in PA30, and on the diagnostic sequence for cases where a correction is entered but the time results never change.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,127 words
Purpose
PT61 is the correction screen for Time Management infotypes, structurally almost identical to PA30 but restricted to time-relevant infotypes and framed for time administrators rather than HR generalists. The one fact that explains most confusion: a change entered through PT61 updates the earliest-retro-accounting-date on infotype 0003, which is what forces time evaluation to reprocess the affected period on its next run. A change to the same infotype record made through PA30 can save cleanly but not reliably push that retro trigger, so the record looks corrected in display but the cluster results from the last time evaluation run are left untouched. PT61 exists specifically to close that gap.
When it is used
PT61 is reached whenever a time infotype record needs correcting after PT60 (time evaluation) has already processed the period: a wrong absence code, a missed substitution, an attendance entered against the wrong work schedule, a partial-day correction discovered during payroll pre-checks. It sits between the front-end capture tools (CATS, employee self-service time entry, shift planning) and payroll: those tools create the original record, PT61 fixes it after the fact. It is not used for mass corrections across many employees at once, and it is not the tool for initial time capture. Consultants reach for it specifically when a correction must be visible to the next time evaluation run, not just to a report or infotype display.
How to use it in practice
- Enter the personnel number and confirm the correct personnel assignment if the employee has concurrent employment
- Select the time infotype to correct from the menu (absences 2001, attendances 2002, substitutions 2003, availability 2004, or others depending on configuration)
- Choose the existing record by validity period rather than creating a new overlapping one, to avoid delimitation errors
- Edit the relevant fields and save, watching for the retroactive accounting date confirmation on infotype 0003
- Rerun or schedule time evaluation (PT60) for the affected period to pick up the correction, since PT61 itself does not trigger evaluation
Key data objects
- PA2001 - absence records (type, dates, times, quota deduction link)
- PA2002 - attendance records including overtime and on-call entries
- PA2003 - substitutions changing the valid work schedule for a period
- PA2004 - availability records used in shift and overtime evaluation
- PA0003 - payroll status infotype, specifically the earliest retroactive accounting date fields that PT61 updates on save
- Cluster B2/PCL result tables - not written by PT61 directly, but the reason the correction is invisible until time evaluation reruns
How to prove it in the data
In SE16 on PA0003 for the personnel number, check whether the retroactive accounting date for time evaluation was pushed back to before the correction date after the PT61 save. Compare the change timestamp on the relevant time infotype (AENDT/UNAME on PA2001, PA2002, etc.) against the last run date logged for that employee in the time evaluation run log. If the infotype change postdates the last evaluation run and the retro date on PA0003 was not moved back, the correction will not appear in the cluster results until evaluation is rerun.
ECC vs S/4HANA
On S/4HANA on-premise, PT61 is functionally unchanged; it remains a GUI transaction and there is no Fiori app that replaces the correction workflow itself, though time recording and approval have Fiori equivalents for entry. In a SuccessFactors Time Tracking or Time Off cloud scenario, PT61 does not apply at all: corrections happen in the cloud application and are replicated back to on-premise infotypes via integration, so the retro-trigger logic described here is only relevant for the on-premise or hybrid replication side, not for pure cloud time processes.
Common pitfalls and how to diagnose them
- Correction not reflected in results: the record saved through PT61 looks correct in display, but the cluster/PCL time evaluation results still show the old values. This almost always means time evaluation has not been rerun since the change. Check PA0003 for the retro date, confirm it moved to on or before the corrected period, then check whether a scheduled evaluation run actually covered that date range afterward.
- PA30 used instead of PT61: someone corrected the same infotype through PA30 out of habit. The save succeeds and looks identical on screen, but the retro trigger on PA0003 may not fire the same way. Compare the infotype change log against the PA0003 retro date update to confirm whether the trigger actually happened, regardless of which transaction was used.
- Overlapping record instead of delimitation: a new record created without properly delimiting the old one leaves two overlapping time records for the same period. Time evaluation then either errors out or picks the wrong one depending on infotype sequence rules. Check for overlapping validity periods on the same infotype before assuming the correction logic is broken.
- Authorization scoping blocks the correction silently: time administrators are frequently restricted to specific infotypes or personnel areas. A save that appears to do nothing is often an authorization check failing quietly rather than a data problem; check the authorization trace before spending time on the data.
- Retro limit exceeded: if the correction date falls earlier than the configured retroactive calculation limit, the system blocks or truncates the retro trigger. Check the configured limit against the correction date before assuming the transaction itself failed.
Whose problem this is
Functional Time Management issue in almost all cases; ABAP involvement is rare and limited to custom time schemas or custom infotype validations. A clean handover states the personnel number, the infotype and record period corrected, the PA0003 retro date before and after the save, and whether time evaluation has been rerun since. Basis is not involved unless the run itself is failing at the batch job level.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/pt61ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.