Ever since my previous blog post SAP Payroll Year End: Analyzing and Debugging a Reconciliation Issue I have gotten a lot of requests to write another article about SAP Payroll and some of the things that I have dealt with in this area. I recently left my job as a Consultant and accepted a position to join SAP in the Education Department where I will be teaching HCM classes. While I have worked with SAP for many years as a consultant, I was never fortunate enough to attend any formal SAP classes. All of my learning was from other consultants and working directly in client systems. I was skeptical about how much I could learn from the formal SAP classes and how much they would really help someone like me. After being able to attend and start teaching some of these classes I must say that I am extremely impressed with the content that is covered and am sure that if I had been given the opportunity to attend these classes it would have helped me in learning the content at a much quicker pace.

Attending formal SAP training allows you to understand the standard configuration of SAP and it’s capabilities and framework as SAP intended. If more people attended the formal training’s then there would be less unnecessary customization by consultants who are solving a client problem that can be handled by standard SAP and coming up with a custom solution for it because they don’t know about the standard solution. From my time in consulting I can safely say that the clients I worked on with the most issues and ultimately the highest maintenance cost were the ones who had highly customized systems. Many times the customization in the system was unnecessary because standard SAP provided a solution that could be used and supported by SAP. I understand why there is a more stringent certification process with SuccessFactors in order to work with the software.

With all of this being said, make no mistake about it – we are still dealing with complex software tackling complex business processes and and it will absolutely take time and effort in order to learn SAP regardless of the module. Simply attending the class by itself is not enough to become an expert – it still takes a lot of time, effort, and dedication.

After attending/teaching some different SAP Payroll classes (HR400, HR410, & WNA11) I decided to write this blog post detailing one piece of functionality that I had to deal with a lot as a consultant and have also had people ask questions about as an instructor – 401K processing and the retro activity of this functionality and how it truly works in SAP from a technical perspective. Fortunately, this functionality works right out of the box as SAP delivered it, but people are still curious how it works and many times need to explain it to and prove that the numbers in the system are correct.

I wanted to share this knowledge with the community and really explain this functionality with a greater level of detail & to show how impressive this functionality is as built by SAP. Please be warned that this article will get very SAP technical (NOT ABAP programming technical) and does require a understanding of both SAP Payroll & SAP Payroll Schema knowledge in order to grasp the content.

First and foremost to begin the process, an employee enrolls in a 401K Savings Plan during their Benefits Enrollment Elections (New Hire Enrollment, Open Enrollment, Marriage etc). The election data is stored on Infotype 169 – Savings Plan. The employee elects a 401K contribution percentage and whether that percentage is a pre-tax or post tax contribution. You can elect a different percentage for Bonus wage types and regular wage types. As part of the initial configuration, on table V_5UBA_WT you tell the system for the 401K plan, what the technical bases (The amount that the 401K percentage is calculated on) are for regular and bonus. The standard technical base is wage type /102 as delivered by SAP. If I am on a monthly payroll and have a salary amount of $10,000 a month with a 401k pre-tax contribution of 10% then the $10,000 is the technical base and $1,000 is the amount withheld from my check pre-tax and added into my 401K account.

For the setup of the 401k, in each of the wage types that you use to pay your employees, you determine if they should count toward the 401K technical base contributions in the wage type configuration. You set this up on Table T512W of which I use view V_512W_O from SM30. The key piece here is the cumulations section of this table. Since we are using wage type /102 as our technical base we are talking about cumulation 02 and if that box is checked in this view for the respective wage types use in your payroll. Any wage type that DOES count towards your 401K wages should have the box checked. The purpose of this is to clearly differentiate what money that you earn should deduct the 401K and what should not. For example. you would likely not want to deduct 401k from a car allowance, gift card, tuition reimbursement paid to an employee but you WOULD want to deduct it from your salary or any bonus amount. This way, in each payroll period the total amount of the wage types that do count towards 401K are totaled and stored in wage type /102 as the technical base amount used for our calculation.

