Between the Clock and the Payslip There Is a Person With a Spreadsheet

Attendance is captured by a biometric terminal at the door, or an app on a phone, or a site register. It produces a stream of punches. At the other end, payroll needs hours by employee, by shift and by category. Between the two, in nearly every company, sits a person with a spreadsheet who exports the raw data, cleans it, applies a set of rules, and produces a figure.

That person is doing real and skilled work, and the problem is not their competence. It is that the rules they apply exist nowhere else. Rounding, grace periods, what counts as a late arrival, how a missed punch is treated, when a break is deducted, which hours are overtime and at what category, what happens on a public holiday, how site travel is handled — all of it is judgement applied consistently by one person and recorded nowhere. The result arrives two days before the payroll deadline, cannot be reproduced by anyone else, and cannot be audited at all. Those rules have to become configuration, and the exceptions have to become a queue somebody clears rather than decisions somebody makes silently.

The rules hiding in that spreadsheet, why the exceptions are the real workload, and the deadline problem sitting underneath all of it: that is what follows.

The rules that exist only in one head

Write these down for your own company and the size of the problem becomes obvious. Most organisations cannot complete the list without asking the person:

• Rounding. To the minute, to five minutes, to the quarter hour, and in whose favour at each end of the day.
• Grace. How late is late, and whether grace is per occurrence, per week, or discretionary.
• Missed punches. In, out, or both. Is the default a full shift, a zero, or a hold for approval? Each is a policy with a cost, and most companies have never chosen one.
• Breaks. Deducted automatically, punched, or by shift pattern.
• Overtime definition. Beyond the shift, beyond a daily threshold, beyond a weekly total, on a rest day, on a public holiday — and the categories are not interchangeable.
• Shift differentials, night work and split shifts.
• Public holidays, including those announced at short notice, which is a recurring regional reality that breaks any hard-coded calendar.
• Site and travel time, where the question of when the working day starts has usually been settled by custom rather than by policy.
• Multiple locations, where an employee punches at one site and works at another.

Two things to notice about this list. First, every item is a policy decision that somebody with authority should own, and in most companies it is being made by an administrator under deadline pressure. Second, each one has a cost attached, and nobody has priced the current answers. A grace rule applied generously across a large workforce is a real number, and it should be a decision rather than a habit.

The exceptions are the work

Once the routine rules are configured, the remaining effort is exceptions, and this is where most attendance implementations are under-scoped.

A workforce of any size produces a steady stream of missed punches, terminal failures, people at a site with no device, leave recorded in one system and absence in another, and overtime worked but not authorised. The system does not remove these — it makes them visible, which is an improvement and is not the same thing as making them disappear.

So the design that matters is the exception queue: every anomaly as an item, with an owner who is the employee's own supervisor rather than a central administrator, and a deadline before the payroll cut-off. Two properties decide whether it works.

The supervisor resolves it, because they are the only person who knows. A central administrator resolving exceptions is guessing, politely and at scale.

Unresolved exceptions have a defined default and it is visible. Not silently paid, not silently unpaid. A default nobody chose is the same as the spreadsheet, moved.

If the resolution is going to happen on a phone in thirty seconds, it will happen. If it requires a laptop and a login, it will be done in a batch at the end by somebody guessing, which is exactly the outcome being paid to avoid — the same dynamic as approvals that migrate to chat because the official route is slower.

The deadline that changed underneath everybody

The reason this matters more than it did is timing. The UAE wage protection framework was replaced in 2026, and the operational change is that the old grace period gave way to a single unified due date — the specifics, the instrument and its date are set out with their source in the piece on what UAE payroll demands of a system, and should be read from the Ministry rather than from a summary.

The system consequence is what concerns us here. A payroll process that took a week of working days after month end used to fit, because the grace period absorbed it. Remove that absorption and every weak link upstream becomes a compliance event — including this one, which is usually the weakest link of all, because it depends on data arriving from sites and on one person's availability.

Which reframes the business case. Automating the attendance-to-payroll bridge is not mainly an efficiency project. It is the removal of the largest single source of delay between the end of a month and a statutory payment date, and it should be argued on those terms.

What it is actually costing now

Four costs, and only the first is usually counted.

The person's time, every month, on work that is a transformation rather than a judgement in most of its volume.

The errors. Small, individually trivial, and corrected next month — which means the payroll of any given month is slightly wrong in both directions, and the labour cost reaching a job is wrong with it.

The key-person dependency. When that person is unavailable at month end, there is no fallback, because the rules are not written down. This is the same structural risk as any process held in one person's memory.

The absence of any labour analysis. Nobody can answer which sites run the most overtime, whether a shift pattern is working, or what absence actually costs, because the data was only ever processed to produce one number and was never kept in a form that could answer anything else.

That fourth one is usually the largest and never appears in a business case. The data already exists; it is being consumed and discarded.

Where to start

Write the rules down. An afternoon with the person who currently applies them. Do this even if nothing else follows, because it converts a personal dependency into a document.

Get them confirmed by somebody with the authority to set policy, and expect two or three to change in the process — that is the exercise doing its job.

Configure the routine cases and route the rest to supervisors with a defined default and a visible queue.

Keep the processed data, so the labour questions become answerable.

The prerequisite for all of it is an employee master that is correct and current, which is the same foundation that leave and end-of-service accrual rest on and the reason those three pieces of data are worth doing first. Where the honest constraint is that nobody can say what the current rules are, that is a discovery exercise rather than a software purchase, and it is the first stage of any automation worth funding.