17 January 2022

Neil Tonks, legislation manager ChMCIPPdip at MHR International discusses the work that software developers carry out when preparing for the new tax year


These days, nearly all payroll teams make use of software to perform the routine processing that goes into calculating, paying, reporting and accounting for what is one of the biggest costs in most businesses: the employees.

Software products are continually updated, ensuring they remain compliant with market expectations and legislation, which the UK and Irish governments and beyond continue to generate.

 

What changes are required?

As a software and service provider, how do we make sure our products have the functionality that’s required, especially for changes driven by legislation?

The first thing we need to do is find out exactly what changes are required. This is harder than you might think. Government announcements are very often just ‘highlights’, with the detail provided later. We can’t make any amendments to our payroll systems to support the changes until we have that detail, so it’s vital that we’re pro-active in getting hold of it, sometimes facing very tight deadlines to ensure we get all the right information.

For instance, we knew in the autumn of 2020 that for 2022/23, there would be a National Insurance (NI) category to provide employer’s relief when employing veterans in their first year of civilian employment. We also knew there would be a way for employers to use the full payment submission to reclaim the NI paid in respect of 2021/22 when the new category wasn’t available. However, it wasn’t until the summer of 2021 that the category (V) and the detail of the reclaim mechanism were released.

 

Research time

The process of investigating and extrapolating the right details involves several stages and plans of action. First, of course, meetings. Sometimes, several meetings. These days they generally take place online via Teams or Zoom but pre-pandemic, visits to government offices were the order of the day.

Many of these events are regular consultation forums between software developers and civil servants. Sometimes they are hosted by government departments such as Her Majesty’s Revenue and Customs (HMRC), while others are held by professional bodies, such as the British Computer Society. There are also ad-hoc meetings dealing with specific upcoming changes, where the impact is sufficiently wide-ranging and the timescale allows for it.

The CIPP contributes much to this process. There’s the technical panel, which has a remit to consider the impact of government initiatives on payroll generally, and policy roundtable events, which concentrate on a specific topic. We find these useful because the discussion isn’t limited to the technical aspects of a change, but also covers the practical challenges faced by payroll professionals.

Finally, we get a lot of assistance from the CIPP’s policy and research team, both from the various publications they produce and by the direct communication we have with them. Most CIPP members probably don’t realise the amount of work the policy team do in the background, but we certainly do and we appreciate it.

We’re also on various government email lists and interact with teams such as HMRC’s software developers support team, who provide a source of information and a point of contact to ask questions.

Internet research is another vital part of the process. We study many documents sourced online ranging from official guidance, publications of the CIPP or other professional bodies (accountants, for example) to white papers and magazine articles. We even resort to reading the legislation itself occasionally, which is not exactly fun but is important as these are, of course, the final word on the rules of an initiative. So that’s how we deal with legislative changes.

 

Company resilience

The other sort of change is market-driven, to ensure our product is kept competitive, adds value and supports the resilience of our customers. We continually need to ask the question, ‘how do we make our users’ lives better?’ This goes beyond the obvious answers around functionality and usability. We need to consider not just how the system supports our customers’ processes, but how it can drive improvements for them.

Conferences are another valuable source of information of what is happening within the industry. These serve the dual purpose of providing a learning opportunity, as well as the chance to talk with payroll professionals from around the country and overseas – after all, payroll is a global profession and many of the challenges are also global.

 

Software update cycle

MHR’s software product iTrent is updated quarterly for functionality enhancements, while short-notice changes can be supplied outside this cycle as ‘service packs’.

Each November, MHR releases legislative changes for the following tax year, allowing customers time to do their own testing, configure the product to their needs, train employees and update processes in time for changes taking effect.

There is a mechanism to ensure payrolls for a new tax year cannot be processed until the minimum release/’service pack’ for that year is installed. This means customers cannot inadvertently be uncompliant and at risk.

 

Necessary testing

After that, a development team is assigned. This will consist of a designated business analyst, alongside software engineers and software testers, plus any other people whose skills might be required in the specific project, such as user interface designers and IT security experts.

The team then get together to work through the requirements in order, to decide how they will be achieved technically. They break them down into individual tasks so that small pieces of work can be tested in isolation, and identify any potential technical difficulties, plan the work, estimating how long it will take.

After that, the process of developing the enhancements can commence. The team works collaboratively to ensure that what’s developed meets the requirements, and that it all performs correctly. This can get very complex in a large development with many interdependent changes to make, and the team lead is responsible for co-ordinating everything, and making sure the inevitable queries and problems which arise are resolved.

Testing is a very important part of the process. Not only do the testers have to verify the enhancements are fulfilling the requirements specified by the business analyst, but they must also make sure the end-to-end processes all work smoothly for the user, and the changes haven’t inadvertently caused any other issues.

Once all that’s been done and everything’s signed off, the changes can be released to customers. However, that’s not the end of the process, because at that point the only people who know what the changes are, and how they’re used, are the members of the team who developed them.

 

Educational process

This means we have a big knowledge transfer process to undertake. We need to educate a range of people, all of whom have different needs.

Customers are, of course, critical to this part. They’re going to be using the new functionality so they need to understand what’s changed, what they need to do in order to implement the changes and how to use the new functionality going forward. But they’re not the only ones who need educating. We have many internal employees who require bringing up-to-date, and they often need a different approach to customers, depending on their level of involvement with customers and the product.

Our implementation and technical consultants, for instance, need to understand not only how to use the new functionality, but how it works and how the information is held in the database, so they can produce reports, extracts, workflows and so on.

We must also educate our help desk analysts, customer relationship managers, sales teams and many other groups of people, so they can support customers.

A range of approaches are used for this process, from webinars and functionality walk-throughs (internal and external facing), and instructional videos, through to training courses and customer user groups. There are also the more traditional user guides, though these tend to be reference manuals, as there are better ways of educating people than expecting them to read lots of text.

 

Conclusion

What I’ve outlined is, of course, the way we operate at MHR. Other developers and companies may have different working practices but the basic functions will always be the same: Research. Do it. Test it. Release it. Educate.

So next time you update your software, and you get support for new legislation, pause to think about all the hard work that went on behind the scenes to produce a compliant product.

Visit the MHR website here: http://ow.ly/Ivmr30s7Hga


 

Featured in the February 2022 issue of Professional in Payroll, Pensions and Reward. Correct at time of publication.