Once you have this setup for all of your wage types and the employee is enrolled in the plan, standard SAP processing in the Payroll schema will handle determining in each pay period how much of your wages add to become the taxable base and then ultimately how much is withheld from your paycheck.

For a regular period standard rule X023 cumulates to determine your taxable base.

This rule runs for each entry in the IT cluster table and adds to the appropriate cumulations setup that we talked about earlier on V_512W_O. The standard operation ADDCU does a check to see all of the cumulation boxes checked for that wage type and then it adds it from the wage type into each respective cumulation amount.

After this rule runs, you can see the taxable base in /102 in the IT table. In my example below the total gross in /101 happens to be the same as the total 401k wages in /102. Depending upon your configuration this isnt necessarily always the case.

After the taxable base is calculated and stored in /102 in the IT table, the schema uses Function P0169 to determine how much should be deducted from the employees check based upon the Infotype 169 record and the percentage entered & whether or not it is pre-tax/post tax. This includes looking at the standard constant table V_T511P to determine the 401K contribution limits set by the IRS. This amount is typically updated by an SAP Note each year if the amount changes although you can adjust it if you so choose manually by adjusting the value directly on the table and saving it. If you have any customer logic implemented in the form of a BADI then you can call it at this point in the processing. This function also checks your configuration to determine which wage types should be automatically created to store the withheld 401K amounts (Employee and Employer based upon your config). Here is the section of the schema where the function P0169 is called as well as the processing of it.

Here is the output after function P0169 is run and you can see the 401k amount in the IT table which is stored in wage type 2030 in my example which is the EE 401k amount withheld with the. If there is an employer match then the amount in the employer match wage type would not be withheld from the employees check since it is paid by the company on behalf of the employee.

This amount shown in wage type 2030 in my screenshot above for the employee 401K contribution is what is ultimately withheld from the employees check and then placed into their account with the 401K vendor. This amount would be sent to the appropriate vendor (Vanguard, Oppenheimer etc) using third party remittance functionality if you have it implemented. Otherwise, you would have an interface or some method that sends this amount to the vendor.

Now, where things get tricky with the 401K is when you have a retroactive change. A retroactive change is when you make a change to data that is effective in the past. For example, if it is currently 04/2015 but you change someone’s salary on Infotype 8 effective 01/2015 then SAP Payroll needs to go back and recalculate to determine how much the employee should have been paid in each period and adjust the amount in the current pay period. This also affects how much was actually contributed to their 401K and how much should have been contributed.

Understanding retroactive accounting in SAP Payroll is a particularly tough concept and this is especially true with 401K amounts. In order to track any retroactive changes to 401K SAP has created a few additional wage types /X02 (Outflow of /102) and /Z02 (Inflow of /102). The way the system knows that these are related to wage type /102 is because they are listed as Statement wage types in the configuration of /102 and vice versa in table V_512W_O.

For wage type /102 it is also important to note that processing class 83 is set to 5 – Take old base, carry base difference forward. This tells the system to keep the /102 base in the retro period (Ex: Period 01/2015 being run IN period 04/2015), but to pass any difference forward to the current period being run (Period 04/2015 IN period 04/2015). This is checked in a schema rule in the payroll processing which I will show later.

In the Payroll schema, the logic for retroactive changes dealing with 401k happens in the subschema for “Gross Cumulation and Tax Processing” in the section for “Process deductions, benefits and storage”

Within this processing there is a check to see if it is a retro period (IF O), and there is a schema Rule UD31 that creates wage type /X02 based upon wage type /102 from the ORT (Previous Results Table) and the wage type /102 in the current IT table. You can see the check for processing class 83 that I mentioned previously in the form of operation VWTCL 83 within rule UD31.

So for example, if the ORT had a /102 amount of 2858.33 and the IT in has an amount of 2939.58 then the schema rule would do the following calculation (2939.58 – 2858.33 = 81.25) and put that amount that is in the 1st statement wage type from /102 (The 1st statement wage type is determined using operation VALBS=1). My screenshot from earlier shows that the first statement wage type for /102 is wage type /X02. Here is a screenshot showing this logic from the rule above and the result of the calculation in the IT table.

