Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
Timesheets & overtime
A month you can close, and a payroll that will not run until you have.
Attendance and approved overtime roll into one monthly timesheet per person. Review it, lock it, and the month freezes to its own snapshot — with six separate write paths checking that lock before they touch anything, and payroll refusing to calculate against a month you have not closed.
Roster-aware expected hours · Open → approved → locked · Bulk approve & lock a month · Overtime logged or auto-detected
21Days worked
1Absent
2On leave
176.5Hours worked
9.75Overtime (approved)
176.0Expected
Shift for the month Rotating
Expected hours is roster-aware. Those 176 hours are not twenty-two times eight — each working day counted the expected hours of whichever shift the roster gave that person on that specific date. A month of mixed days and nights totals correctly.
Three states, one direction
Open, approved, locked — and only the last one freezes.
The distinction between the middle state and the last one is the part worth reading, because "approved" and "locked" sound like synonyms and behave completely differently.
Open
live The default. Figures are computed fresh every time the screen loads, from whatever attendance and approved overtime currently exist.
- Attendance can be recorded, imported, clocked and corrected freely
- Overtime can be logged and approved
- The month's totals move as the records move
Approved
reviewed A supervisor has looked at it and signed it off. That is a statement about review, not about immutability.
- Records the fact that somebody checked the month
- Underlying attendance is still editable — approval is not a freeze
- The right state for "reviewed, awaiting the last correction"
Locked
frozen + snapshot The month is stored as a snapshot and its source records close to change. From here on the figures are read from the snapshot, not recomputed.
- Six write paths refuse to touch the month
- Payroll will now calculate against it — and only now
- Reopenable, by someone holding the approval permission
Why a snapshot rather than a recomputation? Because the figures a payslip was built on need to still exist in the form they were in when the payslip was built. If a locked month kept recomputing, then correcting a single attendance record a year later would quietly change what last July's timesheet says — and the payslip that came out of it would no longer be explicable from the data behind it. A snapshot means a payslip can always be traced back to the exact figures that produced it.
The whole month can be moved at once: approve all, or lock all, for every employee in one action, with a count of how many were affected. For an organisation of two hundred people, closing a month is two clicks rather than four hundred.
What a lock is worth
Six ways in, one guard, and it is the same guard for all of them.
A lock that only some code paths respect is not a lock — it is a suggestion with a padlock icon. Every route that could alter a locked employee-month asks the same question first.
Manual registerAn administrator typing attendance directly
Clock-in and clock-outIncluding from the app and the site kiosk
Bulk importA spreadsheet of attendance, row by row
Correction approvalApproving an employee's regularisation request
Logging overtimeCreating a new overtime record for a date
Approving overtimeTurning a pending record into an approved one
Is this month locked? One shared check, asked by every path, working from an explicit workspace so it holds even from the public kiosk endpoint
Open
The write proceeds normally. Totals move, the month stays live.
Locked
Refused, with a message that names the month: "This period is locked (July 2026). Reopen the timesheet to make changes." Not a silent skip and not a generic error.
Two details in there matter more than they look. The first is that the message names the period and tells you what to do about it — because the person hitting this wall is usually a clerk on a deadline, and "422 Unprocessable" costs somebody an afternoon. The second is that the check works from an explicit workspace rather than from whoever is signed in, which is what lets it hold on the site kiosk endpoint where nobody is signed in at all. A guard that only works for authenticated requests would have left the one unauthenticated write path wide open.
For bulk operations there is a companion: a list of which employees' months are locked, so an import of four hundred rows can skip the locked people and process everyone else rather than failing the whole file on one closed month.
The reason the lock exists
Payroll refuses to guess.
When payroll assembles a payslip it needs two things from attendance: approved overtime hours, and unpaid leave days. It gets the overtime from the locked month's snapshot. If the month is not locked, it does not compute the figure from live data instead — it stops.
Timesheet for A. Otieno / 2026-07 must be locked before payroll can calculate. That refusal is the whole design, and it is worth defending because a fallback would be so much friendlier. A pay figure computed against attendance that can still change defeats the entire point of locking. If payroll silently used live figures, then somebody correcting a clock-in three days after payday would leave you with a payslip that no longer reconciles to anything, and nothing anywhere would tell you it had happened. The awkward error message is the feature.
There is exactly one bypass, and it is explicit: a preview calculation, for seeing what a run would look like before the month is closed. Preview does not produce a payslip, so nothing that has to reconcile later is created from unfrozen data.
One precise detail worth knowing, because it shows how carefully this seam is drawn: the snapshot's leave figure is a raw day count that does not distinguish paid from unpaid leave. So payroll does not use it for that. Unpaid leave days are queried directly from approved leave requests against leave types marked unpaid, overlapping the period — because using a number that nearly means the right thing is how a payroll gets quietly wrong.
Overtime
Two routes in, one approval, and nothing self-approves.
Whether a person typed it or the platform detected it, an overtime record arrives pending and stays pending until somebody with the authority decides. Recording and approving are separate permissions on purpose.
An employee and a date, hours between a quarter of an hour and twenty-four, and a reason. Quarter-hour granularity because "he stayed a bit late" is not a payroll input and fifteen minutes is.
The approval decision carries the decider, the moment and a comment — so a rejected claim has a reason attached to it rather than just disappearing, which is the difference between a control and a grievance.
The queue filters by status, with a live count per status, so "what is waiting on me" is the first thing on the screen rather than something to search for.
For each day in a month, the platform compares hours actually worked against the expected hours of the shift the roster gave that person on that specific date — not a flat daily figure, so a night worker is measured against their night shift.
Anything over the threshold of a quarter of an hour becomes a pending record for the excess, and the reason it writes shows its working:
Auto-generated reason "Auto-derived from attendance (worked 9.75h vs 8h shift)."
It skips any day that already carries an overtime record, so it is safe to run again and again — and it skips employees with no shift at all, because there is nothing to measure them against.
Runs on the 2nd Automatically, at 01:45, for the month just ended — so the queue is waiting when somebody starts the close.
Idempotent Re-running never duplicates. Days that already have a record are left alone.
Scopeable Can be run for one workspace or one specific month on demand, not only on the schedule.
Runs once On one server only, without overlapping itself — so a scaled-out deployment does not detect the same overtime twice.
Straight answers
What timesheets do today — and what we can add to yours.
These figures become pay, so here is exactly what the module does, and the work we would take on.
What AWRA OpsHub does today
- A monthly timesheet per employee rolling up days worked, absent and on leave, hours worked, approved overtime and expected hours
- Roster-aware expected hours — every expected working day counts its own shift's hours rather than a flat daily figure, so a mixed month of days and nights totals correctly
- Three states — open, approved, locked — where locking freezes the month to a stored snapshot rather than recomputing it
- Six write paths that all check the lock: manual register, clock-in and out, bulk import, correction approval, overtime logging and overtime approval
- A refusal message that names the month and says what to do, rather than a generic error or a silent skip
- The lock check working from an explicit workspace, so it holds on the unauthenticated site kiosk endpoint too
- A bulk skip list so an import of hundreds of rows processes everyone whose month is open instead of failing on one closed month
- Payroll that refuses to calculate against an unlocked month rather than falling back to live figures, with preview as the one explicit exception
- Unpaid leave days for payroll queried directly from approved leave against unpaid leave types, rather than taken from a day count that does not distinguish paid from unpaid
- Approve-all and lock-all for a whole month in one action, reporting how many were affected
- Reopening a locked month, gated behind the timesheet approval permission
- Overtime logged by hand with quarter-hour granularity, a reason, and a decision carrying the decider, the moment and a comment
- Overtime auto-detected from attendance against the roster, writing a reason that names both the hours worked and the shift compared against
- Detection that is idempotent and scheduled — the 2nd of each month at 01:45, once, without overlapping, and re-runnable for any month or workspace on demand
- Separate permissions for viewing, approving timesheets, recording overtime and approving overtime
- A Rotating label on the month for anyone with roster overrides, rather than a single shift name that would be wrong for half their days
- Approved overtime priced through payroll, once switched on in HR settings — split by the kind of day it fell on and paid as an earning line each for working-day, rest-day and public-holiday overtime
- A multiple per kind of day that you set between 1 and 10, an hourly rate of full basic salary over the run’s standard working days times your hours per day, and overtime taxable or pensionable as you choose
- A month locked before the split existed re-split from its approved records, or paid at the working-day multiple when those records no longer match the locked total
More we can add to your workspace
- Overtime multiples per employee or per contract, and a night premium, on top of the organisation-wide working-day, rest-day and public-holiday multiples
- An overtime cap per employee or per period, with a warning or a block when approved hours pass it
- Daily and weekly overtime thresholds, so hours past forty in a week or eight in a day trigger on their own rules rather than only against the shift
- Employee-submitted overtime claims from self-service, so the person who worked the hours starts the record
- Multi-level timesheet approval routing — supervisor then department head then HR — with a visible position in the chain
- A timesheet export to PDF and Excel, per employee and for a whole month
- A variance report across the workforce, ranking expected against actual so the outliers surface without opening each sheet
- Time off in lieu as an alternative to paid overtime, with a lieu balance that accrues and is drawn down
- Break and meal deduction rules beyond the flat break on a shift — automatic deduction past a worked-hours threshold
- Clock rounding rules, to the nearest five or fifteen minutes, configured per shift
- Project and task time allocation on the same timesheet, so an employee's month splits across cost centres
- A notification to the employee when their month is approved or locked, and a copy of the sheet they can keep
- Locking a period for a whole department in one action rather than a whole workspace or one person
- An audit view of lock history — who locked, who reopened, and when, for each month
Where we point you to a specialist
- Overtime rates and thresholds come from your contracts and your local labour law. The multiples in HR settings start as a common starting point rather than any country’s law, and overtime pay ships switched off, so nothing is paid on a figure you did not choose.
- Whether a particular hour is compensable is an employment-law question with real consequences, so it stays with the people accountable for it. Tell us the rule and we will apply it every time without exception.
- We will not approve overtime automatically on your behalf. Detection creates a pending record and a person decides — a control that approves itself is not a control.
- We will not make it easy to alter a locked month behind a supervisor's back. Reopening is a permissioned, visible act, and that is deliberate.
Per-contract overtime rates and weekly thresholds are the two most-asked items here, and both attach to work already in place — the hours are already approved, dated, snapshotted and priced by kind of day, so what is needed is the rule on top. Tell us your contracts’ terms and we will come back with a written spec, a timeline and a price.
One sequencing point to plan around: approving a month is a review, not a freeze — attendance stays editable until you lock it. If your process treats sign-off as final, lock rather than approve, because only locking closes the underlying records and only locking satisfies payroll.
Either side of the timesheet
Where the hours come from, and where they go.
Shifts & Rosters The expected hours every figure here is measured against, and why night shifts are declared rather than deduced. Attendance The clock events, the manual register, the bulk import and the correction flow — four of the six paths through the gate. Payroll What consumes a locked snapshot, and what it does with the overtime hours in it. Leave Where the unpaid leave days come from — queried directly rather than read off the snapshot. Sites & Geofencing The evidence behind a clock event, and the kiosk endpoint the lock has to hold on. Project Time Time logged against project work, which is a separate record from the attendance day.
Questions, answered
Timesheets & overtime FAQ.
What is the difference between approving and locking a month?
Approving records that somebody reviewed it. Locking freezes it — the month is stored as a snapshot, six write paths start refusing to touch it, and payroll will calculate against it. If your sign-off is meant to be final, lock rather than approve.
Why will payroll not just use the current figures?
Because a pay figure computed against attendance that can still change cannot be reconciled later. If payroll fell back to live data, a clock-in corrected after payday would leave a payslip that no longer explains itself, silently. So it stops instead, and names the employee and month that need closing.
Can I see what payroll would produce before I close the month?
Yes — that is what preview is for. It is the one explicit bypass of the lock requirement, and it deliberately does not produce a payslip, so nothing that has to reconcile later is created from unfrozen figures.
How does expected hours work for someone on rotating shifts?
Each expected working day counts the expected hours of whichever shift the roster gave that person on that date. So a month mixing eight-hour days and ten-hour nights totals correctly, and the timesheet labels that person Rotating rather than naming one shift that would be wrong for half the month.
Does the platform approve detected overtime automatically?
No. Detection creates a pending record with a reason showing its working — the hours worked and the shift compared against — and a person with the approval permission decides. Recording and approving are separate permissions.
Are overtime hours paid at a premium rate?
Yes, once you switch overtime pay on in HR settings. Each payroll run then prices the approved hours from the locked month as an earning line for each kind of day — working day, rest day and public holiday — at the multiple you set for it, from an hourly rate of full basic salary over the run’s working hours. It ships switched off; with it off, the hours reach the payslip as recorded hours and nothing is added to pay. Night premiums and per-contract rates are in the middle column above.
What happens when I import attendance and some months are locked?
The locked employees are skipped and everyone else is processed, rather than the whole file failing on one closed month. For single-record writes you get a clear refusal naming the month instead.
Can a locked month be reopened?
Yes, by someone holding the timesheet approval permission. It returns to live figures so corrections can be made, and it has to be locked again before payroll will calculate against it.
Ready when you are
Close the month once, and have it stay closed.
A snapshot payroll can rely on, six write paths that respect it, and a refusal rather than a quiet fallback when somebody tries to run pay against a month that is still moving.