Combine SAP’s Wage Type Reporter with Excel to Increase Payroll Testing Effectiveness

  • by Brian Harty, SAP HR Consultant, BearingPoint
  • December 15, 2006
Create an Excel spreadsheet to view and compare payroll result differences after every configuration change to minimize errors.
Key Concept

Parallel testing is one of the most effective ways to test configuration and rules prior to a payroll go-live. Parallel testing is the phase in an SAP implementation in which HR professionals compare the payroll results from the legacy system to what they’ve configured in SAP. It is usually the last phase of an implementation before converting the data to production. In my experience, it is the most effective testing that you can perform to test the accuracy of pay results. There is no substitute for comparing employees’ payroll data and being able to match gross and net pay.

When making a configuration change in your live SAP Payroll system, it’s a good idea to confirm that this modification will not adversely affect your payroll results. You might need to make configuration changes such as updating pay scale groups or levels, adding a new medical plan, or changing an employer contribution on a deferred compensation plan.

A good way to test that your changes don’t affect other areas is regression testing. Regression testing is a quality control measure to validate that a configuration fix does not negatively affect unmodified configuration. You can set up a variant in Wage Type Reporter (transaction PC00_M99_CWTR) and use an automated comparison tool such as Excel to view results and assess the effect of each configuration change on your live system.

You also can apply regression testing to make sure your system goes live without running into headaches. No matter how thoroughly you progress through the phases of an SAP implementation (blueprinting, unit testing, integration testing), it is likely that you will discover errors or new requirements during parallel testing that require configuration or rule changes. Unfortunately, it’s risky to make changes to fix errors discovered during parallel testing. Although you may fix the known error or satisfy the new requirement, you must confirm that the fix does not cause other errors.

Brian Harty

Brian Harty has more than six years of experience in the IT industry, with a primary focus in SAP HR implementations. His main areas of interest are Benefits and Payroll. He is currently a senior consultant with BearingPoint.

See more by this author


No comments have been submitted on this article. 

Please log in to post a comment.

To learn more about subscription access to premium content, click here.