Where's the real value found in payroll?

I don't really care how you run payroll in SAP or EC.

Some customers run their SAP or EC Payroll by executing the individual transactions codes. Some use process models and the HR Process Workbench. Some use Payroll Control Center. All those methods work, and once you get used to them they are effective and efficient. I don’t hear customers complain much about how they run their payroll – I hear them complain about having to handle payroll errors. Making it easier to fix errors found during the payroll process is good, but why put up with those errors when you can eliminate them? I want a payroll system that has so few errors that the time and effort spent fixing them is incidental. I want a payroll system that no one notices because it’s doing its job so well. Unfortunately this is seldom the case. But why?

User interfaces help sell products; they make a great demo. Data quality, interface quality, compliance, reporting and integration are not so exciting. Showing someone how easy it is to fix an error found while calculating payroll is more exciting than explaining how to prevent that error in the first place. Start talking about how – or even if - your software or implementation proposal ensures only good data are allowed into the payroll process will put most people to sleep (except for the payroll manager and payroll IT analysts!). So, these critical aspects of payroll don’t get attention in demos and proposals. And this leads to bad implementations and unsatisfied customers.

Payroll systems often have a number of inbound and outbound interfaces. Every inbound interface has the possibility to introduce bad data into the payroll calculation. Payroll data can also be complex, so correctly transforming it for external systems can be challenging. Getting it wrong means bad data goes out, then you have reconciliation issues and other manual processes for verifying or correcting the data. Too often we don’t program interfaces for the real world – how do we back out an inbound interface? How do we recognize duplicate interfaces, inbound or outbound? How do we provide information on what was processed so that payroll analysts can reconcile, report on and verify the data? You can’t simply throw data into a payroll system and expect it to go well. But that is what most implementation projects do.

Compliance solutions that get you 80% of the way there still leave you with 20% of the work. So if you have to manually perform or work-around 20% of the compliance work for wage calculations, garnishments, tax filings and payments, and compliance reporting that adds up to a lot of work. Or you can implement your own extensions and enhancements to fill that 20% gap – but then you also have to monitor and maintain them over time. Some of this can be outsourced but that is an extra cost.

Payroll reporting is one of the most underserved areas of the system. Customers need more than a payroll journal and a wagetype listing. The standard payroll system needs to include a flexible report writer – only available currently via third-party packages. So, too often payroll users extract data from several sources, download and mash them into usable reports. This necessary but wasted effort results in sensitive data duplicated on local drives all around the payroll department. It’s a serious waste of time and effort, and a security risk.

Calculating payroll is often one of the most complex aspects of the payroll process. The challenge here is that getting this done correctly takes a lot of effort and expertise. Too often, shortcuts and assumptions are made that leave the payroll analysts with manual work-arounds and validations. Maybe a certain payroll calculation is correct 95% of the time, but in some cases manual intervention or validation is needed. With some extra effort and/or expertise we could take that 95% to 100%. 

Most of the data payroll needs comes from other departments and systems. For example – employee demographic and compensation data from HR, timesheets and time-off from several time management systems, finance master data such as cost centers and internal orders, and in some countries employee benefits from a benefits system or provider. Getting good data from these critical sources is important for payroll quality. How well does your payroll system integrate with these sources? How much manual effort is incurred because of errors in this integration?

So anyway, yes show me how nice the user interface is for running payroll and correcting payroll errors. That’s nice. And then let’s talk about all the rest of what makes a good payroll. Show me what your payroll system does with interfacing, compliance, integration, reporting and calculating. How much of it comes with the standard package and what will the customer have to do on their own? And how is this addressed in your implementation proposal?

And for customers who are already living with a compromised payroll implementation, know that with some effort it can get better. Poor implementations can be corrected and processes can be improved. It just takes some effort; more effort, unfortunately, than if it would have been done up front in the initial system implementation.