If you build a new payroll system, you need to verify that it can replicate the results of the legacy system. You can do so with a payroll parallel run. A key activity in a parallel run is the comparison of equivalent sets of payroll results from the legacy system and the new SAP payroll system. Following are different methods of extracting, comparing, and displaying this data to identify and resolve any differences and discrepancies as quickly and effectively as possible.

Extracting Payroll Results from the SAP System

Getting payroll results from the SAP system should be a straightforward process. There are several options available for doing this, which I discuss below.

Extracting Payroll Results from SAP with the Wage Type Reporter

The easiest method is to use the wage type reporter (transaction code PC00_M99_CWTR) to produce a wage type listing. This report has many selection and output options. By spending some time fine-tuning this listing at the outset it is possible to set up a concise variant that displays one row for each wage type that appears in the employee’s payroll results (Figure 1).

Figure 1

The wage type reporter produces a wage type listing for comparison

Extracting Payroll Results from the SAP System with a Custom Payroll Report

Another option is to write a custom report to extract payroll results from the payroll clusters. A report can be written to select employees based on payroll area and period, combined with some basic personnel data (e.g., name, employee type and subtype, and personnel area) and with payroll results from the payroll clusters, and then display these using the ABAP list viewer. A competent ABAP programmer should be able to create such a report in a few days or less. The advantage of writing your own data-extraction routine is that you have more flexibility to add any of your own requirements with regards to employee or wage type mapping and any totals, counting, or formatting options.

Extracting Payroll Results from the SAP System with SAP HANA and Declustered Payroll Results Tables

The method for storing payroll results in the SAP system is currently undergoing a fundamental revision with the introduction of SAP HANA. With SAP HANA as the underlying database technology, the payroll results currently stored using more complex cluster-based storage methods can be moved to transparent database tables. At that point any payroll reports that extract bulk payroll results should run much more efficiently and quickly (e.g., a thousand times faster than they do currently). In fact, writing any custom payroll reports with additional functionality becomes easier because you can use query views based on the virtual data model. More details about how to do this can be found by following this link: https://scn.sap.com/community/erp/hcm/blog/2013/12/19/how-do-sap-hcm-customers-benefit-from-declustering-payroll-and-time-management-on-sap-hana.

Obtaining Payroll Results from the Legacy Payroll System

Often, extracting payroll results for comparison from the legacy payroll systems can provide a challenge. The legacy payroll system may have more limited functionality than the SAP payroll (otherwise why change?) making some types of comparison impossible. For example, a legacy payroll system might not store the equivalent to technical cumulation wage types (e.g., wage type /121 taxable pay, which stores a total value for all taxable elements), thereby making detailed tax comparisons more difficult. On some legacy payroll systems a flexible reporting tool equivalent to the wage type reporter may be available. If this is not the case then, budget permitting, you may be able to request the creation of a custom payroll results extract report on the legacy system. However, from experience I have found that often there is a reluctance to invest in a soon-to-be redundant payroll system. Consequently it may come down to seeing what standard payroll reports are already available on the legacy payroll system and choosing the best option.

General Considerations for a Results-Comparison Utility

A tool or utility program is required to carry out the comparison between the payroll results for the legacy system and the new SAP system. The results-comparison tool should compare the payroll results between the two systems for each employee and be able to identify and produce reports on:

• Non-matching employees, where difference in net pay falls outside the agreed tolerance
• Matching employees where the difference in net pay falls inside the agreed tolerance
• Missing employees where a matching SAP system or legacy employee can’t be found

To carry out a wage-type-by-wage-type comparison, the legacy system pay codes need to be mapped to their equivalent SAP system wage type. In some cases, a one-to-many mapping function is needed. For example, a situation where a generic legacy pension contribution code may map to multiple SAP system pension-plan specific wage types. In other cases, there may be situations where the plus (+) or minus (–) sign of a wage type needs to be reversed before corresponding amounts can be compared. For example, deduction wage types may be stored with a minus sign on the SAP system and a plus sign on the legacy system.

Employees are often migrated to a new SAP ERP HCM or payroll system with a new employee number. If this is the case, then an employee number mapping function is essential.

Performance is also a key consideration. The datasets can be large, and the comparison may need to be repeated many times a day during the parallel runs as each configuration error is resolved. Each comparison should take minutes or seconds, but not hours.

Given all these considerations, common options chosen are to use Excel with formulas, Excel with Visual Basic for Applications (VBAs), a custom standalone database utility, or a custom ABAP utility within SAP itself. The following sections give more details about these different options.

A Spreadsheet-Based Payroll Results Comparison

