I provide a detailed look at the standard SAP processes and how to proceed when you find out that you need to reverse a payroll run. The method used differs greatly depending on where—at which step of the process—you are. Understanding this information helps you make the correct decision on how you should reverse a payroll run.
There are two concepts that must be understood when making corrections in the SAP Payroll module. A payroll reversal is the process of reversing a payroll run that was created in the SAP system. An out-of-sequence reversal process is a payroll reversal in which a payment has already been made to a third party or it is not the most recent payroll run. To understand this article, readers need to have a good grasp of complex SAP Payroll concepts; in other words, this article is not intended for beginners just learning about SAP Payroll.
For more information about this topic I recommend attending the SAP workshop class WNAOC, which offers a deeper look at the entire functionality of the off-cycle workbench, including payroll reversals. The SAP payroll class should be taken based on your country. For the U.S., that would be the HR410 – U.S. Payroll class; for Canada, the appropriate class is HR407. For information about classes for other countries or for more information about any other SAP classes, visit this website: https://www.sap.com/training-certification.html/.
Understanding the Payroll Reversal Options
The first step for understanding this functionality and the options that you have for the reversal or voiding of a payroll is to determine where you are in the overall payroll process flow. Where you are in the process has a huge impact on what choices you have for correcting the data in the system. To determine the best option for correcting payments, you need to ask the following questions to see what can be done:
- Has the payroll control record been exited?
- Has payroll posting already been run and posted to finance (FI)?
- Has third-party remittance already been run?
- Are you reversing the most recent payroll run or a previous one?
Determine If a Payroll Reversal Is Required
The first question is important to determine whether you need to go through the formal process for a payroll reversal. If payroll has not been exited, then you have two choices:
- Delete the payroll results.
- Correct and re-run the payroll. If you choose this second option, then you do the following, in order:
- Change the control record to Released for correction status
- Update the master data to fix the issue
- Change the control record back to Released for payroll
- Re-run payroll
It is safe to assume that if you have not exited the payroll control record, then you have not run payroll posting or third-party remittance since the SAP system does not let you do a production run of those processes until the control record is in exited status.
The decision about whether you want to delete the payroll results or correct and re-run the payroll is based on why you want to reverse the payroll that was already run. If you need to correct the results, SAP recommends that the payroll be corrected and re-run. For example, if you meant to include a salary increase, but did not update the master data before payroll was run, you need to:
- Change the control record to Released for correction status
- Update infotype 8 to give the employee the increase in pay
- Change the control record to Released for payroll status
- Re-run the payroll
These steps update your results and everything should then be correct.
You would only want to delete the results if they never should have existed. For example, if you meant to terminate an employee, but did not do the termination action before payroll was run, then the way to correct this is to do the following:
- Delete the payroll results
- Change the control record status to Released for correction
- Run the termination action
- Change the control record back to Released for payroll
At this point, even if you re-run payroll, this employee should not be picked up since the person would be terminated.
To delete payroll results, execute transaction code PU01. For the purposes of this article, I walk you through this process as it is something that many people are not familiar with; however, I do not walk through the process of correcting and re-running a payroll as most payroll administrators should be familiar with this process.
Deleting payroll results can only be done on one employee at a time. To begin, execute transaction code PU01 and enter the personnel number for the employee for whom you want to delete the results, as shown in Figure 1.
Enter the personnel number for the payroll results to be deleted
After you enter the number, click the execute icon to review the results you want to delete in the next screen (Figure 2). Select the row with the employee’s personnel number and click the Delete button.
Delete the payroll results in transaction code PU01
A pop-up screen opens asking you to confirm that you want to delete the results (Figure 3). Click the Yes button.
Confirm that you want to delete the payroll results in transaction code PU01
A screen like the one in Figure 4 opens, telling you that the results were deleted successfully.
The screen showing that that the payroll records have been successfully deleted
However, what do you do if the payroll has already been exited? What are your options? At this point, you have three possible scenarios that determine how to handle this issue. I walk through each one.
Here is a summary of the three potential scenarios:
- Payroll is exited, but neither posting nor third-party remittance has been run.
- Payroll is exited and the posting run is completed, but third-party remittance has not been run.
- Payroll is exited, the posting run is completed, and third-party remittance has been run, or you are reversing a payroll in the past (e.g., the most recent payroll run is not being reversed, but an earlier one).
For the third scenario it is assumed that for any payroll that is not the most recent payroll run, FI and third-party remittance (also called 3PR) have been run since you should run posting and third-party remittance on any past payrolls before proceeding with the current period.
For the first scenario in which payroll has been exited but neither posting nor third-party remittance has been run, you use the off-cycle workbench and the reverse-payment functionality.
Execute transaction code PUOC_10 and select the Reverse Payment tab (Figure 5). Then select the payment that is to be reversed (in this case, check number 0000000000402) and the reason for the reversal (in this case, Stolen).
Reverse the payment using the off-cycle workbench
After you click the Reverse button, a pop-up screen appears with a message letting you know that a void cannot be undone and asking you if you want to proceed (Figure 6). Click the Yes button.
Payroll reversal void confirmation message
Back in the off-cycle workbench, go to the History tab (Figure 7) and verify that the void was completed by checking that the indicator in the Canceled field is selected.
The off-cycle workbench History tab showing the reversed payroll
Once you’ve confirmed that the payroll has been reversed, it can be verified on the FI side by executing transaction code FCHN and looking for payroll checks (Figure 8). You do this by entering data about the payment, such as which company code made the payment, selecting the Payroll checks check box, and clicking the execute icon.
Verify that the payroll has been reversed in FI
Once you find the check number that matches the payment that was reversed (in this case, check number 0000000000402, shown in Figure 7), you can look at the details of the voided check on the FI side by clicking it. You should see all the relevant information for the voided check as shown in Figure 9.
The details for the voided check
At this point, this concludes the reversal process since there is nothing to be done for payroll posting or third-party remittance in this scenario. The payroll check has been voided, and all the posted results and the amount remitted to vendors are corrected.
For the second scenario (payroll is exited, the posting run is complete, but third-party remittance has not been run), you follow the same exact process for reversing the payroll as shown above, but with one additional step.
For the purposes of this scenario, I assume that the original posting has already been run and posted. Figure 10 shows the details of the original posting run for the example employee. This can be compared to the reversal posting once it’s been run.
The posted payroll results for comparison
After you reverse the payroll results (following the same steps as for the first scenario), you need to reverse the results posted to FI for this one employee. Note that although it is possible to reverse the entire payroll posting document, you would never want to reverse the entire document just because one employee requires a reversed payroll. However, if there is a significant error and you need to reverse an entire payroll document, you can do so in transaction code PCP0 (Figure 11). First, select the document to be reversed. Then click Edit, and select Reversal and Reverse documents, as shown in the figure.
Reverse an entire payroll document
For almost all payroll reversals you need to create new offsetting documents with the reversed amounts for only those employees for which the payroll has been reversed. To reverse the posting results of a voided payroll, execute transaction code PUOCBA (Subsequent Processes of Off-Cycle Activities), and a screen like the one shown in Figure 12 opens. Select the Reversal radio button, enter a Process Model (SAPUSOCV is the standard one, but your company may have a custom version), and enter the Personnel Number for the employee whose payment is being reversed.
Enter the details in transaction code PUOCBA for the payroll reversal
Click the execute icon and the system looks for payroll runs that have been marked as reversed. Once found, they’re shown in an output screen (Figure 13). In the background the system has executed a process model that executes the payroll posting program PC00_M99_CIPE for you.
Output screen for transaction code PUOCBA with the reversed payroll runs
Next, execute transaction code PUOCLG to see which off-cycle payroll runs need subsequent processing, and the statuses of these runs (Figure 14). Make the entries as shown in the figure to identify payroll run results that need subsequent processing.
Execute transaction code PUOCLG to find payroll run results that require processing
It is worth noting that you can execute transaction code PUOCLG to identify any runs that need subsequent processing before you execute transaction code PUOCBA. Transaction code PUOCLG shows all the existing off-cycle payroll runs. Once it is executed, you can look at the details to see which ones have been processed and which ones have not. It can be used as an audit tool to verify before and after a reversal is run to make sure that it is processed correctly. For the runs that have been completed, once you execute the program, the status (Stat…) indicator should change to green and the Proc.date field should contain the date when you ran transaction code PUOCBA earlier (Figure 15).
The output screen of runs that need subsequent processing
Next, execute transaction code PCP0 and verify that a new payroll posting run was created based on the execution of transaction code PUOCBA from the process model. In the screen that opens (not shown) click the payroll posting run to see the details of the posting information, displayed in Figure 16.
Verify the details for the reversal posting run
When you compare the original run to the new run, you see that all the amounts are reversed for the Credit Amount and Debit Amount. Figure 17 shows a comparison of both posting runs.
A comparison of the original (top) and the reversal (bottom) posting runs
(Note: In my example posting runs, the amounts are exact because only one employee’s results are posted. However, in a full production run, the original posting run has values for multiple employees and the reversal only has the amounts for the reversed employee, so it would not be as cleanly reconciled as in this example.)
The third scenario (payroll is exited, the posting run is completed, and third-party remittance has been run, or you are reversing a payroll in the past [i.e., the most recent payroll run is not being reversed]) is the most complex type of reversal—an out-of-sequence reversal.
Once you run a third-party remittance on a payroll that means that the vendors have been paid. At that point, any payroll reversal is considered an out-of-sequence reversal. This is also true if it is not the most recent payroll result that is being reversed. The path that leads to an out-of-sequence reversal is shown in Figure 18 from the SAP website for Payroll Reversal. For the purposes of this scenario, I assume that the following processes have been completed: payroll, posting, pre-data medium exchange, data medium exchange, and third-party remittance.
The process leading to an out-of-sequence payroll run reversal
The first step for an out-of-sequence reversal is the same as the void step I showed how to do in the first scenario. Starting at the off-cycle workbench (transaction code PUOC_10), select the payroll you want to reverse, give a reversal reason, and click the Reverse button.
This time, however, since third-party remittance has already been run, you get a pop-up warning message that says An ‘out-of-sequence-reversal’ is carried out (Figure 19). It asks if you want to proceed.
Off-cycle workbench message warning of an out-of-sequence reversal
Click the Yes button and then, in the History tab of the off-cycle workbench, check to make sure the payment has been reversed (Figure 20). The previous payroll that you cancelled earlier is also shown as well.
Payment history showing the reversed payroll run results
It is worth noting that, in the payroll results in transaction code pc_payresult (Figure 21), when you look at this payroll you see an R in the Reversed field for the out-of-sequence reversal. However, for the previous reversed payroll, it shows a V (for voided) in the Reversed field. This is because the 01/15/2015 payment reversal was a void (e.g., the most recent payroll and third-party remittance had not yet been run) and the 02/15/2015 payment reversal was an out-of-sequence reversal, as shown in Figure 21.
Now that you understand the first step of processing an out-of-sequence reversal, it is important to understand its effect on the system and what occurs behind the scenes when this process is happening. I can’t say it any better than SAP does, so I’ve shown the definition as stated by SAP in Figure 22.
SAP documentation about an out-of-sequence reversal
The documentation in Figure 22 (item 4) gives two possible options for fixing the payroll results when you run an out-of-sequence reversal.
- If the employee is to receive a payment immediately, carry out a correction payroll run in the Off-Cycle Workbench.
- If you do not execute a correction payroll run in the Off-Cycle Workbench, the system automatically carries out retroactive payroll when the next regular payroll run takes place.
(Note: For more details about the effects of an out-of-sequence payroll reversal, follow this link to SAP documentation. This documentation contains more technical information regarding what occurs behind the scenes when an out-of-sequence reversal is run.)
Now that the payroll has been reversed, you need to do the next step of the payroll process. For the purposes of this article, I demonstrate an out-of-sequence payroll reversal using the first of the two options listed above—carrying out a correction payroll run in the off-cycle workbench. For the second option listed above, you do not need to do anything else at this point. The system automatically does a retro calculation in the next scheduled payroll run, and then the reversal is included with the normal payroll posting and third-party remittance for the following period.
Running a Payroll Correction in the Off-Cycle Workbench
The first step for a correction payroll run is to update the affected master data. For my example, I use an employee who never should have had the payroll run (i.e., a terminated employee) and I need to correct the payroll by terminating him. The period for the payroll that is to be reversed is 02/01/2015–02/15/2015. In this case, I terminate him effective 01/31/2015 to tell the system that he should not have been paid for that period.
I do not go into the details for how to do this, but, in brief, go to transaction code PA40 and use the termination action to tell the system the employee should be terminated, with an effective date of 01/31/2015 (Figure 23).
A termination action
After completing the termination action, you need to process a correction run of the payroll. The correction run is something that needs to be done for employees one at a time, and it is done via the off-cycle workbench (or via transaction PUOC_10). In this example, execute transaction code PUOC_10 and select the Payroll tab (Figure 24). Select CORR Correction as the Reason and enter a payment date that is after the end date of the previous run. Since the previous run ended on 02/15/2015, you can use the next day or 02/16/2015 as your date. Then click the Start Payroll button.
Run the off-cycle workbench correction
Once the correction payroll has been run, click the Save button and then you can proceed with the post-payroll processing steps. I do not go into the details for this process here, but I do want to point out that when you run the payroll posting program, you must specify the Run Attributes for the off-cycle payroll run (Figure 25). Enter B (the code for a correction run) in the first Off-Cycle Payroll Run field, 0 in the second field (if there are multiple runs on the same date they would be sequenced), and the pay date (02/16/2015) in the last field. Once you make these entries, click the execute icon.
The selection screen with the required off-cycle run attributes
Once the posting program is executed, the system creates a posting document with the appropriate amounts (Figure 26). In this case, you see that the company is getting a credit for the salary and payroll taxes that offsets the previous posting run (shown in Figure 10) that had these as debit amounts.
Payroll correction posting details
Figure 27 shows a direct comparison of the original run amounts with the correction run amounts—note the reversed amounts in the Credit Amount and Debit Amount.
Payroll correction (bottom) posting versus original run (top)
(Note: Again, in this example, the amounts are exact because only one employee is posted in the original run. However, in a full production run the original posting run has values for multiple employees and the reversal only has the amounts for the reversed employee so it will not be as cleanly reconciled as in this example, but you should be able to reconcile the amounts.)
Next, you need to run the normal third-party remittance process. I do not go into the details for this process here. However, you do need to specify the off-cycle payroll information in transaction code PC00_MRR_URME exactly as you did when you did the posting run (Figure 28).
The selection screen with the correction payroll run details
Once the normal third-party remittance process has been executed, the system creates the third-party documents with the amounts reversed as compared to the original run amounts, as shown in Figure 29.
Payroll correction third-party remittance
Figure 30 shows a comparison between the original and the correction runs. Notice that the Credit Amount and Debit Amount are reversed, indicating that the system knows that the previous amounts need to be reversed and the tax payments credited.
Payroll correction third-party remittance (bottom) versus the original run (top)