Importing Employees from Another Payroll System

What to Export from the Old System

Most payroll software can export its employee list as a CSV or spreadsheet. The column names will not match the new system's, and that is fine. What matters is that the file holds, for each employee:

• First name and last name
• National Insurance number
• Date of birth and gender (HMRC requires both on every Full Payment Submission)
• Tax code, including any week 1 or month 1 marker
• NI category letter
• Start date
• Bank details, if you pay by Bacs or Faster Payments

Have these to hand as well. In Payburo they are set on each employee's record after the import, not through the CSV: home address (required on an FPS where there is no NI number), student loan plan, and pension status.

Keep the header row. A file saved without one puts a real employee where the column names should be, and no mapping tool can safely guess from that.

How Column Mapping Works

Every payroll system names its columns differently: "Surname", "Last Name", "Family name"; "NINO", "NI No", "National Insurance". Column mapping is the step that says which of your columns holds which field.

What Payburo's AI mapping does

When you upload a CSV, Payburo asks an AI model to suggest a mapping for the identity fields: first name, last name, National Insurance number, tax code, NI category, email, start date, gender and date of birth. You then see every column beside the field it has been matched to, change any that are wrong, and import. Nothing is saved until you do.

A column whose header is already one of Payburo's own field names, as in the downloadable template, is matched exactly without asking the AI at all. That is how bank details, P45 figures and opening balances are carried: put them in the template's columns.

What the AI sees, and what it does not

The AI is sent the column headers and the shape of the first data row. A shape is a redaction: every letter becomes A or a, every digit becomes 9, and only separators such as dashes and the @ sign are kept.

The shape is enough to tell a National Insurance number column from a works number column, which is all the sample is for. Any two values with the same pattern produce the same shape, so no name, NI number or bank detail can be read back out of it. Only that one row is shaped; the rest of the file never leaves Payburo.

If the first row of the file looks like employee data and not headers, nothing is sent to the AI at all. You map the columns by hand.

Without the AI

The import does not depend on it. On a plan without AI features, or if a suggestion cannot be made, you choose the field for each column yourself, or use the template so that every column matches by name.

Moving Part Way Through a Tax Year

PAYE is cumulative. Each pay day's tax is worked out from pay and tax since 6 April, not from that pay day alone. So software that takes over in October needs to know what happened from April to September, or every employee's next payslip will be wrong.

There are two different "previous" figures, and they are easy to confuse.

Never enter both for the same employee. A migrated employee's opening balance already includes whatever P45 they brought to the old software, so adding the P45 again counts their previous job twice.

What an opening balance needs

• The tax year it belongs to
• How many pay periods it covers, and at which frequency (six monthly periods are not six weeks)
• Taxable pay and tax deducted to date
• NI-able pay, employee NI and employer NI to date
• Benefits in kind taxed through the payroll to date, if the old system payrolled any
• Employee pension contributions to date, split by whether they were under a net pay arrangement, if the old system filed them

Take these from the last payslip or the year-to-date report of the final period run on the old system. The first period you run on the new system is the one after it.

The cleanest time to switch

The start of a tax year. On 6 April every year-to-date figure is zero, so there is nothing to carry. A mid-year move works, with opening balances, but it is more to check.

Checks to Make After Importing

1. Count the employees. The number imported should match the old system's active headcount. Payburo's import is all or nothing: if any row fails (a malformed NI number, a missing date of birth), nothing is imported and every failing row is listed with its reasons, so you fix the file and upload it again.
2. Check tax codes against the last payslips. A code that lost its week 1 or month 1 marker in the export will tax cumulatively and take a catch-up amount.
3. Check each employee's pay schedule. A weekly employee imported onto a monthly schedule is paid at the wrong frequency.
4. Run the first period in parallel. Calculate the first pay run and compare net pay, tax and NI with what the old system would have produced before you approve anything.

On plans with AI features, Payburo also checks every calculated payslip before a pay run can be approved, looking for figures that do not reconcile. Those checks see pay figures, tax codes and NI categories against an internal reference, never names, NI numbers or bank details. A pay run whose checks did not complete cannot be approved until they are run again or you confirm you have reviewed the figures yourself.

Common Mistakes

• No header row. The first employee becomes the column names and is lost.
• Dates in the wrong order. 03/04/1990 is 3 April in the UK and 4 March in the US. An unambiguous format such as 1990-04-03 avoids the question.
• NI numbers with spaces or a missing suffix. Export them as nine characters where you can.
• Leavers included. Decide whether former employees come across. They are needed if you will produce their P60 or report a late leaving date.
• Entering a P45 and an opening balance together. See above: it doubles the previous employment.

Further Reading

• P60 vs P45: what's the difference?
• How to submit a Full Payment Submission (FPS) to HMRC
• NI rates and thresholds 2026/27