By BP Gallucci, Communications Manager, Ceridian
Paying employees right and on time gets easier when payroll staff use the same system that front line employees use to record their time, and managers use to track attendance. That’s because these functions are all part of the same gross-to-net pay calculation. And the closer together these functions operate, the faster and more efficient the whole thing hums along.
Most solutions interface with their partners in this gross-to-net chain; time tracking applications take data from punch clocks and put it on a timesheet for managers to review; payroll applications calculate taxes from a given gross pay value to tell payroll how much to pay the people; some applications look at overtime per jurisdiction; others operate as the HR system of record.
All this software working together sounds a bit like the traditional assembly line. One works on its piece, finishes it, and passes it on to the next down the line to work on. Just like traditional mass production, this allows for a kind of specialization – software providers become proficient at just their aspect of the chain because they’re focusing on just their piece – but saying a piece of software can interface with another belies the complexity of making that interface work. It requires technical skill to code, for lack of a better term, the links between software.
As a veteran of the software industry providing human capital management (HCM) solutions, I’ve worked on many applications addressing different aspects of the overall problem of getting employees paid right. While I’ve seen many different ways of putting together this puzzle of different applications, the biggest and most common divide has always been between the gross pay and net pay sides of the equation. Software was either concerned with gross pay, meaning functions that contributed to the calculation of an employee’s gross pay, or net pay, meaning calculating taxes, deductions, benefit premiums and so on.
Seeing this divide over and over I assumed there was some fundamental constraint that made this so. Gross pay was an input to net pay so of course it preceded it. Leaning on the assembly metaphor again, I saw the whole calculation as a process where the software was the factory, you had inputs that were the raw materials and you had outputs, the finished product. And like the assembly line, this system enforced a strict serial order that I kept seeing.
But technology advances through human innovation.
What used to be done in serial, where software calculated gross pay for the week and sent it on to payroll, can now be done in parallel when time and pay are the same software. How? When there is no divide between the gross and net sides of the calculation, the different functions share information instantly – time data that is coming into the timesheet as employees log their time shows up on the pay run covering that week in real-time – meaning work can be done simultaneously. The frontline manager checking time and attendance can review the underlying hours that contribute to an employee’s gross pay for a pay run at the same time as a payroll administrator starts working on that pay run.
Without the divide between gross and net, payroll administrators, managers, and their employees, all have an easier time with accuracy. Each step on the process relies on accurate information from the preceding step – with correct time and attendance, gross pay, including any overtime, can be calculated and only with correct gross pay can the net pay be right. With the old school serial way of doing things, it was hard to go back and correct mistakes. If someone’s time and attendance was wrong, for example they forgot to record a weekend shift they were called in to work, then their gross pay was missing worked hours and their pay check would be light. Catching that mistake before it went over the divide to payroll was crucial if you wanted to keep the two sides balanced.
For solutions relying on software integrated together, mistakes caught only after details were sent to payroll normally meant the payroll administrator had to make some manual adjustment directly in the pay run – so if the employee forgot to record an eight-hour shift, the payroll administrator would do the math and add the gross pay amount into the payroll software so that net pay could be calculated with the shift’s hours and the employee paid correctly. While these solutions work to get the employee their missing eight hours of pay, working in serial often leaves large gaps of time between committing gross pay details and employees receiving their pay, during which the underlying records are locked and with payroll. Making the fix just in payroll, the underlying time and attendance records which can impact accruals, bonuses, anything that is calculated on the gross pay side of the equation, are not corrected – creating an incomplete fix.
It’s much better to work in parallel.
Yes, there is still some order to the calculations – the final determination of net pay for a week can’t be completed until the gross pay details are finalized – but the point is payroll administrators don’t have to wait to start their work for some other process and piece of software to finish its piece. They can work on a pay run with incomplete information whenever they need to, recording the quarterly bonus perhaps or adjusting a parking pass deduction, at the same time as the same software gathers time and attendance data for that timeframe. Making corrections is easy: if a shift is missing from the time and attendance records, the manager or whomever simply adds it, and the details are included instantly in the corresponding pay run.
In this system, the gross-to-net calculation is not an old school assembly line where each part has to be made sequentially; now it’s like just-in-time manufacturing, supplying parts to the process only when needed, allowing simultaneous work to be done that come together at the end. It’s more efficient. It’s the only real innovation in payroll processing for decades – and it is the future.
BP Gallucci, Communications Manager for Ceridian, focuses on telling the stories of Ceridian, its people, clients, and award-winning products. BP brings the historical viewpoint of a veteran of the HCM industry, having lived through extensive changes in the industry over the past decade while working in R&D, implementation, and customer support for several HR software vendors. BP’s work can be read in Connect magazine, the Glassdoor blog, and Hr.com; his novel Lexus Sam is published by Iguana Books.