Time and Attendance: What You Are Actually Buying

TL;DR

• The core decision: what counts as time worked, who may change a record, and what happens when the clock disagrees with the schedule. None of those come in the box.
• When doing nothing is right: when payroll is right first time, nobody disputes their hours, and you could produce the records if asked.
• What has to be true: somebody can state, in a sentence, when the working day starts for the purposes of pay.
• How the options split: by how much the person has to do, and how much interpretation the record needs afterwards.
• Decision rule: pick the capture method last. The policy questions underneath determine whether any of them will work.
• Outcome to expect: fewer corrections, and one uncomfortable conversation about the definitions you'd been leaving vague.

Every Demonstration Looks the Same

Somebody gets asked to sort out time and attendance, usually after payroll has been corrected once too often. They line up three demonstrations. All three go well. All three show a clean interface, a clock-in, a manager approval screen, an export to payroll. By the third one they can't remember which feature belonged to which product.

That's not a failing of the person watching. The products genuinely are similar in the part that gets demonstrated, because capturing a timestamp is a solved problem and has been for a long time. What differs between organisations isn't the clock. It's everything the clock doesn't decide.

Consider one worker arriving eight minutes before their shift, putting their bag away, getting changed, and starting at the scheduled time. Another arrives on time but the system is slow and they clock in four minutes late. A third is asked to stay twenty minutes to finish something and nobody tells them whether to record it. Every one of those becomes a payroll question, and no system answers any of them, because they're not measurement problems. They're policy questions about what counts.

Recommended Tools

Best tools for Workforce Management

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

So the real problem isn't which product captures time. It's that most organisations buy one without answering the questions underneath, and then discover they've paid for a more precise version of the same disputes. The definitions are the purchase. The interface is just where they get applied.

When You Genuinely Do Not Need to Act Yet

Your current setup is genuinely fine. Payroll goes through without correction, nobody has queried their hours in months, and if somebody asked for records you could produce them. Whatever you have, including a paper sheet on a clipboard, is doing the job, and replacing it is a project with no problem attached.

Friction is starting to show. Corrections are happening occasionally, or a manager is spending real time chasing missing entries, or the same question about what counts keeps coming up. None of that is urgent. The cheapest check is to take the last correction and find where the wrong number entered, because it's usually a definition rather than a device.

It has become a real cost. Payroll is corrected most cycles, or somebody spends a day each period reconstructing hours, or you've had a dispute you couldn't resolve because the record didn't show what actually happened. At this point the cost is real and recurring, and it's worth fixing properly rather than tightening the existing process.

The edge case that forces it. You're asked for records you can't produce, or you're introducing something that collects biometric data such as a fingerprint or face scan. The second is the one to be careful about: rules on collecting biometric information differ sharply between jurisdictions, several places impose specific consent and retention obligations, and the penalties can be significant. Establish the position where you operate and take local advice before you collect anything, not after.

Five Questions This Reader Asks at 11pm

Is this the same as time tracking? Related and different in purpose. Time and attendance records whether somebody was working, for pay and coverage. Time tracking usually records what they were working on, for billing or project understanding. A team can need one, both or neither, and buying a product built for the second to solve the first produces detail nobody wanted and a workforce that feels observed.

Can we use fingerprints or face recognition? Sometimes, and the question is genuinely jurisdiction-specific rather than a matter of preference. Several places treat biometric data as a special category with its own consent, notice and retention requirements, and some have specific statutes with real penalties attached. It's also worth asking whether you need it: the problem it solves is one person clocking in for another, which may or may not be a problem you actually have. Establish the local position and take advice first.

Who should be able to edit a time record? Somebody has to, because clocks get missed and shifts genuinely change. The question is whether edits are logged with who made them and why, or simply overwritten. An unlogged edit means you have a number rather than a record, and the moment that distinction matters is a dispute, which is the worst possible time to find out.

What about rounding? Whether you may round, in which direction, and to what interval is governed differently in different places, and getting it wrong systematically across a workforce compounds quickly. Beyond the legal question there's a fairness one that people notice immediately: rounding that consistently favours the employer is visible to everybody subject to it, and it costs more in goodwill than it saves.

Do salaried people need to clock? Usually not for pay, and sometimes yes for other reasons: project costing, client billing, or a record keeping obligation attached to particular work. Be honest about which. Asking salaried staff to clock for pay purposes when their pay doesn't vary reads as monitoring, because functionally that's what it is, and it tends to be received accordingly.

