SAP Payroll Year End: Analyzing and Debugging a Reconciliation Issue

[ImranSajid]

I have worked with SAP Payroll for many years across a dozen different clients, and you can always count on issues at the beginning of the year due to year-end. It could be a number of things such as printing W2s, preparing to send 941's, or other error's with particular employee data, and there are a variety of reasons for these issues including the following:

• SAP Changes via HRSP's
• Non-Implemented OSS Notes
• Bad Employee Data/User error

This year, I ran into a issue with one of my clients in regards to their W2 Summary report from Tax Reporter not matching the Payroll Reconciliation report for two particular states and their Withholding Taxable Bases (/701) and wanted to share my experiences with this. I always receive requests to talk about SAP Payroll from colleagues and thought that this might be a good one to share since it is that time of year where everyone is going through this. In this scenario, the client wanted an explanation on why it does not match, and like just about everything else dealing with Payroll it was an urgent issue that needed to be dealt with yesterday.

At first glance, dealing with these type of issues is overwhelming because it seems like you are looking for a needle in a haystack and sometimes that is exactly what you are looking for. My first step to resolving these issues is to always recreate the error, so in this case I was looking at the Payroll Reconciliation Report (PC00_M10_REC) as well as Tax Reporter for the W2 (PU19) Summary and directly compainge them to understand the amount of the imbalances. I typically ask the client to send me a screenshot of the selection screen for how they are running each of these and then run it myself. This will help me rule out silly mistakes like bad data entered on the selection screen, and also to make sure I am comparing apples to apples.

So I ran the Recon Report as instructed with one of the key's being setting the ALV Layout to 1_TOTALVIEW in order to get a high level overview. Here was the results.

Next, I ran tax reporter like this in order to see the W2 Summary

This gave me the following result on the PDF output for the incorrect state.

So the discrepancy was 7,213,542.72 - 7,193,708.14 = 19,834.58 which is a significant discrepancy. In order to dig further into this, I needed to look at the employee level. So I adjusted multiple fields on the Payroll Reconciliation selection screen including the following:

1. Add Personnel Number to the reportable fields by clicking the tab and adding it
2. Changing the ALV Layout to the detailed EE view
3. Limiting what is pulled back to reduce the report run time
   1. Adjusting the wage type selection to only pull back the wage type I am interested in (/701)
   2. Adjusting the tax authority to only the one I am interested in

Once I ran the report and it finally outputted, I looked into and tried to see anything that stuck out with individual employee's. What I found in this particular scenario was that there were many employees that had a "Retro Period Adjustment" that included retro's from 2013 that occurred in 2014. I also saw that they already had a retro in 2015 that went back to 2014 that was also causing a discrepancy. As a result, the system adjusted the /701 and this was not reflected in Tax reporter for the W2 as they were expecting, although it was included in the Payroll Recon report.

In order to "prove" this to my client on how the system was behaving, I did a proof of concept by testing and showing this one one particular associate by comparing tax results in transaction PC_PAYRESULT.

Original Period 52/2014 - TCRT value

Period 52/2014 in 01/2015 - TCRT value

As you can see, the taxable base was decreased by $0.32 with the retro. Now, I ran the W2 for this associate via PU19 in test mode and saw that the amount in the W2 still reflected the original amount instead of the new amount because I was using consider payroll results up to 12/31/2014.

Had I used a date such as 01/15/2015 which included period 01/2015 then it would pull in the new amounts which I also ran and you can see here.

Many times with Payroll issues it is more about proving that something is correct or proving how the system is behaving and that is what I found to be the case here. We can easily include the new year amounts that contain a retro by adjusting the date on the selection screen in Tax Reporter. In order to "prove" that there was nothing off with the payroll data and that the Payroll Reconciliation Report did match I advised the client to the do the following:

• Download to Excel sheet from the Pay Recon report using layout 1_Detail
• Filter the appropriate Tax Authority for WT /701 (If it was not already filtered on the selection screen)
• For Normal Period Results, remove rows with check date in 2015:
• For Retro Period Adjustments, remove rows where the period is For 2013

After these rows are removed, the total amounts matched the W-2 Summary exactly as they were expecting. I also let the client know that they always have the option of adjusting individuals via the Year-End workbench and using IT221 YANA entries on 12/31/2014 if that is what they wanted to do and I could help them as necessary.

One other consideration if you are dealing with an issue with Tax Reporter and an imbalance, be sure to check out the Tax Reporter log for rejected employees - I saw a separate issue with a different Tax Company for this same client where one employee had a negative balance in a field that they should not (Due to GTL and being on leave for most of 2014) and as a result Tax Reporter excluded this employee in the totals which cause the numbers to be off. In this case, you can either do an IT221 entry or a manual entry directly in tax reporter to clear the balance and allow them to get picked up in the production run of Tax Reporter. I opted for the manual entry directly in tax reporter because the wage types to be adjusted were not currently in the permissibility table for Infotype 221, so as small configuration change would be required which would cause a further delay in processing.

Overall, the big lesson learned for this client was that you have to be careful with retro-calculations across years and understanding the impact of these retro-calculations and how the system treats them. I have seen issues with this same concept in the past, with one of my clients coming to me with an issue due to someone who had a retro back 10 years causing a big issue. Unless you have a very strong payroll team who understand the impact and implications of retro calculations, a good rule of thumb is to not allow prior year retro's and you should change the "Earliest retro acctg period" in the control record at the beginning of each year unless it is absolutely necessary and if you know what you are doing.