Shift Rules, Overtime and Biometric Data Risk in Time & Attendance
Where the real complexity sits
Complexity lives in the rule engine, not the reader hardware. The same raw access data produces different attendance results depending on shift definitions, tolerance, break deductions, night work, weekly rest and public holiday rules. When those rules are not written down, the system looks as though it is "calculating wrongly" — what it is actually calculating is an undefined rule.
The rule set that must be written
- Shift definition: start and end, and which day a shift crossing midnight is booked to
- Tolerance: how many minutes late is not counted as late, and whether tolerance is deducted from working time
- Breaks: deducted at a fixed value or driven by reader events, and how an overrun is handled
- Rounding: if entry and exit times are rounded, in which direction and to how many minutes
- Missing punches: how a day is calculated when someone does not clock out, and who may correct it
- Overtime: the threshold at which it starts, whether it is daily or weekly, and whether it requires approval
The last item matters most: overtime calculated without approval converts extra time spent at the gate into pay, which is usually not the intended behaviour.
Missing punches and the correction log
Some punches will always be missing. The design must accept this: the day is flagged, routed to a manager, corrected — and the correction itself is logged, recording who changed which value to what, when, and why. A time and attendance system without a correction log cannot produce evidence in a dispute.
Biometric data: the highest-risk decision
Fingerprint and facial data are special-category personal data. The legal grounds for processing them are narrowly defined, and employee consent alone may not be accepted as sufficient given the imbalance of power in an employment relationship. A practical approach: evaluate non-biometric methods first (card, PIN, mobile verification); if biometrics are unavoidable, store an irreversible template rather than a raw image; always offer an alternative method and inform employees; and write down the retention period and destruction method, including a deletion step on departure. Because this decision has legal consequences, rely on the applicable legislation and authority guidance and confirm it with your legal adviser.
Payroll integration
The boundary is clear: time and attendance produces duration, payroll calculates pay. The fields that must cross are normal working time, overtime split by type, night working time, absence and leave types. The relationship with period closing also needs defining: does a correction made in a closed period carry into the next one, or is the period reopened?
Think about it together with leave management
Attendance is not correct without leave data. Annual leave, unpaid leave, sick leave and administrative leave are distinct types that affect attendance differently. Having requests and approvals in the system also makes missing-day analysis easier.
Frequently asked questions
Can clock-in be done from a mobile app?
Yes, supported by location verification or a check that the device is on the workplace network. The same verification trade-off is discussed in the [field sales guide](/en/blog/field-sales-tracking-guide). The same data-minimisation principle applies, because location is personal data here too.
How should shift changes be managed?
Shift assignments must be stored historically. Recalculating a past month with today's shift definition creates a mismatch with a payroll that has already closed.
Is overtime calculated daily or weekly?
That is a legislative and internal policy question, and the system should support both. The common mistake is hard-coding one method so it cannot be changed later.