Two Clocks That Never Meet
An employee's hour is recorded twice here — once as attendance that becomes pay, and once as effort that becomes project cost. The two systems share no key, so nothing can compare what you paid for against what you billed.
The position, stated first
Attendance time and project time are two separate systems in this product and they do not join. Each works well on its own. What does not exist, and cannot be reported, is the relationship between them — utilisation, recovery, or whether the hours you paid for are the hours you billed.
Ask a services business what its most important number is and most will say utilisation: the share of the hours you pay for that you can charge somebody else for. It is a ratio between two systems, and a ratio between two systems is only as good as the key that joins them.
The two systems
One person, one hour, two records
Attendance
Becomes pay
- Clock in and out, kiosk, device or manual register
- Grouped into timesheet periods
- Locked when the period closes
- Feeds payroll
- Belongs to an employee
Project time
Becomes project cost
- Logged against a task
- Carries a bill rate and a cost rate
- Not subject to the period lock
- Feeds project cost and invoicing
- Belongs to a project
Both are real, both are used, and no query in this product puts them side by side.
They were built for different purposes by different reasoning, and each is coherent. Attendance answers "was this person at work". Project time answers "what was this job worth". Those are genuinely different questions.
The trouble is that a business asks a third question that needs both.
The same hour exists twice and the two copies have never been introduced.
What that forecloses
| The question | Needs | Answerable |
|---|---|---|
| Was this person at work in March? | Attendance only | Yes |
| What did this project cost in labour? | Project time only | Yes |
| What proportion of paid hours were billable? | Both, joined | No |
| Did we bill every hour we paid for? | Both, joined | No |
| Is anybody logging project time on a day they were absent? | Both, joined | No |
| What did payroll cost this project? | Payroll, by project | No |
The last row is a separate absence that compounds this one: a payslip carries no project, so payroll cost cannot be attributed to a job even in principle. Project labour cost is computed from logged hours multiplied by a project rate — which is an estimate of what the work cost, not a share of what was actually paid.
The lock, which is where this stops being theoretical
The timesheet period lock is enforced thoroughly on the attendance side — web and API clock in and out, the public kiosk, passkey devices, the manual register, and both overtime paths. That is a careful, complete implementation.
Project time consults it nowhere. Neither the web path nor the API path asks whether the month is closed.
So billable time can be logged into a month that has been closed and paid, and into a period that has already been invoiced, and nothing objects. There is an argument that this is correct — engagement time is sealed per entry by the invoice that consumed it, which is a different mechanism — but the two halves of one person's time obeying different rules about the same month is a thing to know rather than a thing to discover.
Two, and the first is the one that unlocks the number people actually want
Joining the two systems fully is a large project. Getting the reporting relationship is much smaller, and it is where nearly all the value is.
A reporting join on employee and date
Not a merge of the two systems — a dataset that puts attendance hours and logged project hours side by side per person per day. That single surface produces utilisation, recovery, and the discrepancy list showing project time logged on days somebody was not at work. It changes nothing about how either system captures time.
Payroll cost attributable to a project
A project on the payslip, so labour cost on a job can be a share of what was actually paid rather than hours multiplied by a standing rate. This is the larger piece and it is the one that makes job profitability real rather than indicative.
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. If you sell time, the first item is the one to raise before a trial.
Talk to us about time and utilisationWhat AWRA OpsHub does today
- Attendance capture across web, API, public kiosk, passkey devices and a manual register.
- Timesheet periods with a lock enforced on every attendance write path, including both overtime paths.
- Project time logged against tasks, carrying a bill rate that can be set per entry.
- Project cost assembled from logged time, issued stock at stamped issue-time cost, and attributed expenses.
- A configurable working week resolved through one calendar service.
What it does not do
- Any join between attendance time and project time. They share no key and no report puts them together.
- Utilisation, recovery or realisation as a figure anywhere.
- The timesheet period lock on project time — neither the web nor the API path consults it.
- A project on a payslip, so payroll cost cannot be allocated to a job.
- A per-entry cost rate — cost comes from the project's standing rate and cannot be overridden, while the bill rate can.
Not ours, by choice
- Each system is coherent on its own and this is not a criticism of either. The gap is that a business asks a question that needs both, and nothing in the product spans them.
- The absence of the lock on project time is arguably defensible, because an invoice seals engagement time by a different mechanism. It is still an asymmetry worth knowing about rather than meeting by surprise.
- Nothing here is Malaysian, Singaporean, Indonesian or Philippine. Southeast Asia is here because professional services and outsourced delivery are major employers there, and utilisation is the number those businesses are run on.
Four questions about time in a services business
Show me utilisation for last month.
A good answer sounds like
A percentage.
What it actually means
The fastest test there is. Ours cannot produce one, because the two hour-counts do not join.
Is attendance time and project time one system or two?
A good answer sounds like
They know, and say.
What it actually means
Two is common and fine. Two that cannot be compared is the thing to find out early.
Does the month-end lock apply to both?
A good answer sounds like
Yes, or a stated reason.
What it actually means
Ours applies to one. Asymmetric locking is how a closed month acquires new hours.
Is project labour cost actual or estimated?
A good answer sounds like
An honest answer.
What it actually means
Hours times a standing rate is an estimate. Calling it cost is where job profitability quietly becomes fiction.
Ask for the ratio, not the two numbers
Any system can tell you hours worked and hours logged. The one worth having tells you the relationship, and that is a question about keys rather than about features.
Talk about utilisation reportingFrequently asked questions
Can I export both and join them myself?
Yes, on employee and date, and it is the practical answer today. Watch for people who log project time in blocks against a week rather than a day, because that join silently loses them.
Why can project time go into a closed month?
Because the project side was built around invoices sealing entries rather than around periods closing, so it never consulted the period lock. Whether that is right depends on your process; what matters is knowing the two halves behave differently.
Is the bill rate really per entry?
Yes — the bill rate can be set on an individual time entry on both the web and API paths. The cost rate cannot be, at all, so an engagement's labour cost reduces to total hours multiplied by one project-level figure.