Three Honest Categories the Approaches Split Into

The person records their own time. Timesheets, self-reported hours, an app the worker operates. It's right where trust is high and the work is genuinely variable, particularly for professional and field-based roles where nobody is passing a fixed point. It's cheap, it requires no equipment, and it treats people as adults. It fails on memory and on lateness: self-reported time completed at the end of a week is a reconstruction rather than a record, and it drifts in predictable directions. It also fails where the record has to withstand scrutiny, since a self-reported figure with no corroboration is weak evidence if a dispute arises.

The system records the time. A terminal, a badge reader, an app that captures the moment. It's right where the workforce is large, the hours are the basis of pay, and the record needs to be reliable at volume. It removes the memory problem entirely and produces something consistent. It fails when the capture point doesn't match where work actually starts: a terminal at the entrance measures arrival, not the beginning of work, and the gap between them becomes a dispute that recurs forever. It also fails where equipment failure means the person can't do the thing they're required to do, and nobody has said what happens then.

The schedule is assumed, exceptions are raised. Everybody is treated as having worked their scheduled hours unless somebody says otherwise. It's right in stable operations with predictable shifts and low variance, and it's dramatically less administrative work than the alternatives. It's also honest about what most time systems actually record, which is the schedule with occasional amendments. It fails when exceptions don't get raised, which happens most where raising them is awkward, so unpaid extra time systematically disappears. It also produces records that are weak in a dispute, because they show what was planned rather than what happened.

Five Diagnostic Questions You Can Self-Assess Against

Take the last payroll correction and trace it back. Find the point where the wrong number entered. In most organisations it's one of three things: a shift changed and the record didn't, an absence wasn't entered before the cut-off, or somebody's hours were captured in a form that needed manual interpretation. The first two are process, the third is capture, and only the third is fixed by a product.

Ask three people when the working day starts for pay. A supervisor, a long-serving worker and a recent joiner. If the answers differ, you have a definition problem, and it'll survive any system you install. This takes ten minutes and it's the single most useful thing in this article.

Who edited a time record last month, and can you tell? Ask the question literally. If the answer is that records get adjusted and nobody knows by whom, your records won't support a decision if one is ever challenged, and you should fix that before anything else.

What happens when the clock fails? Every method fails sometimes: the terminal is down, the phone is flat, the badge doesn't read. Ask what the worker is supposed to do, and then ask whether the answer is written anywhere. Undefined failure handling is where most informal workarounds start, and workarounds become the real process quickly.

Could you produce the records if somebody asked? For the period your jurisdiction requires, in a form somebody else could read. If that would take a reconstruction, you have the data and not the records, which is a distinction that only matters once, at the worst possible moment.

Six Ways Time Gets Captured, Reviewed

Manual timesheets completed by the person

The worker writes down or enters their own hours, usually at the end of a day or a week. It earns its place through flexibility and cost. It handles work that doesn't pass a fixed point, it needs no equipment, and for professional or field-based roles it's frequently the only workable option. It also signals trust, which has a value that's real even though it doesn't appear in any comparison.

Where it falls short is accuracy in a specific direction. A timesheet completed on Friday about Tuesday is a reconstruction, and reconstructions round towards the scheduled hours, because that's what people remember. Short extra periods disappear and short absences do too, which means the record converges on the rota regardless of what happened. It's also the weakest form of evidence if a dispute arises, since nothing corroborates it.

It works well where variance is genuine and trust is high. It works badly as the basis of hourly pay at volume, which is exactly where it's most often inherited.

One adjustment removes a good deal of the drift without changing the method. Ask for the entry daily rather than weekly, even if the submission is weekly. A record made on the day is a record; the same record made on Friday is a recollection, and the difference shows up mostly in the small amounts either side of a shift, which is precisely where the fairness questions live.

Manager-entered hours

The supervisor records what their team worked, usually in a weekly submission. It earns its place in small teams and in operations where the manager is physically present throughout, because it adds a layer of judgement: somebody who knows the work is deciding what counts, and genuine exceptions get handled without a process.

It falls short on the same reconstruction problem as self-reporting, amplified across a team. It also puts a manager in the position of deciding somebody's pay based on memory, which is uncomfortable for both parties and hard to defend if questioned. And it makes the record entirely dependent on one person's diligence in a week when they have other things happening.

