AWRA OpsHub Search
Intermediate Certificate on pass

HR: Attendance & Time Tracking

Capture attendance three ways into one record, shape it with shifts and weekly rosters, handle overtime and correction requests, approve and lock timesheets so payroll is safe, and secure self-service clock-in with device, GPS, and QR verification.

5 lessons 50 min 5-question assessment 75% to pass

What you’ll learn

  • Choose among the manual register, self-service clock-in, and device import for a situation
  • Configure shifts and a weekly roster and explain how late detection and expected hours follow them
  • Handle overtime and correction requests, and approve/lock timesheets for a pay period
  • Explain how device, GPS geofence, and office-QR verification secure self-service clock-in

Course content

5 lessons · 50 min of reading
01
Lesson 1 of 5 Reading 10 min

Three ways to capture time, one record

Attendance capture is an input problem, and different teams need different answers, so AWRA offers three methods that all write to a single attendance record per employee per day. The manual daily register lets a supervisor pick a day and mark everyone — "mark all present", or set each person's status and clock times — which suits supervised sites. Self-service clock-in/out lets employees record their own time. CSV/biometric import ingests an export from a physical device. Because they share one record keyed by employee and date, the register, dashboards, timesheets, and payroll all read the same truth regardless of how a day was captured.

That shared record has a source marker (manual, clock-in, import, or system) so you can always tell how a day was captured, and a unique key on organisation, employee, and date so a day cannot be recorded twice. Import leans on that: it de-duplicates on employee and date, updating rather than duplicating, and a real clock-in always wins over a system-suggested value. This is what lets you mix methods safely — a mostly self-service team with a few days imported from a device will not produce conflicting rows.

The design lesson is to pick the capture method per team, not per company, and trust the single record to reconcile them. A head office might run self-service clock-in, a warehouse might import from a biometric reader, and a remote site might use the manual register — and all of it rolls up into the same timesheets. Decide capture first, because everything after this lesson assumes clean daily records exist.

Key takeaways

  • Three capture methods — manual register, self-service clock-in/out, CSV/biometric import — write to one record per employee per day.
  • A source marker records how each day was captured; a unique (org, employee, date) key prevents duplicates.
  • Import de-duplicates on employee+date and updates rather than duplicating; a real clock-in wins over a suggested value.
  • Choose the capture method per team; all methods roll up into the same timesheets.
02
Lesson 2 of 5 Practice 12 min

Shifts and the weekly roster

A shift defines the working pattern: start, end, break, and a grace period, which together give expected daily hours. The grace period is what makes late detection fair — an employee is flagged late only when they clock in after the shift start plus grace, and only a "present" day is upgraded to "late", so the rule is a no-op for someone with no shift. Assign a default shift to an employee and every day is measured against it.

Real teams rotate, so a per-date roster overrides the default. The weekly roster is a grid of employees by day; drop a shift into a cell to place a rotating shift, a half-day, or a night on a specific date, leaving blanks to fall back to the default. A single method resolves the shift for any employee on any date — roster override first, else default assignment — and that one resolver is the source of truth used by late detection, overtime derivation, and timesheet expected-hours alike. For large headcounts the roster adds copy-last-week, a department filter, and bulk fill, and nothing persists until you save.

Because one resolver answers "which shift applied on this date", the whole module stays consistent. A half-day rostered on a Wednesday is measured against its own expected hours, not the default shift's; overtime for that day compares actual hours to the rostered shift; and the timesheet's expected column sums each day's own shift. The habit to build is to roster before the week starts so late detection and expected hours are right from day one rather than corrected afterward.

Key takeaways

  • A shift (start/end/break/grace) sets expected hours; late = clock-in after start + grace, and only upgrades a "present" day.
  • The weekly roster overrides the default shift per date for rotations, half-days, and nights.
  • One resolver (roster override → else default) is the single source used by late detection, overtime, and timesheets.
  • Roster tooling includes copy-last-week, department filter, and bulk fill; nothing saves until you confirm.
03
Lesson 3 of 5 Practice 12 min

Overtime, corrections, and self-service clock-in

Overtime can be logged explicitly and approved, or auto-derived by comparing a day's actual hours to its rostered shift's expected hours; approved overtime feeds the timesheet. When a punch is missed, the fix is a correction (regularization) request: an employee files a correction for a past day — a status or clock times plus a reason — and once HR approves it, the requested values are written into that day's record as a system-sourced entry. This keeps a clear trail: the original capture, the request, and the approved correction are all distinct.

