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.
More we can add to your workspace
- An applicant-tracking front end. The record starting at application rather than at hire, feeding the same employee file the rest of the module already reads.
Where we point you to a specialist
- 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. This is not legal advice.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsWhy 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](/glossary/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.
