Back in 2003 for the inaugural issue of HR Expert I wrote an article about seven ways that SAP Payroll implementations go wrong. It's been a long time since then, and SAP Payroll implementations are still going wrong. The software has changed, and I've learned more. So here's an updated version of that first article.
Some of the items in that first article are still issues. Incomplete paystubs are still an issue, as are schema and rule configuration errors. Payroll reporting is still an issue and testing is still short-changed. But let's take a look at seven of the more contemporary issues that keep coming up in SAP Payroll projects. And even if you have already implemented SAP Payroll, these might apply to you. It's never too late to improve your SAP Payroll implementation.
Payroll Control Center
SAP's Payroll Control Center (PCC) is a great feature that helps automate the payroll process. Before PCC we used the HR Process Workbench, also called 'Process Models', to automate the payroll process. That technology is still good and useful, but PCC takes the concept further by using a Fiori-enabled user interface and enabling data validations. For example, you can setup alerts to let you know when an employee's gross pay changes more than a certain amount or percentage, when their net pay is zero or over a certain amount and so on. The validations are flexible and each customer can create their own as needed. Rejects in the payroll process are highlighted and can be assigned to people for correction.
There are good resources available to explain more about PCC so I won't go into the details here. Check out the online SAP library at help.sap.com, blogs.sap.com and Imran Sajid's book from SAP Press. The bottom line is that PCC takes some effort to setup, but it returns a lot of value for new and existing SAP Payroll implementations.
Flexible Reporting
Reporting has been a weakness in SAP Payroll for a long time. The standard reports such as Wagetype Reporter satisfy only a fraction of the needs of any payroll department. Many companies make up for those unmet needs by creating custom ABAP reports or downloading data to the workstations and enhancing it via MS Excel of MS Access. That does allow some flexibility, but it also incurs a lot of work for users. Spreading payroll data around on a lot of workstations also has some risk due to the privacy concerns.
SAP Payroll data can be fed to other SAP platforms such as Business Warehouse, Business Objects and HANA, and from there merged with other HR and enterprise data to solve many payroll reporting needs. That approach isn't used often because of timing (daily feeds vs real-time) and data privacy (no one should see your net pay or garnishments, for example). Timing and data privacy can be addressed but many companies choose not to invest resources in that. In most cases a better solution for flexible reporting is a third-party add-on reporting tool that accesses SAP Payroll and HR data in real-time.
Using these third-party tools payroll super-users can create very focused reports to solve specific business needs and then deploy them to users via a self-service model. The days of payroll analysts running reports and distributing them out to others has to end because it provides little if any value. And why create dozens of custom ABAP reports when we can have a tool that non-programmers can use to get better results?
In my experience, we use these reporting tools during an implementation to create 50 to 100 reports for specific purposes. There might be only one or two reports so complex that we need to create specific ABAP reports. And then we put in place a user-driven self-service reporting model where each functional area – Payroll, Benefits, HR – has a reporting super-user who creates reports, but they don't run them. The reporting tool is enabled for each user who needs the reporting data, and they run the reports as needed. This model works well and takes non-value added work out of payroll, empowering everyone to get the data they need themselves, when they need it without relying on anyone else.
Quality of Configuration
In the original article this same topic was described as 'Schema and Rule Configuration Errors' but now it's more than that. Even 20 years, more or less depending on the country, after the SAP Payroll product was first released I still see poor configuration. But why is this?
Payroll has always been complex, and it is not getting simpler. The complexities in calculations, compliance and reporting require attention to detail and a good understanding of how to make it work in SAP Payroll. It's not something that a person can just pick up in a training class and be proficient at in a couple years. Unfortunately, that reality has been ignored too often. We've had too many inexperienced or unqualified resources trying to make SAP Payroll work for customers. Because of that inexperience we end up with poor quality in implementations. Schema and rule configuration is done without considering the impact of retrocalculations, it continues to have hard-coded wagetypes and values, and wagetype splits get eliminated when they ought to be preserved. All the items in my first article continue to be issues.
Another reason for poor configuration quality is that SAP's Payroll is a very complex product. There are many opportunities to make mistakes if you don't fully understand the configuration. For example, making date effective changes on the mapping from a wagetype to a GL account is done by creating new symbolic accounts and making a date-effective change in that mapping to the wagetype. There is no date-effective change on mapping GL accounts to symbolic accounts – and the difference in these two approaches can have a dramatic impact on the posting to financial accounting. There isn't anything in SAP's training or configuration that tells you which way to go. There are many examples of this throughout SAP's Payroll product. It offers flexibility to meet all sorts of needs, but in doing so it also requires that a consultant or IT analyst knows enough to make the proper configuration decision.
Simplify Processes and Calculations
While SAP Payroll can handle all sorts of complexity, it is always better to eliminate that complexity instead of building it into the system. Too often we simply 'lift and shift' the payroll from the old system to SAP. Whatever the old system did, we just do it in SAP. That approach prevents us from gaining value in the payroll process. Simpler is almost always less expensive and higher quality than complexity.
For example, let's assume your company has three different 401k plans due to changes over the years, and those plans each have their own definition of eligible wages. So then in SAP Payroll, we need to have a wagebase for each plan. We can't just take the standard wagetype /102, we need two additional ones such as /195 and /196. Simple enough, just creating two more wagetypes. But then what happens when an employee changes from one plan to another? And then they get a retroactive payment from a period when they were in the previous plan? These scenarios happen, and our payroll calculation has to be compliant with the 401k plan. This gets complex very quick.
Instead of building this complexity into the new payroll and living with it forever (due to retrocalculations we always have to support old calculations) why don't we work to get all three plans using the same definition of eligible wages? We reduce the complexity, and payroll is easier to configure and support.
Not every complex process or calculation can be simplified, but if we never try we never get the benefit of simplicity. Every payroll has these opportunities, and though it's best to tackle them at implementation you also benefit if you simplify after that.
Standardization Among Country Implementations
SAP's payroll is supported in dozens of countries and many customers have implemented in multiple countries. Unfortunately, too often those implementations are done without any attempt to standardize system configuration and payroll processing. Although each country's payroll has different calculation and reporting requirements, much of it is also the same from a process perspective. Standardizing that which is the same across countries reduces complexity making maintenance and operations less expensive.
There are several ways to standardize configuration across countries. Wagetype naming standards are a good place to start. For example, all hours-based payments start with '1', all salary or flat-amount payments start with '2', deductions with '3' and so on. It's also useful for all expatriate-related wagetypes to be in the same range, even using the same wagetype code. For example, expatriate housing allowance could be wagetype 0HAL in every country. The same global approach is good for wage bases that are used in global compensation programs, such as incentive compensation. The wagebase might be /196 and the payment 2300 for each country. This sort of consistency is good for reporting, processing and support since we don't have to account for country differences.
Another good practice for multi-country payroll implementations is to use sub-features per country. Doing this enables one country to make changes independent of the other countries. For example, below the feature ABKRS calls a separate sub-feature per Country Grouping, so if Canada needs to make a change they can update their subfeature at the same time the US is making a change to theirs, and they can independently move them through change management. This same approach can be extended to most every feature used by payroll (feature PPMOD is the exception, since Country Grouping is not available to it; use Company Code instead).
From a process perspective, each country is more similar than distinct. We can implement Payroll Control Center for each country; only deviating in cases where we have country-specific steps in payroll. We can use SAP PI (Process Integration) to manage interfaces into and out of payroll in each country instead of creating country-specific frameworks. We can also use the same reporting tools and strategies.
Remember that complexity is the enemy of payroll, and approach each country implementation with the goal of standardization to a global framework, deviating only where required for country-specific items.
Documentation
Documentation's importance is rarely realized until it's needed and we find it doesn't exist. It's important to understand why certain configuration was put in place, not just what was done. Without the 'why', change management becomes more time-consuming and quality can suffer.
Documentation can be maintained on many of the configuration objects themselves. This is a good approach since the configuration and documentation stay together, and it's easy to update one when you change the other. For feature, schemas and rules the documentation is maintained via the corresponding transactions PE03, PE01 and PE02, as below; just select 'Documentation' and click on 'Change'. An editor will come up where you can enter in whatever text you want.
Most payroll configuration tables also have thee documentation objects. For example the primary wagetype table T512W enables you to enter documentation for each wagetype; click on the 'info' icon, and an editor comes up to accept your documentation:
Here's an example of what the documentation could look like for wagetype /102:
Some documentation has to happen outside the system, such as how to run payroll, how to clear claims and so on. Use whatever tool your company has for that, but make sure that it is stored in a place that everyone in payroll can easily access.
Testing
Payroll testing is a complex process, and it is critical that it is done well and comprehensively because fixing payroll errors in a productive system can be challenging. And even the best payroll system implementation will never be perfect at cutover because we can't test every possible scenario that we will encounter in the productive environment.
Interface testing is usually a challenge since it involves coordinating with external vendors, and getting a large base of data to test with is challenging. Sometimes we use the data from parallel testing to do more comprehensive interface testing, but that isn't always possible due to reusing that environment for the next parallel test. If possible, plan to have different testing clients or instances for the first and second parallel tests so that the data can be used for this testing. And with each vendor having a different testing process, it's good to have someone focusing on just coordinating the testing effort.
Parallel testing is a requirement for payroll, and a good practice is to test the full population of employees over three different pay periods. The amount of detail to sift through in parallel testing can be overwhelming. Comparing SAP Payroll, employee by employee and wagetype by wagetype, to the legacy system is a lot of work. There are some third-part tools that can help automate this process and they most often pay for themselves a few times over. They automate the comparison, record testing results, let you analyze differences within a certain tolerance (good for taxes) and provide data on how many wagetypes match or don't match. Without third-party tools you could develop something similar in ABAP or an offline database such as MS Access. If you take that route, be sure to develop that and have it ready before parallel testing starts.
Data migration testing is another area that seems to be discounted in too many projects. Data migration is never an easy, straightforward process, and we must have a way to prove that we are doing it properly. Typically, we reconcile data from SAP back to the legacy system per infotype. In the case of payroll balance transfers, we tie them back to the legacy system per wagetype. Since parallel testing depends on data migration, be sure to start the data migration development and testing process far enough in advance so that it is stable and read for the first parallel test. My practice is to have three cycles of data migration prior to the first parallel test.
Two Ways to Avoid Problems
As in my initial article, good project management is still the most effective way to avoid these SAP Payroll implementation challenges. Too often we rely on part-time project managers, or we assume consultants can manage the project themselves. In addition to that, experienced consulting resources are also critical. Don't entrust your future payroll system to underqualfied consultants. Investing in good project management and experienced consultants are two of the most effective ways to increase your chance of success.