Self-service clock-in is available two ways. A signed-in employee uses "My Attendance" to clock in and out for today, see recent days, and track their own correction requests; hours and lateness compute automatically. Staff without accounts use the same tokenised PIN portal as leave — the "time" side of it — to clock in and out and file corrections, with no login. Both resolve the same employee and write the same record, so a mixed workforce is handled uniformly.

The operational point is that self-service does not mean unsupervised. Corrections still require HR approval before they change a record, overtime still requires approval before it counts, and — as the next lesson covers — clock-in can be gated by verification. Self-service moves the data entry to the employee while keeping the control with HR.

Key takeaways

  • Overtime is logged-and-approved or auto-derived from shift vs actual; approved overtime feeds the timesheet.
  • A correction (regularization) request fixes a past day and, once HR approves, writes a system-sourced value.
  • Self-service clock-in works signed in ("My Attendance") or via the same no-login PIN portal used for leave.
  • Self-service shifts data entry to the employee but keeps approval and control with HR.
04
Lesson 4 of 5 Reading 9 min

Timesheets: approve and lock

A timesheet rolls a pay period up per employee: days worked, absences, leave, hours worked, and approved overtime, with an expected-hours column that respects the roster. It is read-only by design because it is a view over the daily records — you fix the records, and the timesheet reflects them. This is the surface HR reviews before committing a period to payroll.

The commit is a two-step: approve, then lock. Approving snapshots the figures; locking freezes them, and from that point the snapshot is authoritative rather than the live data. A locked employee-month is protected everywhere — it blocks or skips edits to the register, overtime logging and approval, correction approvals, and self-service clock-in for that person and month. That immutability is exactly what makes payroll safe to run: payroll consumes locked periods, confident the numbers cannot shift underneath it. Reopening a period deletes the lock and returns it to live for corrections.

The workflow to internalise is review → approve → lock → run payroll, and only reopen deliberately. Approvals and locks can be done per employee or in bulk for the whole period. The reason locking is strict — no exceptions once locked — is that a payroll run must be reproducible; if a locked month could be quietly edited, a payslip and its underlying hours could disagree, which is precisely the class of error payroll cannot afford.

Key takeaways

  • A timesheet is a read-only per-employee roll-up of a period, with roster-aware expected hours.
  • Approve snapshots the figures; lock freezes them as authoritative over live data.
  • A locked employee-month blocks register/overtime/correction/clock-in edits — this makes payroll safe.
  • Reopening returns a period to live; locking is strict and no-exceptions so payroll stays reproducible.
05
Lesson 5 of 5 Reading 9 min

Verifying who and where clocked in

Self-service clock-in raises an obvious question: is it really that person, at the right place? AWRA answers with an optional verification layer that, once enabled for an employee, must pass before they can clock in or out. It combines up to three independent factors: a registered device passkey (WebAuthn), GPS geofencing against one or more assigned sites, and an office QR code. Verification is opt-in per employee and mirrors the self-service enablement pattern, so you roll it out to the teams that need it.

GPS distance is the anti-fraud backbone and is always computed on the server from the reported coordinates — never trusted as a yes/no from the client — so a spoofed "I am in range" flag does not pass. An employee assigned to several sites passes if they are within range of any one of them, adopting that site's rules (including whether it requires a QR). Someone with no site assigned is treated as field/remote and is device-verified without a geofence. The office QR comes in two forms sharing one secret: a rotating kiosk code that changes every 30 seconds to defeat photographed replay, and a static printable poster accepted as a deliberate trade-off because GPS and device checks remain independent.

A pragmatic guardrail keeps people from being locked out: removing an employee's last registered device auto-disables their verification, so they are never hard-blocked with no way to pass. Every attempt — pass or fail, with location, distance, matched credential, and reason — is logged separately from the attendance record, so the heavily-used daily table stays clean while you still get a full audit trail. The takeaway is that verification is layered and server-checked: convenience for the honest, friction for the fraudulent, and no dead ends.

Key takeaways

  • Verification is opt-in per employee and combines device passkey, GPS geofence, and office QR before a clock-in counts.
  • GPS distance is computed server-side, never trusted from the client; multi-site staff pass if near any assigned site.
  • Office QR has a rotating kiosk code (30s) and a static poster; no site assigned means device-only (field staff).
  • Removing the last device auto-disables verification (no lockout); every attempt is logged separately from attendance.

Finished the material?

Take the 5-question assessment and earn your certificate — 75% to pass.

Take the assessment

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center