Producing a wages file your bank will import
How a South African employer produces a wages payment file its bank will import, why new layouts need a test import, and what to check first.
By Achekam · · 4 min read · For Running a business businesses in South Africa
On payday in many small businesses, someone sits with the payroll report on one screen and online banking on the other, typing each employee's net pay into a bulk payment. It is slow, and it is exactly where mistakes and fraud slip in: a digit transposed in an account number, a salary entered twice, or a bank account that was quietly changed last week.
A bank import file removes the retyping. Payroll produces a file, the bank's online system reads it, and the person releasing payments checks a total instead of a list. This article explains how that works for a South African employer in Achekam, and the checks that make the file safe to use.
FNB's layout or a column-mapped CSV for other banks
Once a pay run is approved, Achekam can produce a wages file for the bank. There are two kinds:
- FNB's import layout, for businesses that bank with FNB.
- A column-mapped CSV, for Standard Bank, Absa, Nedbank or another bank. You set the order of the columns to match what your bank's bulk payment import expects.
Every payment in a bank file needs a six-digit branch code, along with the employee's account details. Check that every employee record has one before payday rather than on it.
A file can only be produced from an approved run. A pay run is approved by someone other than the person who prepared it, nobody can approve a run that pays themselves, and an approved run is never recalculated. So the figures in the file are the figures someone else has already checked.
Untested layouts and the test import
A new layout is marked untested until someone confirms a test import. That label is there for a good reason: if the column order is wrong, the bank may reject the file, or misread a column without saying so.
Do the test before you need it:
- Produce the file from an approved run.
- Import it in your bank's bulk payment screen, but do not release the payments.
- Check that the bank shows the right number of payments, the right names, the right amounts and the right total.
- Delete the unreleased batch at the bank.
- Record in Achekam that the bank read the file correctly.
Only then treat the layout as tested. If your bank changes its import format, test again.
Unverified bank accounts
Changing an employee's bank account is the classic payroll fraud. A message that looks as if it came from an employee asks for their salary to go to a new account, and nobody checks.
In Achekam, 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. Unverified accounts are listed when the run is approved and left off the bank file. Staff who submit a new bank account through self-service are no exception: an approved change still needs a second person to verify it.
Verification means more than clicking a button. Phone the employee on the number you already had on file, not one given in the change request, and confirm the new details with them before you verify.
If someone is left off the file because their account is unverified, they still need to be paid. Verify the account properly and pay them separately, rather than skipping the check because payday is close.
The payment schedule
Each approved run also has a payment schedule, downloadable as CSV. It lists who is to be paid and how much. It is useful for a final review, for employees paid outside the bank file, and as the record of what the run was meant to pay.
When the payments have gone, you can mark the schedule paid. Doing so only records the fact.
Achekam moves no money
Achekam does not pay anyone. It produces the file; you import it into your own online banking and release the payments there, under your bank's own authorisation rules. Marking the run paid in Achekam records what happened at the bank; it does not cause it.
That split is a strength. Your bank's controls, such as dual authorisation on bulk payments, stay in force, and payroll staff in Achekam never have the power to send money. ACCA's overview of internal controls explains the types of control behind arrangements like this, including segregation of duties.
When a payment comes back
Now and then a salary payment is returned by the receiving bank, usually because an account was closed or a detail was wrong. Treat it as a warning, not an admin chore. Find out why it bounced, confirm the correct details with the employee directly, have the new details verified by a second person in Achekam, and pay the employee separately once that is done. Keep a note on the run of what was returned and how it was resolved, so the payment schedule and the bank statement can still be reconciled.
Who does what on payday
| Step | Who |
|---|---|
| Prepare the run | Payroll preparer |
| Approve the run | A different person in a payroll role |
| Verify any changed bank accounts | Someone other than the person who entered the change |
| Produce the bank file | Payroll |
| Import and release at the bank | The people your bank mandate allows |
| Mark the schedule paid | Payroll, once the bank confirms |
Construction firms with large site teams face a sharper version of the bank-account problem; checking bank details against ghost workers covers it. For why two people on payroll is worth the effort, see the two-person rule for payroll. And once wages are paid, the month's statutory returns follow, as described in UIF declarations, UI-19s and the COIDA return.
Before next payday, produce a file from your last approved run and do the test import. It is far better to find a wrong column order on a quiet afternoon than on the morning staff expect their pay.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