In the next period (If it is period 06/2015 and we have a retro to 01/2015 then the next period I am referring to would be 02/2015) during the retroactive run, in standard rule UD11 wage type /Z02 is created based upon the /X02 from the previous period (LRT). This happens in the following location of the schema.

In this rule, if you had /X02 in the previous period then the logic looks at the 1st statement wage type from /X02 (Which is /102) and then looks at the second statement wage type of /102 (Which is /Z02) and creates this wage type in the IT table based upon the exact amount from /X02 in the previous period. So it is really just copying /X02 from the previous period into /Z02 in the current period. Here is a screenshot showing the example of this processing (I do realize that this last paragraph may have been a little confusing and you may need to read it a few times). Essentially the key thing to understand is that it is copying /X02 from the LRT (Last Results Table) into /Z02 in the IT table.

Next, when you have a /Z02 wage type in a period that is still a retro (02/2015 being run in 06/2015 for example), then in standard rule UD21 the system cumulates this amount to /X02. So /X02 now contains the amount in /Z02 (Which was copied from /X02 in the previous period). So at this point in the processing /X02 and /Z02 have the exact same amount in it in period 02/2015.

Next, just like it did in the first retro period (01/2015) rule UD31 runs again in the next retro period (02/2015) and this rule adds to /X02 based upon the difference from wage type /102 from the ORT (Previous Results Table) and the current IT table /102 amount. So if in period 01/2015 the difference was 81.25 and the difference is the same in period 02/2015 then it would add this amount together for a total of 162.50. At this point in the process /Z02 would now have 81.25 and /X02 would have 162.50 as seen in my screenshot below.

This process would repeat for each period being run.I have included a screenshot of an excel document showing the expecting results in each period of my example at the bottom which hopefully should clarify the expected results.

Once the system gets to the current period being run (06/2015 in my previously mentioned example) then the rule UD21 would cumulate /Z02 to /102 instead of to /X02 as it did earlier. You can see the different behavior than my earlier screenshot of rule UD21 in that it follows the “N” path during the RETRO check instead of the “Y” path that it took earlier.

The purpose of the check using operation RETRO in rule UD21 is so that /Z02 does not cumulate to /102 when there are multiple periods in a single retro. Per my earlier example, if you are running payroll period 06/2015 and it is doing a retro back to period 01/2015 then /Z02 would exist in period 02, 03, 03, 05, & 06 but we would only want it to cumulate to /102 in the current period 06 otherwise the /102 amount would be inflated in previous periods and instead we want to keep the original /102 value and have the system pass the difference from the original run the to the current run forward to the current period so it can be withheld in the check. /X02 will contain the total amount that needs to be passed forward at the end of 05/2015 and this amount will be imported to /Z02 in period 06/2015 which will ultimately cumulate into /102 in 06/2015 so that the system can calculate the correct 401K. So if there was a retroactive change where there was an 81.25 difference in each period (01, 02, 03, 04, & 05) then /Z02 would contain $406.25 by period 06/2015. This amount would then be added in addition to the /102 that was calculated for this period so the extra $406.25 would be included in your technical base of /102.

Here is an illustration of the concept that I am referring to and the impact of each of the 3 key wages types in each of the periods during a retro which follows my previous example of a retro to period 01/2015 in period 06/2015 and the amounts that I have used above.

Another thing worth pointing out that with the standard processing of 401K, if you use different percentages for bonus and regular wage types then the bonus needs to be processed in a separate run in order to work correctly and calculate at the different rate. If you enter your bonus on IT15 and include it in a regular payroll period, then the system will not automatically differentiate the amounts. If you want this to work automatically then it will involve additional setup and customization.

In the process of working through this logic and being able to explain it to others, I gained an understanding a lot respect for the standard SAP rules in place to make 401K work. There is a lot of different logic and it is impressive how this functionality works. The standard logic as delivered by SAP allows a tremendous amount of flexibility and would work correctly even with different retro amounts across multiple pay periods. Hopefully this blog post helps people understand this functionality.

Feel free to leave comments and thoughts in the section below.