The Name on the Payroll Nobody Had Met
The auditor does not ask whether payroll is correct. She asks for three things that prove it: that every name on the run is a person who exists, every change to pay or bank account between two runs with a name against it, and a payslip from March that reprints today exactly as it was paid. What the system already holds for each, how to pull it, and where it is thin.
The internal auditor arrives on a Tuesday with a printed copy of the September payroll summary: 214 people paid, a net figure, a date. She puts three requests on the table. First, she will pick twenty-five names from the run, and for each one she wants to see that the person exists — a contract, attendance for the month, an account the money went to. Second, she wants every change to anyone’s basic pay, allowances or bank details between the August run and the September run, with who made it and who approved it. Third, she wants to see that the August run cannot now be altered, and she wants the March payslip for one particular employee reprinted, with the figures it was paid on.
None of these is unusual. Payroll is usually the largest single cost an organization has and the easiest to inflate quietly, which is why every audit plan treats it the same way: headcount first, changes second, finality third. The awkward part is that most payroll teams answer all three with spreadsheets assembled the night before, and an auditor knows exactly how much a spreadsheet assembled the night before is worth.
Three requests, three kinds of evidence
| The request | What she is really testing | Where the answer lives |
|---|---|---|
| Twenty-five names from the run | Ghost employees: pay going to someone who does not work here | Each payslip, the contract it was calculated from, the locked timesheet for the month, and the payment line written when the run was posted |
| Every change between two runs | Unauthorised rises, allowances and diverted pay | The audit log, filtered to HR and the dates between the runs, read alongside the two sets of payslips |
| A closed run, and an old payslip | Whether history can be rewritten after approval | The run’s locked status, the payslip’s stored figures and the rule versions recorded against it |
Every name on the run is someone who exists
Start with how a person gets onto a regular run at all. When payroll calculates a month, it takes every employee whose work country matches the run and whose status is active or on probation. For each of them it then needs two things before it will produce a payslip: an active employment contract with a basic salary on it, because the contract is the only place base pay comes from, and a locked timesheet for that month. Anyone missing either is not paid and not silently dropped either — they are listed on the run as skipped, with the reason, and that list stays on the run after the page is closed.
That gives the auditor’s sample a path to follow for every name. The payslip points to the contract it was calculated from and to the timesheet period it read. The timesheet carries who locked it and when, plus a frozen summary of the month: days worked, days absent, days on leave, hours, overtime and the hours the roster expected. The employee record carries who created it and when, and its creation appears in the audit log under HR with the person who did it, their IP address and the time.
When the run is posted, one payment line is written per person for their net pay, and each line records the last four characters of the account or mobile number the person’s primary payout record held at that moment, and who posted it. So the question “where did the money go” is answered from the posting itself, not from whatever the payout record says today. AWRA records payroll as paid when it is posted; the transfer itself happens in your bank, and the bank’s file is the second half of that evidence.
A locked timesheet is evidence, not a gate
Basic pay is reduced only by approved unpaid leave. A person whose locked timesheet shows no days worked at all is still paid their full basic, because the timesheet being locked is what payroll checks, not what is inside it. That makes the timesheet summary the first place to look in a ghost test: a full salary against a month with nothing worked and no leave is the pattern worth an hour of anyone’s time.
Before the auditor samples names
- Open the run and read the skipped list. Someone skipped in September and paid in an off-cycle run the same week deserves a sentence of explanation.
- For every name sampled, open the locked timesheet for the month and compare days worked with the pay on the payslip.
- Check who created each sampled employee record and when, in the audit log, and whether that person also runs payroll.
- Compare the last four digits on the payment lines across the whole run. Two different people paid into accounts ending in the same four characters is a question, not an answer, but it is the right question.
- Open the Access Conflicts screen and see who holds both the right to edit employee records and the right to run payroll. AWRA flags that pair as high severity for exactly this reason: add a person, give them an account, pay them.
Between two runs: what changed, and who changed it
The second request is where most payroll systems are weakest, because the changes that matter are made in three different places. In AWRA they are three different records, and each leaves a different kind of trace.
| What changed | How it is changed | What the trail holds |
|---|---|---|
| Basic pay | Edited on the employment contract | An audit entry naming who updated which contract, and when. The amounts before and after are on the two payslips, each of which stores the basic salary it was calculated on. |
| Allowances and deductions | Added to or removed from the employee’s pay package, one component at a time | An audit entry for each addition and each removal, naming the employee, the person and the time. The amounts appear as lines on each payslip. |
| Bank or mobile money details | Added as a new payout record, made primary, or removed. A record is never edited in place. | The earlier record is kept, as a non-primary record or as a removed one with an audit entry. Who added each record and when is stored on it. |
The last row does the most work. A new account number is never typed over an old one: a change of bank is a new payout record, added by someone allowed to edit employee records and made primary, and the old record stays on the employee. So “what was the account before, and who added the new one” always has an answer. Seeing a full account number is a separate, higher permission, and every reveal is itself written to the audit log.
The allowance trail is thinner, and worth understanding before the auditor finds it herself. An employee’s package of allowances is a single record that components are added to and removed from; it does not keep dated versions of itself. We wrote about that separately in The Package That Has Only One Version. For an audit the practical consequence is simple: the payslips are the history of the amounts, and the audit log is the history of who touched the package and when. Read them together.
A change of bank is a new record, never an edit. The account the money used to go to is still there, and so is the name of whoever added the new one.
Who ran it, who approved it
Payroll in AWRA is four separate permissions, and an auditor will want to see them held by different people. Viewing runs and payslips is one. Running payroll — creating a run, calculating it, entering off-cycle amounts, discarding an off-cycle run that has not been approved — is another. Approving a run, and reopening an approved one, is a third. Posting it to the ledger as paid is the fourth.
Each step leaves its stamp. Calculating records who did it and when. Approving records the approver and the time, and is refused if another run of the same month was approved or reopened after this one was calculated, because tax is charged on a person’s combined pay for the month and the figures would no longer add up. Posting records the time, and each payment line records the person who posted. Every one of those actions is also a line in the audit log, with the person, the time and the address they came from.
Two things to know before the auditor asks. Reopening an approved run clears the approval stamp on the run, so the run shows only its latest approval; the audit log keeps both the original approval and the reopening. And the run itself will accept an approver who also calculated it. The Access Conflicts screen flags anyone holding both permissions as high severity, and warns rather than blocks, for the reasons in Segregation of Duties. A hard rule is in the ledger below.
A finalised run stays finalised
The third request is the easiest to demonstrate, because the rule is enforced in one place and every action goes through it. Once a run is approved it is locked: it cannot be recalculated, its off-cycle amounts and final settlement figures cannot be changed, and it cannot be discarded. The only way back is to reopen it, which needs the approval permission and is recorded. Once it has been posted and marked paid, even that is refused, and it cannot be posted a second time.
- The attendance under it is locked too. Reopening an employee’s timesheet for a month is refused while that month’s run is approved or paid, so the payslip and the attendance it was paid on cannot drift apart afterwards.
- One regular run per month per work country. Anything extra in the same month is an off-cycle run, and an off-cycle run has to carry a reason: bonus, correction, missed pay, commission or other.
- Payslips have no edit screen. A payslip changes only by recalculating its run, which is impossible once the run is approved.
A March payslip, reprinted in October
Reproducing an old payslip is a test of whether the system recalculates history or remembers it. AWRA remembers it. Each payslip stores its own figures at the moment of calculation — basic salary, prorated basic, gross, the taxable and pensionable bases, both deduction totals and net pay — with every earning and deduction as its own stored line. Reprinting March in October renders those stored figures, and the printed payslip says so: the figures are frozen at calculation time and unaffected by any later change to statutory rates or contract terms.
The statutory side is handled the same way. Tax and contribution rules are configured per country as dated, numbered versions, and a change in the law is published as a new version rather than an edit to the old one. Each payslip records exactly which versions it was calculated under. So if a rate changed in July, the March payslip still points to the March rule, and its figures were never recalculated under the July one.
One detail for the auditor’s file: the name and employee number on a reprint are taken from the employee record as it stands today. If someone changed their name between March and October, the reprint shows the new one against the old figures.
Pulling it, in the order she will ask
-
The run-level summary
The Payroll Summary report lists every run in a date range with its status, headcount, gross, deductions, net and run date, and exports to CSV or PDF. It is the August-to-September headline: if headcount moved from 209 to 214, five names need explaining.
-
The run itself
Open each run for its payslips, its skipped list with reasons, and its status. Download any payslip as a PDF from there.
-
The changes in between
In the audit log, filter to the HR module and the dates between the two runs’ calculation. Narrow by person or action if she asks about one employee. Export the filtered set as CSV or JSON.
-
Proof the log is whole
Every audit entry is chained to the one before it, so removing or editing an entry breaks the chain. Run the verification from the audit log screen and hand her the result. How that works is on the audit trail integrity page; the honest word for it is tamper-evident.
-
Who could have done it
The Access Conflicts screen lists every person and role holding a risky pair of permissions — run and approve payroll, or edit employees and run payroll — so the segregation question is answered with a list, not an assurance.
The short version
A payroll audit asks three things: that every name is a real person, that every change between runs has a name against it, and that a closed month stays closed. AWRA answers the first with a contract, a locked timesheet and a payment line per person; the second with a chained audit log and bank details that are added rather than overwritten; the third with a lock on approved runs and payslips that keep their own figures and rule versions. Prepare by hand for two things: comparing two runs person by person, and keeping the person who calculates apart from the person who approves.
What AWRA OpsHub does today
- A lock on approved and paid runs: recalculation, entries, settlement figures and discarding refused once approved; reopening needs the approval permission and is refused once paid.
- Four separate payroll permissions for viewing, running, approving and posting, with each step stamped with the person and time and written to the audit log.
- A regular run that pays only people with an active contract and a locked timesheet for the month, with everyone else listed on the run as skipped, with the reason.
- Payslips that store their own figures and lines, record the statutory rule versions they were calculated under, and reprint from those stored figures.
- Payout details added as new records rather than edited, encrypted at rest, with a separate permission to reveal a full number and an audit entry every time one is revealed.
- One payment line per person on posting, carrying net pay, the last four characters of the account paid to, and who posted it.
- A chained, exportable audit log with module, person, action and date filters, CSV and JSON export and a verification check, plus an Access Conflicts screen for the payroll pairs.
More we can add to your workspace
- A rule that refuses the person who calculated a run as its approver, as payment runs already do, available as a workspace setting so a team of two can keep its current arrangement.
- A run-to-run variance report per employee, listing who joined, who left and whose basic, allowances, deductions or payout account changed between two chosen runs, ready to hand to an auditor.
- Before-and-after values in the audit entry for contract salary edits and allowance changes, so the log alone answers what the amount was and what it became.
- A second-person approval for changes to payout details, with a notice to the employee at the contact details already on file when their account is changed.
- A duplicate payout account check across employees, flagging two people on one run paid to the same account.
- The calculated-by and approved-by names on the run screen itself, alongside the dates, so the stamp is visible without opening the audit log.
- The statutory rule versions printed on the payslip, and the employee’s name and number held on the payslip as they were at calculation.
- A worked-days check before payment, warning when a full basic salary is about to be paid against a locked month with no days worked and no leave.
Where we point you to a specialist
- We do not sign off a payroll as compliant, and we do not file or remit anything to any authority on your behalf. The figures, the evidence and the decisions are yours and your auditor’s.
- We do not decide what counts as a reasonable control for an organization of your size. The Access Conflicts screen shows the overlaps; whether to accept one with a compensating review is a judgement for your auditor and your board.
The approver rule and the variance report are the two an auditor will ask about first, and both sit on records that already exist: each run already stores who calculated it and each payslip already stores its figures, so the work is comparison and presentation rather than new data.
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 needsFour questions to ask any payroll system before the audit
If I reprint a payslip from last year, what is it calculated on?
What you will probably hear
It uses the employee’s details.
How to read it
Ask whether that means the details then or the details now. A payslip that recalculates on today’s rates and salary is a new document with an old date on it.
How do I see that someone changed an employee’s bank account?
What you will probably hear
It is in the audit log.
How to read it
Ask whether the old account still exists anywhere once the new one is saved. If the change overwrote it, the log can tell you that something changed but not what it was.
Can the same person calculate and approve a run?
What you will probably hear
You control that with roles.
How to read it
Ask whether anything shows you who holds both today. A control nobody can list is one an auditor has to take on trust.
See HR and payroll in AWRA
Payroll runs that lock on approval, payslips that keep their own figures, and an audit trail that shows when it has been tampered with.
Explore payrollFrequently asked questions
Can anyone edit a payroll run after it has been approved?
Not in place. An approved run refuses recalculation, changes to its entries and settlement figures, and being discarded. Someone with the approval permission can reopen it before it is posted, and that reopening is recorded. Once it has been posted and marked paid, it cannot be reopened or posted again.
How does AWRA help with a ghost employee test?
A regular run only pays people with an active contract carrying a basic salary and a locked timesheet for the month, and lists anyone else as skipped with the reason. For each person paid you can follow the payslip to the contract, the locked timesheet and its summary of days worked, the record of who created the employee, and the payment line showing the last four characters of the account paid to.
Does the system show who changed an employee’s bank details?
Yes. Payout details are added as new records rather than edited, so the earlier account remains on the employee, and each record stores who added it and when. Adding, making primary and removing are all written to the audit log, and every time someone reveals a full account number that viewing is logged too.
Will an old payslip change if tax rates or salaries change later?
No. Each payslip stores its own figures and lines at the moment of calculation and records the statutory rule versions it used. A reprint renders those stored figures. The only things taken from today’s records are the employee’s name and number.
Can the same person run and approve payroll?
They can if their role holds both permissions. The Access Conflicts screen flags that combination as high severity so it can be seen and reviewed. A rule that refuses the calculator as approver of the same run is something we can add as a workspace setting.
Is there a report comparing two payroll runs?
The Payroll Summary report compares runs at the level of headcount, gross, deductions and net, with CSV and PDF export. A person-by-person comparison of two runs is something we can add; today it is done by reading the two runs’ payslips alongside the audit log for the dates between them.