It is technically possible to carry out a comparison of the two sets of payroll results using Excel formulas with no additional coding. The Excel functions VLOOKUP, COUNTIF, and INDEX can provide a lot of the required comparison and totaling functionality. However, for large numbers of employees, the responsiveness of the Excel formulas declines significantly and the worksheets can start to freeze because there is too much data. If multiple look-ups are involved simultaneously (e.g., mapping old to new employee numbers and legacy wage types to SAP wage types) then the formulas can become complex and cumbersome. Additionally it can also become time consuming to re-apply the same set of formulas to a new Workbook for each iteration of the parallel run.

A Payroll Results Comparison Database with VBAs

It’s possible to create a more functional Microsoft Excel Workbook with a simple VBA program that compares two sets of payroll results, and creates a new spreadsheet that highlights and identifies all the differences. I documented a simple version of how to do this in a previous article, “How to Compare Payroll Results Before and After a Major Schema Change.”

This approach has worked well for me in the past for comparing payroll implementations of up to around 10,000 employees. I added extra code to add colors to highlight different types of variances, which makes it easier to spot patterns in the comparisons. With regards to performance, I think that this would struggle with a larger parallel run with tens or hundreds of thousands of employees.

A Custom Payroll Results Comparison Database

It’s possible to create a custom database utility for comparing results such as Microsoft Access, or the open-source OpenOffice Base. This would need something in the order of three to five days to configure with a competent database developer. Once built, the utility should be re-usable on other payroll implementation projects, though some adjustments normally would be required.

A Custom ABAP Payroll Results Comparison Program

It’s possible to build a comparison utility within the SAP system itself, provided that a competent ABAP resource is available and can be included in the project costs. This approach makes extracting the SAP payroll results very straightforward—the starting point is exactly the same as the custom payroll report to extract payroll results that I outlined above. The legacy system results need to be loaded into custom tables similar to standard SAP table T558A (Old Payroll Account Transfer). Then appropriate mapping and comparison logic can be built in. Although it may appear to be a big investment for a utility that is initially only going to be used for a limited number of weeks in one phase of the project, such a program can likely also be used as a variance monitor tool after go-live. After go-live this program will enable the payroll team to compare results within the SAP system before and after major configuration changes, support packs, enhancement packs, and upgrades. Some SAP partners have developed products that can be bought off the shelf to meet this requirement. With the advent of SAP HANA and declustered payroll results, this may soon become the preferred option.

Employee and Wage Type Sample Size

Not all the employees or all the wage types necessarily have to be compared—in some cases only a subset of each is necessary. Depending on the complexity of the payroll and the headcount, a choice can be made about whether to compare all employees or only a subset of the employees in parallel run. I’d recommend that the full set of employees be included in all parallel runs. This ensures the widest possible coverage in terms of wage types and payroll scenarios tested. However, if there are time constraints, the alternative is to test only a subset of employees, either chosen at random or based on predefined scenarios (e.g., hiring, unpaid leave, or mid-month transfer) as determined by the company’s requirements. This is a potentially riskier approach, and may impact the success criteria of the first live run and the severity and number of faults raised after go-live.

There are a wide range of options with regards to which wage types are included in the comparison. The natural starting point is to compare gross and net pay for each employee to give an initial idea of matching employees. An example of an Excel-based VBA comparison spreadsheet is shown in Figure 2.

Figure 2

A side-by-side payroll results comparison in Excel

Net pay amounts are compared by setting a filter on column E (WT– wage type) so that only the chosen net pay wage type (in this case /560 Amount paid ) is shown for all employees. The SAP system amount is shown in column G (SAP Amount), next to the legacy amount in column H (Legacy Amount). Any difference is calculated in column I (Difference). The VBA routine is used to color code the cells according to the magnitude of difference. The Key to the different colors is given in the top row: Green is for an Exact Match, yellow is for a one pence (or a one cent) rounding difference, light blue is for a 21 pence (or 21 cents) target tolerance, and red is for any difference greater than one pound sterling (one dollar).

Changing the filter value in the WT column allows for easy identification of errors by wage type. Further comparisons can then be made for each employee by increasing the number of wage types compared to include some or all of the individual payment and deduction wage types. Key wage types for tax, national insurance, Social Security contributions, pension contributions, and benefits should also be compared. Alternatively, cumulation wage types such as total gross, taxable pay, or pensionable pay can be compared as a method of quickly narrowing down the principal category to which any difference belongs. I’ve had good results with this method, particularly where color is added to highlight differences. Although simple, such a spreadsheet utility makes it possible to systematically identify and resolve configuration and data migration errors. Any remaining issues need to be referred back to the business payroll team for full investigation and explanation.

Owen McGivney

Owen McGivney is a senior consultant at iProCon Ltd., part of the iProCon group, based in London, England. He has worked on implementing SAP HR and payroll systems since 1998. Owen has delivered UK, Irish, and multi-national payroll solutions for a wide range of private- and public-sector clients. He has a special interest in combining ABAP programming with configuration to create innovative and effective solutions.

You may contact the author at o.mcgivney@iprocon.com.

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