If you’re a payroll professional, one of the most irritating things that you probably hear far too often is… ‘payroll is just pressing a button once a month’. Fortunately, those people entrusted with the business’ largest controllable cost, i.e. its salary bill, know differently.  

Whilst it might appear great that systems make everything look straightforward and seamless to both senior leaders and colleagues, the downside is that the work doesn’t have the profile that it deserves. That’s why National Payroll Week is our annual opportunity to step out of the shadows and demonstrate: ‘that we don’t simply pay people, because paying people isn’t simple’.

It’s certainly true though that we have enough to contend with thanks to legislative complexity, so we don’t want to add to that by having overly complicated processes and system workarounds. This approach will almost certainly lead to errors, whether these are to do with data inputting, being unaware of the interaction between different processes or just because we haven’t thoroughly tested a new process or data item.  

Let’s take just one example… the HR team want to introduce a new benefit provided via salary sacrifice. It sounds very ‘simple’ to reduce somebody’s salary so saving employer’s NI and apprenticeship levy, but what are some of the steps this actually involves?

1. Agreeing the layout of employment contracts going forward that will be understood by both the employee and any members of the HR or Payroll team who have to interpret them

2. Re-designing the payslip to show the reduced salary and the negative addition which reflects the value of the benefit in kind provided

3. Updating corporate intranets and shared service portals to explain the new payslip layout

4. Agreeing with HR where the notional (original) salary will be stored and what it will be used for, for example salary review, overtime rates and death in service to name but three

5. Will the reduced salary simply be passed to payroll and then onto the finance team and what will appear on all the internal reports?

These points are in no way an exhaustive list of what it takes to implement a salary sacrifice, but let’s just consider what could go wrong even with just these five steps….

1. The project team amend the employment contract to show the reduced salary after the sacrifice but don’t know there is a separate starter form that payroll receive that still asks for the original salary, not the reduced figure, so new starters get overpaid

2. The payslip shows the salary sacrifice, but IT were told simply to show it is a deduction, rather than as a reduction on the gross side of the payslip. HMRC are sent all the salary sacrifice documentation to get a ruling on whether it’s compliant and of course it isn’t, so the whole scheme has to be scrapped

3. Salary review coincided with the scheme being set up, which meant that line managers were given the reduced salary after the sacrifice when in fact the business

had initially agreed that salaries would be reviewed based on the original pre-sacrifice pay. Therefore all the new salaries are incorrect and everybody is underpaid  

4. Finance get the shock of their lives when the first payroll run after the sacrifice has been implemented when it appeared that the NI and apprenticeship levy to be paid over to HMRC is a lot less than the month before. No one has talked to them about the 14.3% saving of NI and apprenticeship levy as a result of reducing salaries, which impacted their systems and forecasting

So how do we avoid a simple reduction in gross pay leading to a failure to pay the whole workforce correctly?!

1. Ensure that all of the systems that the HR and payroll team use are process mapped so it’s absolutely clear the impact of amending even something as minor as the name of the field

2. Include in that process map, the documents that are impacted within the business by the system change

3. Avoid silos of knowledge where individuals have everything stored in their head instead of it being written down, or specialists who never rotate their roles so the there is no cascading of expertise

4. Involve the right stakeholders right from the beginning of any system change whether it appears straightforward or is a complex new tax year update – the payroll team cannot have the expertise to know what the impact is of their project on other parts of the business, but they certainly will know when something goes wrong!

5. Avoid shortcuts and workarounds, you can bet your life the one person who doesn’t know about them is the one tasked with the data input

In summary, the reason software developers like ourselves have extensive teams of analysts, developers and testers is that so we can provide systems that make it look as if you just press a button.  Whilst your customers may never appreciate how much effort has gone into getting that little net pay box perfect, the more we keep systems and processes streamlined the more likely we are to keep that a secret between us and you.