Loading a batch of new temps into payroll
How a staffing agency adds a batch of new temps to payroll from a CSV file without half-loaded records, and what to check before the first run.
By Achekam · · 4 min read · For Recruitment businesses in South Africa, Nigeria, Kenya
A client calls on Wednesday: they need a full shift of pickers at the distribution centre from Monday. By Friday the agency has screened and confirmed the workers, and someone in payroll now has to get every one of them set up before the first pay run. Typing them in one by one is slow and invites mistakes. Importing a spreadsheet is faster, but a bad import can be worse than none at all.
The risk with bulk loading is the half-finished job: some workers loaded, others rejected, and nobody quite sure which. A partly loaded batch leads to people missing from the first run, duplicate records when someone tries again, and a long afternoon matching names against a spreadsheet.
This article explains how to load a batch of temps into Achekam payroll cleanly, and what has to happen between the import and the first payday.
Start with the right employer and country rules
A business sets itself up as an employer in Achekam and runs payroll under South African, Nigerian or Kenyan rules, chosen when the employer is created. Before any import, make sure the temps are going into the employer whose country rules match where they work. An agency that supplies workers in more than one of these countries keeps each country's workers under an employer set up for that country.
Payroll tax tables need attention too. Achekam ships its tables pre-loaded but unconfirmed, and no payroll run uses a table until a named person at the business confirms its own copy. If this is your first run under an employer, or the first in a new tax year, confirm the table before the temps' first payday, not on the morning of it.
Preparing the file
Most import problems start in the spreadsheet, so time spent here is well spent. Prepare one row per worker in the layout the import expects, and check every detail against the documents you collected during screening. For each worker that usually means:
- full name exactly as on the identity document;
- identity or passport number;
- tax number, where the worker has one;
- start date and pay frequency;
- pay rate and how it is paid, such as hourly or daily;
- bank account details;
- for Nigerian workers, the State where they live.
That last item matters. Each Nigerian employee's PAYE is assigned to the State tax authority of their State of residence, and a run cannot be approved while a State cannot be worked out. Collect it at screening, not on payday.
Have someone who did not build the spreadsheet compare it with the screening records before the import. Typing errors in identity and bank numbers are easier to catch on paper than to unpick later.
Every row checked: all rows or none
Employees can be added one by one or imported from a CSV file. The import checks every row and writes all rows or none.
That is the protection against half-loaded batches. If one row in the file has a problem, nothing is written; the import is refused, you correct the file and import it again. You never end up with some workers loaded and others missing, so there is no reconciliation exercise to work out who made it in.
When an import is refused, fix the file rather than removing the troublesome rows to get the rest through. A worker taken out of the batch "to deal with later" is the worker who will be missing from the first run.
Verifying bank accounts before the first run
Importing a worker's bank details does not make them payable. 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. For an imported batch, that means a second person checks each new account before payday. AccountingTools' definition of segregation of duties explains the principle behind it: assigning the steps in a process to different people so that no one can both commit and conceal theft or error.
Plan for it. A large batch can take time to verify properly, so schedule the verification for the day after the import rather than leaving it to the hours before the run. A good verifier checks that the account holder's name matches the worker and, for anything that looks odd, confirms with the worker directly.
The wages journal for temp pay
Once a run is approved, it is posted to the business's own ledger as a wages journal, with the amounts owed to the tax authority and to funds recorded as liabilities. For an agency, that matters for two reasons.
First, the cost of temporary staff lands in the ledger as payroll costs, alongside the revenue from billing the client for their hours, so the margin on each contract can be seen in the books. Second, the liabilities for PAYE and other deductions are recorded as they arise, which helps when the monthly returns are prepared.
Before the first run: a checklist
- The temps are under the employer whose country rules apply.
- That employer's tax table for the period is confirmed.
- The import file was checked against screening records by a second person.
- The import succeeded in full.
- Every new bank account has been verified by someone other than the person who entered it.
- For Nigerian workers, every State of residence is recorded.
Once loaded, temps need payslips and a reliable payday; see payslips and pay schedules for temporary workers. Permanent placements are billed differently, as explained in when to issue the placement fee invoice, with rebates when a placed candidate leaves early covering failed placements.
Before your next intake, build the import spreadsheet template once, with every column above, and keep it as the only way new temps reach payroll.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
