Attendance Integration

Connecting a device to payroll is straightforward. Agreeing what the data means is not, and skipping that step is why integrations produce disputes rather than savings.

• What constitutes a present day, in hours or in some other test, and whether it differs by population.
• What a half day is, and whether it is defined by hours worked or by a leave application.
• How lateness is treated, including the grace period, and whether it has any pay consequence.
• What happens when someone works beyond the normal day, and whether that is overtime, compensatory off or nothing.
• How a day split across locations, or between field and office, is counted.

Each of these is a policy decision that payroll will encode. Where the policy is unwritten, the integration will encode whatever the configuration happens to do, and that becomes the policy by default without anyone choosing it.

An ordinary day where someone arrives, works and leaves needs no attention. The integration exists for everything else.

The last two produce most of the reconciliation effort in practice, because they involve two systems making claims about the same day and neither being obviously wrong.

Capture fails. Devices break, networks drop, phones run out of battery, and people forget. In each case the person worked and the record says otherwise.

An integration without a regularisation route converts every technical failure into an attendance mark against someone who was present, which is both unfair and corrosive of trust in the whole system.

• Allow a correction request with a stated reason and a named approver, recorded rather than done quietly in the back end.
• Set a window for raising it, so corrections land before payroll cut-off rather than after.
• Report regularisation volume by team and by cause. A team with high volume usually has a device problem or a capture method that does not suit its work.
• Do not require the employee to prove a negative when the failure was the system's.

The third point turns regularisation from an irritation into a diagnostic. Persistent corrections at one site are telling you something about the hardware or the roster rather than about the people.

Payroll runs to a cut-off, and attendance corrections arrive continuously, so some of them will always arrive late.

The decision to make in advance is what happens to a correction that arrives after cut-off: whether it is adjusted in the following period, held and paid retrospectively, or triggers an off-cycle payment. All three are defensible and only one should be the practice.

Where corrections routinely arrive late, the cause is usually the cut-off being too close to the period end for approvals to complete, rather than employees being slow. Moving the cut-off, or moving the approval step earlier, fixes more than chasing does.

It also matters that employees know which period a correction will affect, since an adjustment appearing a month later without explanation reads as an error.

A workforce spanning offices, sites, field roles and hybrid working cannot use one capture method sensibly. Biometric readers suit fixed locations, mobile capture suits field work, and self-declaration suits roles where presence is not the point.

What must be consistent is not the method but the downstream definition. A day of work should mean the same thing regardless of how it was recorded, and pay consequences should not differ because someone was captured by a different mechanism.

Where they do differ, employees notice quickly and read it as one group being trusted and another being monitored, which is usually accurate and rarely intended.

The related question is what happens to the data. Location-based capture in particular raises questions about tracking outside working hours that are better answered in the policy than in a grievance, and the entries covering data protection deal with the obligations.