Payroll System Implementation - Part 1 (Getting Ready)

This is the first of two articles which I hope may assist payroll professionals who are embarking on a payroll system implementation project. In this first part I look at some of the initial topics you may wish to consider at the outset of your project - tasks you can undertake and decisions you can make before you even start working with your new system. I've written in a generic style rather than focusing too heavily on the specifics of our particular project - though for information purposes we're a UK Local Authority, moving from Oracle's on-premise e-business suite to their cloud platform, Fusion. In the second part I'll cover parallel run and go-live.

Elements

Elements are the building blocks of payroll. The quality of your data migration, UAT and parallel run will be dependent upon how precisely your elements have been mapped (legacy system to new system), spec’d, built and tested. Moving to a new system is a good opportunity to streamline your elements – in the legacy system you might have elements which are redundant, duplicated, badly designed or simply no longer meet requirements. It is tempting to completely overhaul them. Before doing so, a note of caution – the more fundamentally you change your elements, the greater degree of difficulty you’ll be adding to the process of data migration and parallel running. For example, in an effort to streamline your pool of elements, you might have two elements in the legacy system which you combine into one in the new system. This is a perfectly reasonable course of action, but one that can quickly become complex if the two legacy elements use different input values.

For this reason, it is not enough to only consider the elements themselves, you must also account for the input values which control how each element works – are they based on a unit of time worked (hours /days etc.), a cash value, a percentage of basic pay, a table or some other variable (or combination of variables)? Are you using different input values for particular elements compared to those used for the same element in the legacy system?

None of the above constitutes a recommendation not to improve your elements as part of your implementation project; it’s merely recognition of the challenges which can present themselves. In hindsight, I’d have been less radical at the outset, sought to have only changed those elements which were fundamentally flawed and looked to make ‘root and branch’ improvements to our element pool after the completion of our implementation. By seeking to run before we could walk, significant pain was added to our data migration and parallel running, and we had to use a third party system to support the reconciliation process.

However you decide to approach the task, the need to clearly define and map all of your elements (and input values) cannot be overstated. The time you put into this task will pay huge dividends later on. Collaborate with your SI on an ‘Element Logic’ document which contains as much detail as possible about every element.

These are just some of the fields contained within our ‘Element Logic’ document –

·????????New Element Name

·????????Old Element Name

·????????Legal Entity (on which legal entities is the element applicable)

·????????Classification (e.g. Standard Earnings, Voluntary Deductions etc.)

·????????Costing

·????????Description

·????????Element Logic (how does the calculation work)

·????????Input Values

·????????Table Value (if applicable)

·????????Pro-Ration (Yes / No)

·????????Taxable (Yes / No)

·????????Niable (Yes / No)

·????????Pensionable (Contributions) (Yes / No)

·????????Pensionable (Banding) (Yes / No)

·????????Pensionable (Qualifying Earnings) (Yes / No)

·????????Recurring / Non-Recurring

·????????OTL Element (Yes / No)

·????????ICD Element (Yes / No)

·????????Termination Rule (e.g. Termination Date, Last Standard Process, Final Close etc.)

Consider the level at which you hold your element eligibility links. Holding links at as high a level as possible (legal entity or enterprise level) reduces the maintenance overhead, but beware of 'globality' - if you're using one element to serve multiple employers or payrolls and the requirement of one of those customers changes, you may end up having to create another version of the element.

Balances

If elements are the building blocks of payroll, balances may well be the roof. Those without an understanding of how payroll works often seek to minimise the importance of balances, but it’s clear to those in the industry that without accurate year-to-date values we cannot deliver a statutorily compliant FPS, return pay data to pension schemes or provide payroll reports to our customers. It’s worth adding that if you’re undertaking a mid-year migration, then previous taxable pay and PAYE balances will be needed for correctly calculating cumulative tax.

It is an oft-repeated fallacy that if you’ve matched your parallel run to a 100% degree of accuracy, you don’t need to conduct a balance reconciliation as well. Those who advance this viewpoint argue that if your element results match, your cumulative figures will automatically match too. This fails to account for the many balances which are for reporting-purposes only, are needed to calculate a run result, or that inaccurately built balance feeds could mean that balances aren’t populating even when element results are correct.

