Importing a client's employees from a spreadsheet

How a bureau imports a client's employees from a spreadsheet so that every row is checked and nothing loads by halves, then verifies bank details.

By Achekam · 11 October 2026 · 5 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya

A new payroll client rarely arrives with clean data. It arrives with an export from its previous provider, a spreadsheet someone in HR has kept for years, or both, and they do not agree. Some names have trailing spaces, some ID numbers have lost their leading digits to a spreadsheet's number formatting, two employees share a cell phone number, and one row is a heading somebody pasted halfway down.

The danger in loading that file is not that it fails. It is that it half succeeds: most of the staff loaded, a handful of rows quietly skipped, and nobody notices until those people are missing from the first run. This article sets out how to prepare the file, how Achekam's import treats it, and what to check afterwards.

Set up the employer first

Each client whose payroll the bureau runs is its own employer in Achekam, with its own employees, earnings, deductions and pay settings. The employer is created before anyone is imported, and that is when the country is chosen: an employer runs payroll under South African, Nigerian or Kenyan rules, decided when it is created.

Get that choice right before importing. The country decides which details each employee needs and which statutory figures the runs will produce, so a Kenyan client set up by mistake as a South African employer is a problem to fix before there are employees attached, not after.

Preparing the employee spreadsheet

Spend the time on the file before the import, not after. A practical preparation routine:

1. Agree one source. If the old provider's export and HR's spreadsheet disagree, settle each difference with the client before loading either.
2. Strip what is not data. Remove headings repeated mid-sheet, subtotal rows, colour-coding that carries meaning, and notes typed into cells.
3. Protect identity and tax numbers. Format those columns as text so that leading zeros and long numbers survive, and spot-check a few against source documents.
4. Collect the country's essentials. For a South African employer, identity and income tax numbers matter, because an IRP5 or IT3(a) cannot be issued while an ID or tax number is missing. For a Nigerian employer, record each employee's State of residence: PAYE is assigned to that State, and a run cannot be approved while a State cannot be worked out.
5. Write down control figures. Count the employees and total their monthly pay in the source file, and keep both numbers for the check after import.

An employee spreadsheet is also personal information of the most sensitive ordinary kind: identity numbers, salaries and bank accounts. Move it only through channels the bureau trusts, and delete working copies once the import is done. For Kenyan clients, the Data Protection Act, 2019 sets out the principles for processing personal data, data subjects' rights and the Data Commissioner's powers; South Africa and Nigeria have their own data protection laws, and the bureau's handling of the file should satisfy the one that applies.

Every row checked: all or none

Employees can be added one at a time or imported from a CSV file. The import checks every row and writes all rows or none. If a single row fails, nothing is written, and the bureau sees which rows failed and why.

This is stricter than many imports, and it is the right behaviour for payroll. A partial load leaves the client with some employees present and others absent, which is precisely how someone gets left off a run. With all-or-none, the state after an import is always one of two things: the whole file, or nothing at all.

Fixing rejected rows

When the import refuses the file, resist the quick fix of deleting the failing rows to get the rest through. Each deleted row is an employee who will not be paid. Instead:

• Read every error before changing anything. Several rows often fail for one reason, such as a date column in the wrong format.
• Fix the cause in the source, not just the symptom in the CSV, so the next export does not repeat it.
• Ask the client about anything you cannot resolve from the documents, such as a missing tax number or two different start dates for the same person.
• Re-import the complete file, not a patch of the corrected rows, so the all-or-none check covers everyone.

Keep a short log of what was changed and on whose instruction. When the client later asks why an employee's start date differs from their own spreadsheet, the log answers it.

Bank details after the import

An imported bank account has been entered by whoever ran the import, and Achekam treats entered and changed accounts the same way: an employee's bank account entered or changed by one person must be verified by another person before it is paid in the payment schedule or bank file.

Plan the verification as part of onboarding rather than discovering it at the first approval. A second person at the bureau confirms each account, ideally against a document the employee or the client provides independently of the spreadsheet. For a large client this is a real piece of work, so schedule it before the first payday. The checks that make verification meaningful are set out in verifying employees' bank detail changes.

After the import: prove it matches

Before any run, reconcile the loaded employer to the source:

Then run the first payroll as a parallel run beside the old provider's figures where you can, and investigate every difference. For how separate employers sit side by side in one firm, see running clients' payroll as separate employers.

The import itself takes minutes. Book the preparation and the reconciliation as proper time in the onboarding plan, because that is where the accuracy of the client's first payslips is decided.

General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.