Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
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
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.
live The default. Figures are computed fresh every time the screen loads, from whatever attendance and approved overtime currently exist.
reviewed A supervisor has looked at it and signed it off. That is a statement about review, not about immutability.
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.
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.
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.
The write proceeds normally. Totals move, the month stays live.
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.
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.
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:
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.
These figures become pay, so here is exactly what the module does, and the work we would take on.
What AWRA OpsHub does today
More we can add to your workspace
Where we point you to a specialist
Overtime multipliers and weekly thresholds are the two most-asked items here, and both attach to work already in place — the hours are already approved, dated and snapshotted, so what is needed is the rate 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.
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.