Blame game won’t solve duplicate employment records

The duplicate employment record – where the employee has a single employment, the employer has one record but, somehow, the same single employment is duplicated on HMRC’s systems – is a nightmare. It leads to all sorts of complications, not least the potential issue of the basic rate (BR) code, as HMRC believes it is a second job. This is not a new issue, however, with reporting in real time it seems more common and certainly more visible. 

HMRC realises this and the latest Employer Bulletin contained information about how to avoid the creation of duplicate records. It’s all to do with knowing how HMRC expects to receive data. The big but, though, is this does differ from what happens in reality sometimes, so employers can learn and, maybe, adapt processes to avoid creating duplicates. However the simple fact is that payroll software functionality differs from one provider to the next.

If processes and software allow, the following are considerations to bear in mind.

The new starter

The first full payment submission (FPS) will be the first time HMRC’s systems are aware of the new employee in this employment. Yet, the first FPS should be submitted after the previous employer has submitted their final FPS containing the leave date. How do we check if the previous employer has submitted their final FPS? The presentation of a P45 is an indicator. So, this is just an awareness issue, as it is understandable HMRC’s systems will recognise an employment on one PAYE reference number and one on another.

In addition, the Employer Bulletin has the following tips.

• Full employee information on the first FPS is essential, as this matches the employee with an individual on HMRC’s systems. Once it is sent, don’t change it. A Robert who wants to be known as Bob is a potential duplication in the making, so maybe consider software’s “known as” functionality.
• The date of starting and the declaration (A, B or C) should only be sent in the first FPS. If, for example, the starting date turns out to be incorrect, record this in the software but do not send it to HMRC. This does lead you to question whether HMRC’s systems are accurately reflecting reality.

The message for employers is to have processes in place allowing for accurate gathering and input of full matching data. See HMRC’s Real Time Information (RTI) data item grid for the information that must be included on the FPS.

The leaver

Consider, firstly, the leaver under a Transfer of Undertakings (Protection of Employment) (TUPE) agreement, for example, a change from one PAYE reference to another but with no change to employment terms and conditions or continuity of service. HMRC’s view is that this is a leaver under the old PAYE reference and a starter on a new reference. This is often recognised by employers who will generate a P45 but will not give it to the employee (they have only gone through an administrative procedure at the end of the day, not a change of employment). Yet, even though there may be a need to retain the original start date in software, say for seniority purposes, this is a leaver and starter process and must be reported as such.

In addition, the Employer Bulletin has the following tips.

• Like the start date, the leaving date first reported to HMRC is a leaving date that should not change. If the date is found to be incorrect, change it in internal systems but do not report to HMRC
• The payment after leaving indicator is used only where the employer has issued a P45. Although a payment after leaving has to be reported, it must be with the original leaving date

Appendix 2.1 Best Practice Hints and Tips in the RTI data items grid is useful as this includes guidance on the common situation where an employee leaves employment, payroll don’t know and the leave date has to be reported on a subsequent FPS.

Changing software providers

It is important the details in the new software match those in the previous one. Employers need to remember, though, that if this is a continuation of employment and just a change of provider, the transfer does mean the employees are new starters. Therefore, the once-only reporting of the start date and starter declaration should not be repeated by the new provider.

This is a check that should form part of the implementation project. Like TUPE transfers, a change of provider is an administrative action only, as reporting transferred employees as new starters may result in two records for the same employer on the individual’s personal tax account.

The payroll ID

Data items 38, 39 and 40 in the RTI data items grid refer to the payroll ID field. This is a unique identifier of a single employment in the PAYE scheme. So, for example, where the same employee is employed on the weekly payroll and on the monthly payroll, this is two employments and each one must have a unique payroll ID.

It is worthwhile explaining the three fields mentioned above.

• 38 is the unique payroll ID in this employment. It may or may not be visible to the employer and may or may not be auto-generated by software. Once used and attached to an employee, it should never be used again, even if that employee leaves and then returns. In cases like this, while the employee number might stay the same in payroll software, this is a separate employment and another payroll ID needs to be allocated.
• 39 is simply notifying HMRC that the payroll ID in this employment (field 38) has changed in this submission, leading to 40.
• 40 is the original Payroll ID.

So, if the employer wants the unique payroll ID to be different from one declared previously, they will indicate field 38 as the payroll ID, indicate “Yes” in field 39 and enter the previous payroll ID in field 40. 

The only time that 39, 39 and 40 are not declared together is, for example, where there is a change of software providers and the payroll ID used for the employment was not known. In that instance, in the first FPS with the new provider, not as part of parallel processing, the employer will declare the new payroll ID (38) and the change indicator (39) leaving 40 blank.

Together with the full employee name, address, current gender, date of birth and national insurance number, the payroll ID is essential data-matching information for HMRC’s systems. The issue is that, unlike other information, employers may not have visibility of this.

The Employer Bulletin also talks about three other data fields. While these don’t cause duplicate employments, mentioning them indicates that either employers are using them incorrectly or HMRC are interpreting the data incorrectly. It could also be that HMRC’s guidance on their use is unclear.

1. Only where an occupational pension is being paid should field 33 (the occupational indicator) be completed.
2. Only where an occupational pension is being paid should field 34 (the occupational pension value) be completed.
3. Only where the employee is not paid regularly should employers use field 40A, the Irregular employment payment pattern Indicator. This may be, for example, when an employee is in an unpaid portion of maternity leave or is a zero-hour worker, both examples of where someone is not paid regularly but the employer still regards them as employees and do not wish HMRC to treat them as leavers on their systems.

Effectiveness and accuracy

In everything we do in life, effectiveness and accuracy all comes down to education and communication. The fact HMRC recognises that education is necessary is to be applauded. Yet, it still does not take away the fact that employers are using up-to-date, 21st-century software that is “speaking” to legacy HMRC systems.