Four Different Things Called Time Tracking

Time tracking is bought as one system and asked to serve four purposes at once. They pull in different directions, and most of the trouble in this field comes from not separating them.

The four

Recording hours worked. How long someone was on duty, when they started, when they stopped, what breaks they took. In much of the world this is a legal obligation and it exists to protect the worker.

Billing. How much time to charge a client for, against which matter.

Costing. How much of the organisation's effort went into which project, product or activity.

Monitoring. What someone was doing during the hours they were on duty.

The first three are about time. The fourth is about activity, and conflating them is the single most consequential error in this field.

Why they conflict

Recording wants accuracy about duration. It needs start, end and breaks, and nothing else.

Billing wants attribution to a matter, at an increment the client accepts, and it wants to be defensible in a dispute.

Costing wants completeness across all work, including the unbilled, which billing systems systematically omit.

Monitoring wants detail about behaviour, which none of the other three needs and which changes the legal position entirely.

A single system asked to do all four either collects far more than any one of them requires, or does three of them badly.

The distinction that matters most

Recording that someone worked from nine to five is not surveillance. In many jurisdictions it is required, and the requirement exists because without a record a worker cannot prove unpaid overtime or a missed rest period.

Recording which applications they used between nine and five is surveillance, with its own obligations and its own cost in trust.

Same product, different setting. Most time tracking tools will do both, and the default configuration frequently includes the second.

Decide which you are doing, in writing, before deployment, because the answer determines the legal analysis, the consultation requirement and how the workforce reads the whole thing.

What each needs

Recording: start, end, breaks. Objective, reliable, accessible to the worker. Retained for the statutory period.

Billing: duration attributed to a matter, with enough narrative to survive a client query, at the agreed increment.

Costing: duration attributed to a project or activity, covering all work including internal and non-billable.

Monitoring: everything else, and the burden of justifying why.

The practical recommendation

Serve the first three from one record where you can, since they are all statements about duration and attribution.

Do not add the fourth to that record. If activity monitoring is genuinely required, it is a separate decision with a separate justification, and bundling it into the timesheet system is how organisations acquire surveillance they never decided to deploy.

Name the purpose on the first page of any proposal. A proposal that cannot say which of the four it serves is not ready.

The first week

Four things that establish where you stand, before any procurement.

Ask five people how they currently record time and what they think it is used for. The answers will differ and the gap is the finding.

Establish the legal position for every jurisdiction you employ in. This determines what is mandatory.

Check what already exists: access control, calendars, ticket systems, payroll. Most organisations hold more than they realise.

Reconstruct one completed project's true cost by hand, including the unbilled effort.

None of this needs a licence, and together they usually change what the project is for.

Who this is for

Three audiences with different reasons to be here.

Whoever has been asked to deploy something and needs to know which of the four purposes they are actually serving.

Whoever has to assess it — legal, HR, a works council — and needs the technical picture in terms that connect to the obligations.

Whoever fills it in, whose cooperation is the data collection mechanism and whose interests are treated here as a design input rather than an obstacle.

These notes are written for the first, with the second's questions answered where they arise.

Turn the principle into a test

For an example that can make this requirement testable, consult workforce tracking features. Treat the page as a starting point rather than proof: reproduce the workflow with real roles, exceptions and permissions before relying on the result.