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.

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:

1. Has the payroll control record been exited?
2. Has payroll posting already been run and posted to finance (FI)?
3. Has third-party remittance already been run?
4. 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:

1. Delete the payroll results.
2. 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. After you enter the number, click the execute icon , which opens the screen in Figure 2. Here you can review the results you want to delete. Select the row with the employee’s personnel number and click the Delete button.

Figure 1

Enter the personnel number for the payroll results to be deleted

Figure 2

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.

Figure 3

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.

Figure 4

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:

1. Payroll is exited, but neither posting nor third-party remittance has been run.
2. Payroll is exited and the posting run is completed, but third-party remittance has not been run.
3. 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.

Scenario 1

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).

Figure 5

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.

Figure 6

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.

Figure 7

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.

Figure 8

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.

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.

Scenario 2

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.

Figure 10

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.

Figure 11

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.

Figure 12

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.

Figure 13

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.

Figure 14

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).

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.

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.

Figure 17

A comparison of the original (top) and the reversal (bottom) posting runs

Scenario 3

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.

Figure 18

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.

Figure 19

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.

Figure 20

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.

Figure 21

Payroll results

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.

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.

1. If the employee is to receive a payment immediately, carry out a correction payroll run in the Off-Cycle Workbench.
2. 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.

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).

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.

Figure 24

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.

Figure 25

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.

Figure 26

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.

Figure 27

Payroll correction (bottom) posting versus original run (top)

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).

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.

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.

Figure 30

Payroll correction third-party remittance (bottom) versus the original run (top)

Imran Sajid

Imran Sajid is a Senior Education Consultant at SAP based in the Atlanta, GA, area. At SAP, he focuses on teaching classes in the HCM area within both SAP and SuccessFactors. Previously, Imran was a consultant who implemented and provided post-go-live support for more than a dozen different client systems spanning many industries, including manufacturing, automotive, retail, information systems, the public sector, and energy. He is the author of the book entitled, The Payroll Control Center for SAP ERP HCM and SAP SuccessFactors, as well as a frequent contributor to SAP Experts, where he has published almost a dozen articles. Imran is also frequent blogger on SAP Community Network (SCN). He graduated from the Georgia State University Robinson College of Business with a degree in Computer Information Systems. Imran can be found on Twitter @ImranSajidSAP.

You may contact the author at Imran.Sajid@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.