Skip to Content

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.

Image 7.png

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.

Image 2.png

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.

Image 1.png

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.

Image 2.png

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.

Image 3.png

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.

Image 4.pngImage 5.png

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.

Image 6.png

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.

Image 1.pngImage 2.png

Image 3.png

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.

Image 4.png

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”

Image 2.png

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.

Image 6.png

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.

Image 8.png

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.

Image 12.png

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.

Image 10.png

Image 9.png

Image 11.png

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.

Image 13.png

Image 1.png

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.

Image 3.png

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.

Image 14.png

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.

Image 5.png

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.

To report this post you need to login first.

20 Comments

You must be Logged on to comment or reply to a post.

  1. Jarret Pazahanick

    Nice job on this blog Imran as 401K, Garnishment and Taxes are the 3 biggest areas that I tend to have to clean up due to poor or inexperienced consulting when it comes to US Payroll.  Good luck in the training career and like you very glad that SuccessFactors has more stringent certification requirements as longer term that will be a good thing for customers.

    (0) 
    1. Imran Sajid Post author

      Thanks a lot Jarret! Yep those areas plus claims processing đŸ™‚ . I appreciate the well wishes. I enjoy teaching SAP so I think it is a good fit!

      (0) 
      1. Sriram Tamil

        Hi Imran,

        Thanks for your great article. i have started to learn payroll, hence i am doing learning one by one. here i just don’t get it the last paragraph. 10% of amount will be deducted from the /101 for the savings plan for the current period ,

        So 2030 wage type will have amount 1000 which is 10% of the amount in /102 – Am i right? this is for the current period which is 02/2015,

        in the period 01/2015 – 2030 WT has value 2000, so /102 has 20000, then i change the basic pay in the period 01/2015 so the value of /102 becomes 30000,

        retro starts for 01/2015 so 2030 will have 3000 now and for the period 02/2015 2030 will have 1000,

        then why do we need a retro, why the amount has to be carry forwarded?

        i just dont get it brother. sorry if i am confusing with my question, extremely apologize for the basic question as well.

        I just dont get the concept.

        Thanks

        Sriram

        (0) 
        1. Imran Sajid Post author

          Hi Sriram,

          Always good to see new people learning SAP & Payroll. The concept to understand is that the change was done retroactively, however you cannot change the amount that was already sent to the 401K vendor in the past (We cannot go back to January and send a new amount from January if it is July). So we need to recalculate what it SHOULD have been in the past (January for example), bring that to the current period (July) and pay it out in the current period so that the total YTD values are correct.

          Best of luck in learning SAP. If you are serious about learning you should consider some of the SAP training classes like HR400 for Payroll. You can find more information at training.sap.com

          Regards,

          Imran

          (0) 
          1. Sriram Tamil

            Hi Imran,

            Thats really great , yes i thought of it.. so the amount suppose to be paid should be paid in the current period with the differences.. yeah i understood that.

            Yes imran i am so keen learning payroll, but how would i register myself for the classes , which one would be preferable to choose. how much does SAP charge for that?

            Thanks

            Sriram

            (0) 
            1. Imran Sajid Post author

              Hi Sriram,

              You can get more information at training.sap.com website including scheduling and pricing. I am not sure your level of experience or location, but the payroll classes are HR400 & HR410 (US Specific). If you are more of a beginner then it is recommended to take HR305 for configuration of master data before the payroll classes. Once you are more advanced then there is also a workshop class WNA11 that goes into great detail on the payroll schema and you get good hands on experience for writing rules. It is a fantastic class for even experienced people.

              Regards,

              Imran

              (0) 
              1. Lena Cromwell

                Hi Imran,

                Your posts were very helpful!!

                I am hoping you can help me understand a little more about the 401K deductions…I have a case where a change in payroll area occurred in the middle of the pay period and 2 checks were created for the same pay date. One for salary (his old payroll area) and one for hourly (his new payroll area). The business expected the 401K deduction to come out on the salary payroll and the new hourly payroll. However the system only took the 401K deduction out for the new hourly payroll area only. Can you explain why the system would not have taken the 401K deduction in both periods (salary and hourly)? I am assuming this is 401K specific because medical and dental deductions occurred. It was just the 401K that did not!

                If anyone else can provide feedback that would be as well!

                Regards,

                (0) 
                1. Imran Sajid Post author

                  Hi Lena,

                  Thanks for taking the time to read and for your comment. You have listed a very specific scenario and quite honestly I do not know why the system would behave this way for you in this situation without either recreating the scenario or looking in the system and taking a look at the Payroll log to see the processing steps. My recommendation would be to have a consultant or IT analyst on your team who is familiar with reading the log take a look and figure out the processing. It may require someone to debug the SAP code if it is not something that is obvious in the log although that could be very time consuming.

                  You can try to create a new SCN thread asking this question, but it is a very specific scenario that I doubt anyone will know off the top of their head unless they have run into this exact scenario previously.

                  Regards,

                  Imran

                  (0) 
  2. Lena Cromwell

    Hi Imran,

    Also I need to clarify the only time the 401K deduction would retro is when there is a change in earnings, correct? That is the only thing that makes sense. If there is a retro change to the percentage, my understanding is that it will not retro, the system will only  process the current percent? What would happen if the most current record was changed by using the pencil, where the percent changed and the record was dated  effective 1/1/2016 already? Would it adjust the deduction amount for past results based on the new percent?

    If anyone else can provide feedback that would be great as well!

    Regards,

    (0) 
    1. Imran Sajid Post author

      Hi Lena,

      That depends upon the configuration of your system and whether the field for a percentage change is setup to trigger a retrocalculation. I believe as delivered by SAP, this field on Infotype 169 is setup to trigger a retro if it is changed in the past.

      My recommendation is to setup this scenario in your testing environment and see what happens.

      Regards,

      Imran

      (0) 
  3. Mohammad Parwez

    Hello Imran,

    Thank you so much for the blog, it is really helpful.

    I am working on one of the retro scenario, where I have given 401K rate as 20% and basic salary 20000$ for a EE whose age is more than 50years, after 5 PP system is deducting the amount perfectly and stored in pre tax WT (ex 818E= $18000 as per the IRS limit) and $2000 in catch up wage type.

    but when I am changing the basic pay retrospectively from PP01 and made it to $15000 so in PP 06, the changed  /102 will be $90000(compare to last /102 till PP05 was $100000)

    so that will have difference of $2000 which will be refunded. So this $2000 deduction should be from catch up WT first then pre tax WT, but in my case in is deducting from pre tax?

    Could you please help to fix it…what could be the issue?

    Thanks in advance!!!

    Best Regards,
    Parwez

    (0) 

Leave a Reply