Where it's used, it should be a confirmation of something already captured rather than the primary record.

A fixed terminal at the entrance

A clock, tablet or reader at a fixed point that people use on arrival and departure. It earns its place in single-site operations with a defined entrance, where it's unambiguous, hard to forget and produces a consistent record at volume. It's also the method people understand most readily, which matters more than it sounds.

It falls short on the gap between the terminal and the work. If the clock is at the entrance and the job starts at a workstation five minutes away, or after changing, or after a handover, then the record and the work don't match, and the difference either gets absorbed unpaid or becomes a recurring argument. Queues at shift change compound it. It also fails entirely for anybody who doesn't pass that point.

The fix isn't a better terminal, it's deciding where the working day begins and putting the capture point there.

The secondary problem is throughput, and it's easy to underestimate. A single terminal serving a shift change of any size produces a queue, and a queue at the start of a shift is unpaid waiting caused by your own equipment. People notice quickly, and the usual workaround is that somebody clocks in for the group, which reintroduces the exact problem a terminal was meant to prevent. Count the people passing through in the busiest five minutes before deciding how many you need.

A mobile application, sometimes with location awareness

The worker clocks in from their phone, occasionally with a check on where they are. It earns its place for distributed and field-based work, where there's no fixed point to install anything, and it can genuinely improve accuracy for people moving between sites.

It falls short on two fronts. It relies on the worker's own device, battery and signal, and where a personal phone is required for work that's an imposition worth acknowledging rather than assuming. Location checking is the larger issue: it collects data about where people are, which is governed differently in different jurisdictions and is experienced as surveillance whether or not it's intended that way. Establish the local requirements before enabling it, and be clear internally about what's being collected and why.

If you do enable it, the narrow version causes less damage than the broad one. Checking location only at the moment of clocking in and out, and storing whether the person was at an expected site rather than a coordinate history, answers the operational question without building a movement record. Continuous tracking through the shift answers a question most organisations have not actually asked, and it's the version that reliably ends up in a grievance.

Badge or card entry tied to access control

The record is a byproduct of the door system people already use. It earns its place through effort, which is nearly zero: nobody does anything extra, the record is generated by an action they'd take anyway, and there's nothing to forget.

It falls short because access and work aren't the same event. A badge records entry to a building, which includes people arriving early, coming back for something, or passing through a door on the way to somewhere else. Using it as a pay record means paying for presence rather than work, and it produces exactly the ambiguity you were trying to remove. It also complicates anything where access data is held for security purposes, since using it for a second purpose may carry its own obligations.

Useful as corroboration. Weak as a primary record. There's also a data question that gets overlooked. Access records are usually held for security reasons under one justification, and using them to determine pay is a second, different purpose. Whether that requires anything additional depends on where you operate, so it's worth checking before repurposing a door system rather than assuming the data is simply available because you already hold it.

Scheduled hours assumed worked, with exceptions raised

Nobody clocks anything. The schedule is the record unless somebody reports a difference. It earns its place by being proportionate: in a stable operation where people work their shifts, this captures the same information as a clock with none of the administration, and it's honest about what most time data actually is.

It falls short on the exceptions, and the failure is asymmetric. Absences get raised reliably, because somebody notices. Extra time frequently doesn't, because raising it requires the worker to ask, and asking is awkward. Over a period that produces a systematic understatement of hours worked, which is both a fairness problem and a risk if anybody examines it. It's also the weakest possible record in a dispute, since it shows the plan rather than the event.

It's a reasonable choice where variance is genuinely low, provided raising an exception is made easy and visibly welcome.

The Decision Table

The third row is where most of these projects should start and almost never do. A definition disagreement produces disputes that look like system failures, and installing a system on top of it gives you the same disagreements recorded to the minute.

The Questions the Method Does Not Answer

Every capture method produces a timestamp. None of them decides what the timestamp means, and the meaning is where the disputes live.

The first row causes more disputes than the rest combined, and it's rarely written anywhere. People form their own view from where the clock is, which means the policy is set by an installation decision made for convenience. Deciding it explicitly, then putting the capture point there, removes an argument that otherwise recurs indefinitely.

The seventh row is worth care. Break rules differ considerably by jurisdiction, and a system that automatically deducts a break somebody didn't take creates a systematic error across an entire workforce. Automatic deduction is a default in many configurations, so it's worth checking rather than assuming.

