When accumulating your employee data to import into the payroll system, it's important to get it right. This means making sure the data is inputted correctly, all mandatory fields are completed and the data is accurate. A big part of a payroll implementation is data checking, and this guide provides tips to support this process. 

Contents

• Transferring Employee Data
• Suggested checks
• Year-to-Date data checks

Transferring Employee Data

You can use reports from any of your current systems as long as they are up-to-date. Typically we see payroll/HR systems being used for current employee data to feed into the import. 

When retrieving this information, it's best practice to check the data on the system (if you can) and on the export that you are using: is the data tidy, are there any obvious gaps, do the employee numbers look correct?

If you're not using the FPS XML to import employee data, it's very important that the employee data import is accurate per HMRC's records. This means handling the data manipulation onto our import spreadsheet needs to be done with precision. This could look like comparing data to other systems/reports, using a 'VLookUp' formula instead of copy and pasting data, and manual checks on the spreadsheet. 

Suggested Checks

Check for duplicates: What's key here is the National Insurance numbers, e-mail addresses, and the employee and RTI codes. These should not be duplicated at any point as they all serve a specific purpose for reporting, communication and individualisation. 

Check employee numbers: Once you have confirmed there are no duplicates, ensure all employees are captured on the spreadsheet. We need all employees who have been paid within the current tax year, so it may be beneficial to cross-reference data here to ensure HR and Payroll are aligned. 

Ensure all mandatory fields are complete: A great help here is checking through our Employee Import File Notes to check which fields "can be left blank". It is possible to do multiple imports if you don't have your data all at the start, but if you are not consciously doing multiple imports then this check can be beneficial. 

Check the format of data: Manipulating data manually, typically on Excel, can lead to incorrect formatting, such as the cell style changing and dropping leading zeroes. Key items to check here are dates (e.g. start dates, date of birth, opt out dates) and bank details (sort code 6 digits, account number 8 digits). 

Year-to-Date Data Checks

If your implementation requires the year-to-date template to be completed (if you are not using the FPS XML to import this data), then this requires some extra knowledge to 'sense check' the figures and ensure any blanks are completed with 0s if applicable (note: NI category and employee code should never be blank). 

Subject specific elements to be mindful of: 

• Figures in the lower earnings limit (LEL) column should not be decimals.
• The banding columns (LEL, LEL-PT, PT-UEL) have caps so these figures should not be higher than the pay period multiplied by the cap figure. If you check this, please ensure this checked against the NI bandings for the current tax year as this can change. For example, the 2025/2026 LEL cap is £542. If your data is from August, this is p5, so the total should not exceed £542*5=2710) 

Once you have transposed the data onto the import template, total the columns and compare the employee totals to figures on your P32 (employer summary). This will raise any differences on the spreadsheet and can help to identify missing/duplicate records and incorrect figures. You can check this again once the data is imported into Ciphr Payroll Cloud on the reports, which can help reassure you that the data has imported correctly and the records are accurate for HMRC.