The Hour the Auditor Picked
A project cost report is a total. An auditor does not test totals — they pick five lines and ask to see the hour behind each one. What the record can show for that hour, and how to have it ready before they ask.
The donor’s auditor has the cost schedule open on one screen and a pen in her hand. She has ticked five lines, apparently at random. The first is 37.5 hours, field coordination, March, charged to the water project at the project’s staff rate. “Show me these hours,” she says. “Who worked them, who entered them, when they were entered, who approved them, and where the rate came from. And tell me whether anything about them changed after the invoice went out.”
The project manager knows the work happened. She was there. But that question is answered entirely by what the system kept when somebody typed in those hours, and by what it refused to let anyone do to them afterwards. This post walks through the sample test as it plays out in AWRA OpsHub: where each answer lives, which answers are strong, and which to prepare before the auditor arrives.
What a sample test is actually testing
Labour is usually the largest and softest number on a project cost report. Purchases have a supplier on the other end; hours have only the person who typed them. So an auditor rarely recomputes the labour total. They pick a handful of entries and test each against five properties, and one weak answer is enough to widen the sample.
| The auditor asks | What they are testing | Where the answer lives here |
|---|---|---|
| Who worked these hours? | The charge belongs to a real person on this project | The time entry itself, shown on the task |
| Who entered them, and when? | Contemporaneous recording, not reconstruction | The entry’s logged-at time and the audit log |
| Who approved them? | Someone other than the claimant reviewed the period | The person’s locked timesheet month |
| At what rate, from where? | The rate was set by policy, not chosen per line | The rate copied onto the entry from the project |
| Changed after invoicing? | The charge on the report is the charge that was billed or paid | The refusals on removal, and the audit log |
Who worked it, and who typed it
Every time entry keeps two people apart. One is the employee who did the work. The other is the account that logged it. They are usually the same — the form defaults the worker to the logger’s own employee record — but a coordinator entering hours for a field team, or a manager catching up on someone’s week, will produce entries where they differ, and the entry keeps both.
On the task page, each entry shows the hours, the date the work was done, the worker’s name, the cost when a rate applies, the note and whether it is billable. The account that logged it is not printed there; it is held on the entry, and the act of logging it is in the audit log — the account, the time, the address it came from and the task it was logged against. Entries logged from the mobile app go through the same rules, and a queued entry that is retried after a lost connection is recognised by its one-time key rather than logged twice.
When it was worked, and when it was written down
Every entry carries two dates, and the distance between them is what the auditor is really asking about. The work date is the day the hours were worked, chosen by the person logging. The logged-at time is when the entry was saved, set by the system and not editable by anyone. Hours logged the same week are a record; hours logged four months later, the week before the grant report, are a reconstruction, and a reconstruction needs its own evidence.
Reading one sampled entry
A late entry is not wrong in itself, and the system does not refuse one while the month is still open. What makes it defensible is the evidence it was copied from, which is why the lock date matters as much as the entry date.
You can run this test across a whole project before anyone else does. The custom report builder has a Task Time Entries dataset with the work date and the logged-at time side by side, filterable by period and exportable to a spreadsheet, where the gap is one subtraction. Sort by it, and the entries that will draw questions are at the top.
Who approved it, and what approval holds
Here precision matters, because the honest answer is narrower than most people assume. Project hours are not approved one entry at a time. The control that governs them is the person’s timesheet month in HR: a manager approves the month, then locks it, and each step records who did it and when.
-
Approve the month
Stamps the approver and the time, and freezes the month’s attendance and overtime figures for payroll. Approval on its own does not yet stop project time being added.
-
Lock the month
Stamps who locked it and when. From that moment, project time for that person cannot be logged into that month or removed from it, on the web or in the app. The refusal names the month and says to reopen the timesheet first.
-
Reopen only when it is still safe
A locked month can be reopened, and the reopening is written to the audit log with the period’s previous approval and lock stamps. Once the payroll run for that month is approved or paid, reopening is refused outright.
So the defensible answer to “who approved these hours?” is: the month they fall in was locked by a named person on a named date, and nothing has been added to it or taken from it since. Two edges are worth knowing. An entry with no employee behind it, which happens when the logger has no employee record, has no timesheet to be locked by. And the frozen timesheet figures are attendance figures; project hours in a locked month are protected by the lock rather than copied into it.
The auditor is not asking whether the work happened. She is asking whether the record would look any different if it had not.
The rate, and where it came from
This is the strongest answer in the set. The cost rate on a time entry is never typed by the person logging time. It is copied from the project’s cost rate at the moment the entry is saved and kept on the entry, so a later change to the project’s rate does not reprice hours already logged. The bill rate works differently on purpose: it also defaults from the project, but can be set on an individual entry, because a client can agree a different price for a particular piece of work. Work Done and Not Yet Asked For covers what that does to the billing side.
One entry across a rate change
The one exception: hours logged while the project had no cost rate at all carry no rate of their own, and are priced at whatever the project’s rate is when the report is run. The project page warns when hours exist with no cost rate. Set the rate before the first hour is logged and the exception never arises.
The auditor’s follow-up will be “and where did 40.00 come from?” That answer is outside the time entry. The change to the project is in the audit log as an update by a named account at a named time, but the log records that the project was edited, not the old and new rate. Keep the rate-setting decision — the salary scale, the donor-approved rate card, the board minute — with the project, and the trail from entry to policy is complete.
Changed after it was invoiced or paid?
A time entry has no edit path at all. Hours, date, worker and rates are fixed when it is saved; a correction is made by removing the entry and logging a new one, and both acts land in the audit log. Removal is then refused in three situations, identically on the web and in the app:
- Once the hours are on an invoice. Billing a project’s time stamps each billed entry with that invoice, and a stamped entry cannot be removed; the message says to credit the invoice instead.
- Once the hours are paid out. Posting a project payout stamps the entries it paid, and those cannot be removed either. How payouts reconcile is in Paying the People Who Did the Work.
- Once the person’s month is locked, as above.
Two behaviours need to be in your explanation if the auditor’s sample lands on them. Cancelling an invoice that was generated from project time releases its hours, so they can be billed again on a corrected invoice — which is the right outcome, but it means the entry itself no longer shows it was once billed; the cancelled invoice still does. And a removed entry is recorded in the audit log as a removal of that entry by that account at that time, without its hours and rates. If your organization corrects time by removal, keep the reason with the task.
Archive tasks after the report, not before
Archiving a task that has hours logged against it takes those hours out of the project’s cost figures and the profitability report, while the Timesheet & Billable Hours report still counts them. A task with logged time cannot be permanently deleted, so the hours are never lost — but two reports that disagree mid-audit are worse than either one alone. Leave tasks with logged time in place until the period has been reported and audited.
Every other line on the cost report
A project’s actual cost here is four things added together, and the auditor will sample the other three too. Each one counts only from a defined point in its own approval chain, so a cost on the report always has a document behind it with a status that says it was committed. Four Costs, and Payroll Is Not One of Them explains the composition; this is the tracing view.
| Cost line | Counts once | Valued at | Trace it from |
|---|---|---|---|
| Labour | The entry is saved | Hours × the rate kept on the entry | The task, then the entry |
| Purchases | The purchase order is approved or completed | The order total | The project page links each order; every change to an order is logged with old and new values |
| Expenses | The expense is past approval; pending and rejected ones never count | The expense amount | The expenses list filtered to the project, with receipts attached to each |
| Material from stock | The issue is completed, not merely requested | The unit cost stamped when the stock left | The work in progress by job report, per movement |
One consequence for the sample: purchases count at the order total once approved, before the supplier’s bill arrives, so if your funder reimburses on paid invoices, reconcile the orders to their bills before the visit.
Preparing for the sample, the week before
Where each answer for a sampled hour can be read today
| For one entry | Task page | Audit log | Entries export |
|---|---|---|---|
| Who worked it | Yes | No | No |
| Which account logged it | No | Yes | No |
| Work date | Yes | No | Yes |
| When it was logged | No | Yes | Yes |
| Cost rate applied | Partly — configurable by you | No | No |
| Invoice or payout it went to | No | Partly — configurable by you | No |
Built and maintained Configurable by you, not maintained by us Not built
The task page shows the cost an entry carries rather than its rate, and the audit log records that an invoice or payout was raised rather than which hours it took. Assembling the answers for twenty sampled entries is work for the week before the visit.
-
Lock every month in the audit period
For every person who logged project time, lock the timesheet month once it is complete. A month locked on the fifth of the following month is a far better answer than one locked the day before fieldwork.
-
Run the lateness test yourself
Export Task Time Entries from the report builder for the period, subtract the work date from the logged-at time, and find the source sheets for anything late before the auditor sorts the same column.
-
Freeze the cost report and keep the file
Export the Timesheet & Billable Hours report for the period as a spreadsheet and a PDF, and keep it with the project. Exports are themselves recorded in the audit log.
-
Export and verify the audit log
Export the audit log for the period with its chain columns and run the chain verification, so you can show that the record of who did what has not been altered since. The Audit Trail That Leaves the Building covers handing that log to someone outside.
-
Put the rate decision with the project
Attach the rate card, salary scale or approval that set each project’s cost rate, dated, so the answer to “where did this rate come from” is a document rather than a recollection.
Five questions to put to any system that charges time to projects
Can the person logging time choose the cost rate?
What you will hear
Often yes, through a rate field on the entry form.
How to read it
Then every cost on the report is as good as the last person’s judgement. Look for the cost rate to be copied from a policy source and kept on the entry, with only the billing price open to override.
Does a rate change reprice hours already logged?
What you will hear
It depends on when the report is run.
How to read it
A report that gives a different answer next month for the same past hours cannot be audited. Ask what happens to entries logged before any rate was set.
What happens if I try to change hours that have been invoiced?
What you will hear
A warning, or nothing at all.
How to read it
The right answer is a refusal that points you to a credit note, applied the same way in the mobile app as on the web.
Can I see when each entry was typed, not just the day it claims?
What you will hear
Only the work date.
How to read it
Without the save time there is no way to tell a record from a reconstruction. Ask for both, in an export you can sort.
What stops a closed month being quietly reopened?
What you will hear
A permission.
How to read it
A permission decides who may reopen. Look for the reopening itself to be recorded with the previous approval, and refused once payroll for the month is final.
What AWRA OpsHub does today
- Cost rate copied from the project onto every entry at the moment it is saved; the person logging time never types it.
- Worker and logging account kept separately on each entry, with the save time stamped by the system.
- Removal refused once hours are invoiced, paid out or in a locked month, identically on the web and in the mobile app.
- Timesheet approve, lock and reopen with the approver and locker named, and reopening refused once that month’s payroll is approved or paid.
- A hash-chained audit log of every create, change, removal and export, with verification and an export that carries the chain.
- Four cost routes that count only once committed: approved purchase orders, approved expenses, completed stock issues at their stamped cost, and logged time.
More we can add to your workspace
- An entry-level sample export with worker, logging account, task, project, work date, save time, cost and bill rate, and the invoice and payout each hour went to.
- Approval of project hours by week or by project, with the approver stamped on each entry, alongside the timesheet month lock.
- A late-entry flag when hours are logged more than a set number of days after the work date, with a reason required past that point.
- A rate history on each project, recording who changed the cost or bill rate, from what, to what, and when.
- A kept copy of every removed time entry, with its hours and rates, beside the removal in the audit log.
- Billing history retained on an hour after its invoice is cancelled, so a re-billed entry shows every invoice it has been on.
- Archived tasks’ hours kept in project cost and profitability, so archiving a task leaves every reported figure where it was.
- Separate preparer and approver on project payouts, so the person who drafted a payout is refused when they try to approve it.
Where we point you to a specialist
- We do not decide which hours or costs are allowable under your grant or contract. That is a judgement for your finance team and your funder, and the record supports whichever rule you apply.
- We do not express an audit opinion. The system produces evidence; the auditor decides what it proves.
The first two items in the middle column work as a pair: an entry-level export is most useful once each hour also carries its own approval stamp.
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 needsSee how time and cost reach a project
Time logged against tasks at a rate the project sets, budgets measured against actual cost from four sources, and invoicing that refuses to bill the same hour twice.
Explore project time and budgetFrequently asked questions
Can a person choose the cost rate when they log time to a project?
No. The cost rate is copied from the project at the moment the entry is saved and kept on the entry, so the person logging time never sets it and a later change to the project rate does not reprice past hours. The bill rate can be set on an individual entry, because a client can agree a different price for particular work. The one exception is hours logged while the project had no cost rate at all, which are priced at the project rate in force when the report is run, so set the rate before the first hour is logged.
Can project time be edited after it has been invoiced?
A time entry has no edit path at all; a correction is made by removing the entry and logging a new one. Removal is refused once the hours are on an invoice, once they have been paid on a project payout, or once the person’s timesheet month is locked, on the web and in the mobile app alike. To correct invoiced hours, credit or cancel the invoice; cancelling it releases the hours so they can be billed correctly.
Who approves project hours?
Project hours are governed by the person’s timesheet month in HR. A manager approves and then locks the month, and both steps record who did it and when. Once locked, project time cannot be logged into or removed from that month until it is reopened, and reopening is recorded in the audit log and refused once that month’s payroll is approved or paid. Approval of individual project entries by week or by project is something we can add to your workspace.
How can I show when hours were entered, not just the day they were worked?
Every entry carries the work date chosen by the person logging and a logged-at time stamped by the system on save. The custom report builder has a Task Time Entries dataset with both columns, which you can filter by period and export to a spreadsheet to calculate the gap for every entry before an auditor does.
What counts as actual cost on a project report?
Four things: logged time at the rate kept on each entry, purchase orders once approved or completed, expenses once past approval, and stock issued to the project at the unit cost stamped when it left the store. Pending and rejected items never count, so every figure on the report has a committed document behind it that can be traced from the project.
Is the audit log itself tamper-evident?
Yes. Every entry in the audit log is hash-chained to the one before it, the chain can be verified from the audit log screen, and the export carries the chain columns so someone outside your organization can check the rows link up without access to the system.
