Employee Files, Contracts & Onboarding: The HR Record That Survives an Audit
The employee file is the least glamorous thing in HR and the first thing anyone asks for — in a dispute, at an audit, when a funder checks your controls, or when the person who knew everything about your staff resigns.
Here is a test worth running on your own organization this week. Pick an employee who joined two years ago and try to produce, without asking anybody: their signed contract, their current salary and the authorisation for the last change to it, their statutory numbers, their next of kin, and the documents they submitted at onboarding. If that takes more than a few minutes, you do not have employee records — you have employee folklore held by one or two people.
That is a risk in three directions at once. It is an employment-law risk, because a dispute is decided largely on documents. It is a continuity risk, because the knowledge sits in a person rather than a system. And it is a payroll risk, because every statutory computation is derived from facts in that file.
What actually belongs in the file
Most employers hold some of this, in several places. The point is not that each item is exotic — it is that they need to be one record rather than five.
| What | Why it matters | Where it usually lives instead |
|---|---|---|
| Signed contract and any variations | A dispute turns on documented terms, not on what was understood | A folder on someone's laptop, or a filing cabinet nobody has opened since |
| Role, department, reporting line, start date | Drives cost allocation, approvals and who authorises whose leave | An org chart in a slide deck that is a year out of date |
| Compensation and its change history | Every payslip is derived from it; every increase should be traceable to an authorisation | A spreadsheet where only the current figure survives |
| Statutory identifiers (KRA PIN, NSSF, SHIF) | Required for statutory computation and remittance | Copies of documents in an email thread |
| Bank details | Payment routing, and a common target for fraud | A bank mandate file maintained separately from HR |
| Next of kin and emergency contacts | The one thing you need urgently and cannot look up | Whatever was written on the application form |
| Onboarding documents and certificates | Verification, and evidence of due diligence | Scattered across the inboxes of whoever recruited them |
| Exit date and reason | Stops payment, closes leave, ends statutory obligation | Discovered when someone notices the payment still going out |
If one person leaving your organization would make your staff records unusable, you do not have records. You have a colleague who happens to remember things.
Employee is not the same thing as user
This distinction sounds technical and has real consequences. Plenty of your employees will never log into a system — casuals, field staff, drivers, production and cleaning teams. If your HR records only exist for people with logins, those staff have no records at all, which is precisely backwards: the workers with the least paperwork elsewhere need the file most.
So an employee record has to stand on its own, whether or not there is an account attached to it. In AWRA an employee exists independently of a system user, and a login can be linked when there is one. That is what lets a casual worker have a proper contract, a bank record, statutory numbers and a payslip without occupying a licence or being handed credentials they do not need.
Onboarding is where the file is either built or lost
Every gap in an employee file was created on the day that person joined. Nobody sets out to have an unsigned contract on record; it happens because the first week is busy, the person starts work, and the paperwork is a task without a deadline.
-
Create the record before the first day, not after
Role, department, reporting line, start date and terms exist before the person walks in. If the record is created retrospectively it will be created incompletely.
-
Collect documents as a checklist, not a conversation
Contract, identification, statutory numbers, bank details, next of kin, certificates. A list with ticks, owned by someone, closed before the end of week one.
-
Capture statutory identifiers immediately
KRA PIN, NSSF and SHIF numbers are needed for the first payroll run. Chasing them in week four means the first payslip is either late or wrong.
-
Set the compensation record, not a note
Basic and allowances as structured compensation the payroll reads, so the first payslip derives from the record rather than from an email.
-
Enrol them in leave and attendance from day one
Accrual starts on the start date. Backfilling leave accrual months later is where opening-balance disputes are born.
-
Close the loop at exit with the same discipline
Exit date recorded on the leaving date — which stops pay, closes leave accrual and ends statutory obligation. Processed late, it becomes an overpayment you have to recover from someone who no longer works for you.
The bank-detail change control
Changes to employee bank details are a well-known fraud route: a request arrives that looks like it came from an employee, the details are updated, and one salary goes somewhere else. Treat a bank-detail change like a payment approval — verified against the employee independently, authorised by someone other than whoever received the request, and recorded with who changed it and when. This is cheap to enforce and expensive to skip.
Who is allowed to see what
Employee files contain the most sensitive data most organizations hold — salaries, bank details, identification, sometimes medical context in sick leave. It should be uncomfortable that this often lives in a shared spreadsheet or a folder with generous permissions.
Two rules cover most of it. First, access is by role: a line manager may need to approve leave without seeing salary; finance may need pay figures without seeing personal documents. Second, the sensitive changes leave a trail — who viewed or changed compensation and bank details, and when. Data-protection obligations under Kenyan law apply here too; confirm what applies to you with your own adviser rather than assuming a system handles compliance on your behalf.
What we do and do not do
What AWRA OpsHub does today
- One employee record independent of system users, so staff without logins still have proper files.
- Roles, departments, reporting lines and dates, driving approvals and cost allocation.
- Compensation as structured data with change history, feeding payroll directly.
- Statutory identifiers, bank details, contacts and next of kin on the record.
- Document storage against the employee, so contracts and certificates live with the file.
- Role-based access and an audit trail over sensitive changes.
What it does not do
- We are not a recruitment or applicant-tracking system. The record starts at hire, not at application.
- We do not draft contracts or supply templates that constitute legal documents.
- We do not advise on employment law or data protection. What you must hold, for how long, and who may see it are questions for your advocate or data-protection adviser.
- We do not verify documents — we store what you collect; authenticity checks remain yours.
Employment and data-protection obligations are set in law and change. Confirm what applies to your organization with your advocate or adviser. Nothing here is legal advice.
Why this pays for itself quietly
Employee records rarely produce a visible saving, which is why they get deferred. The return shows up as absences: the dispute that ends in one meeting because the contract and the authorised change history are on the record. The audit that asks about payroll controls and gets an answer. The month the HR administrator is away and nothing stops. The exit that does not become an overpayment.
The payroll connection is the most concrete of these — every statutory computation is derived from the file, so file quality sets payroll quality. That chain is set out in PAYE, NSSF, SHIF and housing levy, and the wider sequence in HR software in Kenya.
Our take
Build the record at hire, close it at exit on the leaving date, treat bank-detail changes as payment approvals, and make sure employees without logins still have files. None of that is exciting and all of it is what you will wish you had done the first time somebody disputes something in writing.
See the employee file done properly
One record per employee with or without a login, compensation history feeding payroll, documents stored against the file, and an audit trail over the sensitive changes.
Explore employee managementFrequently asked questions
Can we keep records for staff who do not use the system?
Yes, and this matters more than most employers expect. An employee record exists independently of a system user, so casuals, drivers, field and production staff have proper files — contract, compensation, statutory numbers, bank details, payslips — without needing credentials or occupying a licence. If your HR records only cover people with logins, the staff with the least paperwork elsewhere are the ones with no records at all.
How should we handle changes to employee bank details?
As a payment approval rather than an admin update. Verify the request against the employee through a channel you initiate, have it authorised by someone other than whoever received it, and keep a record of who changed it and when. Fraudulent bank-detail changes are a well-established route to diverting one salary payment, and the control costs almost nothing compared with recovering the money.
What documents must we hold, and for how long?
That is a legal question rather than a software one, and it depends on the document and on obligations that change — so confirm it with your advocate or data-protection adviser rather than inferring it from what any system happens to store. What we can say is that whatever you decide to hold should live against the employee record rather than in personal folders and inboxes, because retention rules you cannot locate the documents for are not being met in practice.
Who can see salary information?
Whoever you grant it to, by role. The useful separation is that a line manager can typically approve leave without seeing compensation, while finance needs pay figures without needing personal documents. Sensitive changes — compensation and bank details in particular — leave an audit trail showing who changed what and when. Kenyan data-protection obligations apply to this data; confirm your specific position with your own adviser.
What is the most expensive record-keeping failure you see?
Exits processed at the point of noticing rather than the leaving date. It produces overpayments you then have to recover from someone who no longer works for you, leave accrual that kept running after they left, and statutory contributions made for a person who was not employed. Recording the exit on the actual leaving date fixes all three at once, and it is purely a discipline question rather than a system capability.
