Bank transfer files for payroll: why the system must build them, not a copy into Excel
The payroll bank transfer file must be built by the system from a locked close, with five controls, because one shifted cell in Excel pays one person someone else's salary.
The close is done, the payroll total is approved, and someone opens Excel and copies the name, account and amount columns to upload to internet banking. On row 214 there is a new employee with no bank account yet, from that row on the whole amount column shifts down by one, and the bank transfers exactly what the file says. The payroll bank transfer file must be built by the system from a locked close, because only that can prove every row is still correctly paired.
The system builds the bank file because copy-and-paste has no control
The incident above is not rare; it is just rarely told. The bank file must be built from a close that is already locked, by the system, with no human hand between the take-home pay figure and the file row. The reason is not that people are careless. A copy-and-paste step has no control that can prove 800 rows are still correctly paired.
Five controls close the last step of payroll
- Single source. The file is built from a payroll period with the status closed. A period that is still open cannot be exported.
- Matching totals. The row count and the rupiah total in the file equal the payroll summary. Both are printed on the approval sheet, which is signed before upload.
- Verified accounts. The account number is stored in the employee record with the bank name and the account holder's name. Employees without an account go on an exceptions list paid in cash, not as an empty row in the file.
- A format per bank. Every bank has its own upload format, and banks change formats without wide notice. Formats are stored as versioned templates; when a bank changes a column, the template is updated once.
- Reverse reconciliation. The bank's transfer result report is read back. Failed transfers (closed account, name mismatch) become a follow-up list, not something an employee discovers three days later.
A multi-depot distributor builds one file per source account
Distributors often pay from several company accounts, one per entity or per region. The bank file is built per source account, and the summary per account is the basis for moving funds between accounts before payday. A common mistake: one combined file uploaded from an account without enough balance.
Two figures per period show whether the controls work
Measure the number of failed transfers and the number of pay corrections after payday. Both should be close to zero after two periods. If they are not, the cause is almost always account data that was not verified at onboarding.
In HRKita, the transfer file is built from a closed period
HRKita exports the bank transfer file from a period that is already closed, with a summary per company and per account as its control sheet. Formats for certain banks are already available. Reconciliation of the transfer results is done from the bank's report, not through a direct connection to the bank; how it runs for your bank is something we go through in the demo.
If your bank is not yet supported, bring one upload file that has worked before, together with the bank's format guide, to a demo. The template is built from that real example and tested with a small upload before the first payroll period. Later format changes are handled by updating the template, not by going back to Excel; that rule alone keeps the five controls above in force.