Many of the requirements for safeguarding against these problems are similar to those already described for elements – you should painstakingly map your balances at the outset of the project, defining which elements feed each balance, and in turn identify the purpose of each balance e.g is it needed for statutory reporting, does it feed a formula responsible for a pay calculation etc.? Balance reconciliations should be conducted at the following points:

a)?????Data Migration – ensure initialised balances in the new system reconcile to the balances in the legacy system at the point of migration.

b)?????Reconcile balances after each parallel run – as you layer on each parallel run, are your balances increasing in line with the legacy system? This should form part of the exit criteria for moving to the next parallel run cycle.

Payroll Structure

Rationalising your payroll structure is another attractive aspect of implementing a new system. The opportunity to reduce your overall number of payrolls and right the wrongs of your legacy system should not be allowed to pass you by. If you do decide to combine legacy payrolls together in your new system, take care to ensure that you can still report out at the level that you need - especially if you're bringing departments which are part of the same TRU together under one payroll but those departments still want separate reporting.

We relished the opportunity to rationalise over 150 payrolls down to 20 and have benefited from doing so, but this has also posed challenges around being able to produce reporting at the granular level that some of our customers expect. For example, it's been an advantage for us to bring multi-academy trusts (MATs) together on to the same payroll and equalise deadlines and run-dates, but not being able to produce the gross-to-net report at departmental level has made the transition process difficult.

Historical Data

Naturally you’ll want to minimise the volume of data you’re migrating to the new system, but before making this decision you may wish to consider the following examples in which the lack of pay history can create problems during parallel run and go-live. ?

·????????Average Weekly Earnings for statutory payments – discuss with your SI how you’ll cater for this. Your system may have a facility to disable the earnings check, meaning statutory payments are automatically granted to everybody and then you only need to make a manual adjustment for those who don’t meet the eligibility criteria. This is likely to be the path of least resistance since most people qualify for statutory payments, but it clearly carries a risk in that if you fail to make the required manual interventions you’ll end up granting payments to those who aren’t entitled.

·????????You may decide not to migrate terminated secondary assignments. If you’re undertaking a mid-year migration and an active employee has had a terminated secondary assignment at some point during the tax year, you’ll need to migrate any taxable pay and PAYE balances from the terminated record in order to ensure the cumulative tax calculation is accurate for the ongoing active assignment(s).

·????????In the Local Government Pension Scheme, the Assumed Pensionable Pay rules (which govern how pensionable pay is calculated during periods of reduced pay) dictate that the employer contribution should be based on an average of pay in the preceding three months. Until sufficient earnings history is built up in the new system, this may leave you in a position where you have to enter APP adjustments manually. By considering this issue in advance, you may be able to formulate an automated approach, such as the creation of a custom balance which migrates the required three months of earnings history.

·????????You might choose not to migrate terminated employee records at all, but we know that ‘payments after leaving’ are a frequent occurrence. Having to manually set these records up in the new system during a busy parallel run can place an unnecessary strain on a team already likely to be overburdened by that stage.

·????????In local government, entitlement to occupational sick pay is often calculated on a rolling year basis, taking into account OSP exhausted in the past 12 months. Ideally, two years of absence history should be migrated to cater for this. ?

·????????If your increment rules are driven by length of service, ensure your new system holds the correct historical date against which service is measured, rather than simply the start date of the record in the new system. Many people think that the position start date will suffice for this purpose, but check your increment rules carefully – it may be that you should actually be measuring service against the length of time the person has been on the spinal point, rather than the the time they've been in their current position. By the time we discovered this and realised that the spinal point effective date only went as far back as the record start date, it was too late and in some cases we've had to continue managing increments manually until enough time has passed that the automated increment rules will work based on the spinal point start date.

Other areas for consideration at the design stage are grade ladders, pension schemes, absence plans, FTE calculations, costing and your approach to third party payments. If feedback to this article suggests those topics would be of interest to readers, I'll make it a three part series.

In the second and final part of the series I'll look at parallel run and go-live.