Payroll bulk imports
Several payroll things are set per employee and are impractical to enter one at a time: contributions, recurring other payments, previous-employer income, tax adjustments. Each has a bulk import, and they follow the same shape.
Where: Payroll and My Team › Tools › the relevant import You need: the bulk data right, plus the payroll rights for what you are importing
What can be imported
| Import | Sets |
|---|---|
| Profile contributions | Which contributions apply to each employee, and any overrides |
| Profile other payments | Recurring allowances and deductions per employee |
| One-time other payments | A single payment for many employees at once |
| Previous employer | Income from a prior employer in the same tax year |
| Tax adjustments | Manual tax corrections in bulk |
| Historical payslips | Payslips from a system you migrated from — see Importing historical payslips |
Which one, when
| You want | Use |
|---|---|
| To set up many employees at go-live | Profile contributions and profile other payments |
| To pay something once to many people | One-time other payments, or a bulk bonus |
| To fix the annual tax basis for mid-year joiners | Previous employer |
| To apply an authorised tax correction to several people | Tax adjustments |
If you are importing the same thing every cycle, it should be a group rather than an import — see Other payment types and groups.
Before You Start
Reconcile the source data. An import applies exactly what is in the file, including its errors, to everyone in it at once.
Do it before the run is calculated. An import after calculation does not appear until the payslips are recalculated.
Start with ten rows. A column mismatch or a date-format problem is obvious on ten and invisible on four hundred.
How to import
- Open the relevant import under Tools and download the template.
- Complete it — one row per employee, or per employee per item.
- Upload and read the validation output before committing. This is the cheap moment.
- Import.
- Compare the imported row count against your file. Skipped rows are the quiet failure mode of every KAMI import.
- Recalculate the affected payslips.
⚠️ Rows whose employee identifier does not match are skipped, and the import still reports success for the rest. A partial import looks like a successful one. Always check the count.
What Happens Next
- Imported values apply from the next calculation.
- Profile-level imports persist and apply to future runs; one-time imports apply once.
- Previous-employer income changes the annual tax estimate, so it affects every remaining payslip that year, not just the next one.
Tips
- Always check the count, every import, every time. It is the one check that catches the failure mode nobody notices.
- Keep the source file with the date it was imported. It is the only record of where the values came from.
- Import previous-employer income before the first live run for mid-year joiners, or their withholding is wrong from the start.
- Check one employee you know well after every import. A systematic error shows up on a person you can sanity-check.
- Do not use imports to correct a single employee. Edit them directly — an import for one row is a large tool for a small job and leaves a confusing trail.
Troubleshooting / FAQ
Q: The import succeeded but some employees are unchanged. Their identifiers did not match, so those rows were skipped. Compare the count against your file.
Q: The values imported but the payslips did not change. Recalculate. Imports do not reach calculated payslips.
Q: Which identifier should the file use? Whatever the template specifies. Do not substitute names — they are not unique and will not match.
Q: Can an import be undone? Not as a single action. Correct by importing the right values or editing the affected employees, so plan the check before the import, not after.