Tips to Avoid Duplicate Employment Records

Duplicate employment records, where the employee has just one employer who, in turn, has just one record but the record is duplicated on HMRC’s system. 

This issue has been occurring for some time and can lead to many complications including HMRC believing the duplicated record to be a second job, thereby slamming the employee with the basic rate tax code. While this is not a new issue, it is easier to see in real-time reporting. 

In order to rectify this issue, HMRC’s recently released Employer Bulletin offered information on how duplicate records can be avoided. It has a lot to do with the way in which HMRC expects data to be received which can differ from what happens in practice. While the advice from HMRC is helpful, the key issue remains that payroll software functions differ based on the provider. 

The following is worth bearing in mind should your software allow:

New Starters

HMRC’s systems will initially be made aware of the new employee on receiving the first full payment submission (FPS). However, the first FPS should not be submitted until after the previous employer has made their final FPS (which is usually indicated by the receipt of a P45). This is a frequent issue that plagues many employees on starting a new job but is usually rectified quickly when HMRC systems recognise that a job change has occurred. 

Employer Bulletin gave the following additional tips:

• • It is essential that full employee information is submitted with the first FPS in order that the employee can be matched with an individual on HMRC’s systems. 
• • Shortened names e.g., Michael who is known as Mike can cause issues so ensure consistency with HMRC’s systems (or your software may have ‘known as’ functions which you may consider using). 
• • The starting date and the declaration should be sent with the first FPS only. For example, if you submit the first FPS but then discover that the starting date was incorrect, just record this in software and do not send to HMRC because it could lead to duplication. 

Leavers

First, we consider the leaver under a Transfer of Undertakings agreement (TUPE), where there is a change from one PAYE reference to another but there is no change to the terms of employment or continuity of service. HMRC takes the stance that this is a leaver under the old PAYE reference and a new started on a new PAYE reference. While employers often recognise this by generating a P45, they often don’t give this to the employee. This can cause duplication as this is a leaver and starter process and HMRC expects to receive as such. This can be confusing where the original start date is required for seniority purposes but, again, it is best to record this only on software and not with HMRC.   

Employer Bulletin gave the following additional tips:

• • As with the start date, the leaving date reported to HMRC should not be changed even if there is a mistake. It should be changed on internal software only. 
• • The ‘payment after leaving’ indicator should only be used where a P45 has been issued. Payments after leaving should be reported but with the original leaving date intact. 

Changing the Software Provider

It is essential that all details entered in the new software match the details in the previous software. If this is a change of software only, the employees continuing their employment will be recorded as new starters by the software but this should not be reported to HMRC because a new starter record for employees could lead to a duplicate record with HMRC and on the employee’s personal tax. 

Payroll ID

Data items 38, 39 and 40 in the RTI data items grid refer to the payroll ID field. This is the unique identifier of one employment for the purposes of the PAYE scheme. For example, where the same individual is employed on both the weekly payroll and the monthly payroll, this counts as two employments and each one is required to have a unique payroll ID.

Data item 38 is the unique payroll ID for this employment. It may or may not be visible to the employer and may or may not be generated by software. Once this has been used and attached to an employee, it is never to be used again, even if the same employee leaves and returns later. In such cases, while the employee number may remain the same in payroll software, this is a different employment and a different payroll ID must be allocated.

39 notifies HMRC that the payroll ID in this employment (field 38) has changed in this submission, leading to 40 which is the original Payroll ID.

Therefore, if the employer requires the unique payroll ID to be different from one declared previously, they will need to select field 38 as the payroll ID, select “yes” in field 39 and enter the previous payroll ID in field 40. 

Where there is a change of software providers and the payroll ID used for the employment is not known, the employer should declare the new payroll ID (38) and the change indicator (39) leaving 40 blank as part of the first FPS.

Much like the employee’s full name, address, gender, date of birth and NI number, the payroll ID acts as data-matching information for HMRC’s systems.  Unlike these other pieces of information, however, the Payroll ID may not be visible to the employer.

Get in touch to discuss your payroll, tax and finance requirements.