When the Clock and the Schedule Disagree

Every organisation has a rule for this, and in most it's undocumented and applied differently by each supervisor. It's the single richest source of payroll corrections, and it's entirely a policy question.

The four cases are predictable. Somebody clocks in before their shift starts. Somebody clocks out after it ends. Somebody doesn't clock at all. And somebody's actual shift differed from the published one because of a change made on the day.

For the first two, the decision isn't whether to pay the difference, it's whether the difference was authorised. Paying all early arrivals encourages arriving early; paying none means somebody asked to start early isn't paid for it. The workable rule is that scheduled time is paid by default and anything outside it needs authorisation, with a stated way of getting that authorisation quickly. What breaks this is when the authorisation route is slow or awkward, because the extra time then either gets absorbed unpaid or claimed without approval, and both erode the rule.

For the missing clock, the important thing is that a defined path exists. A worker who cannot clock has done nothing wrong, and if there's no clear route to correct it they'll either lose the time or invent a workaround. The route needs to be simple, logged, and not framed as an exception requiring justification.

For the changed shift, the failure is almost always that the change was real and the system was never told. Somebody swapped, somebody was moved to cover, somebody stayed on. This is the largest category and the most fixable, because it's a single habit: whoever makes the change updates the record at the time, not afterwards. Where that habit doesn't exist, the reconciliation work moves to payroll, who weren't there and have to ask.

A short written statement covering those four cases removes most of the corrections in most operations, and it costs an afternoon.

What to Put in Writing

The definitions are the thing being bought, and they're the part no implementation includes.

The fourth row is the one that pays for itself fastest. Most payroll corrections trace back to one of those four cases being handled differently by different supervisors, and a single written rule resolves them all at once.

Questions to Ask Before You Commit

On the definition. When does the working day start for pay, and would three people agree? A bad answer is that it's obvious.

On the diagnosis. Where did the last wrong number actually enter? A bad answer is that the current system is unreliable.

On amendments. Who may edit a record, and is it logged? A bad answer is that managers sort it out.

On failure. What does somebody do when they can't clock? A bad answer is that it rarely happens.

On biometrics. What applies where you operate, and who confirmed it? A bad answer is that the vendor says it's compliant.

On salaried staff. What's the purpose beyond pay? A bad answer is consistency.

What Getting This Wrong Costs

The first cost is the correction cycle, and it's larger than it looks because it's distributed. Every correction consumes payroll time, manager time and usually the worker's time, and it arrives after the fact when everybody has moved on. Organisations in this position tend to describe it as payroll being busy, which locates the problem in the wrong department: payroll is processing an error that was created upstream, usually by a definition nobody wrote down.

The second cost is trust, and it's asymmetric in a way that's worth understanding. Errors that underpay somebody are noticed immediately and remembered for a long time. Errors that overpay are noticed by nobody until a reconciliation, at which point recovering the money is unpleasant for everybody. A process with a known error rate therefore damages the relationship even when the errors go both ways, because only one direction is visible to the person affected.

The third cost arrives once, and only when it's too late to fix. If records are challenged, whether by an individual or by somebody external, what matters is whether you can produce an accurate account of hours worked for the required period in a form somebody else can read. Organisations with plenty of data and no records discover the distinction at exactly that moment. What must be kept and for how long differs by jurisdiction, so it's worth establishing deliberately rather than trusting a default setting.

So before you evaluate anything: is this a capture problem, a definition problem, or a habit problem? Capture means the information genuinely isn't being recorded, and a product helps. Definition means people disagree about what counts, and no product will decide it for you. Habit means changes happen and the record isn't updated at the time, which is fixed by one behaviour rather than by software. Most organisations diagnose the first and have the second or third.

When You Are Ready to Go Further

None of this needs a purchase to begin. It needs one written statement of what counts as time worked, a rule for the four clock-against-schedule cases, and an audit trail on amendments.

The step beyond that is the comparison nobody makes: scheduled hours against actual hours, looked at on a regular cadence by somebody who can act on it. That's the only output of a time system that changes anything, and it's available from whatever you have today.

HROpsLab publishes independent comparison work across HR tooling, applicant tracking and payroll. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is comparing what these systems actually differ on, our comparison work is one place to start.

Frequently Asked Questions

The clock is the easy part. What you're buying is a set of decisions nobody has made yet.