EU Mandatory Time Tracking Starts at the Rota"

Eleven hours between shifts. Tomas got eight, on eleven days last quarter, and your time tracker has all twenty-two timestamps to prove it.

It proved them on the fifth of this month. The eight hours was decided three weeks before Tomas worked either shift, by a supervisor filling a Wednesday early with the one person who was obviously free — because he had worked until ten the night before and was therefore in nobody's way.

What the law actually asks you to record

The obligation comes from a single 2019 ruling. In CCOO v Deutsche Bank (C-55/18, 14 May 2019) the Court of Justice held that member states must require employers to set up "an objective, reliable and accessible system enabling the duration of time worked each day by each worker to be measured" (judgment). The reasoning matters more than the holding: without such a system, the Court said, the rights in the Working Time Directive cannot be verified, so they cannot be relied on.

Those rights are the arithmetic the record exists to prove. Directive 2003/88/EC sets eleven consecutive hours of daily rest, an uninterrupted twenty-four hours of weekly rest on top of it, an average forty-eight-hour week including overtime across a reference period of up to four months, and four weeks of paid annual leave. The directive sets floors; member states and collective agreements routinely set stricter numbers, and it is the stricter number that binds you.

So the tracker answers one question — how long did this person work — and the law asks a second one it cannot answer: was that allowed.

Where the member states stand, September 2026

Mandatory time tracking arrived by ruling rather than by statute, so implementation is uneven — and three of these are moving this year.

Two things follow for anyone running shifts in more than one country. The retention period, the format and the reader of the record differ; the underlying rest and hours arithmetic mostly does not. And the direction of travel is the same everywhere: from a record you produce on request to a record somebody else can read without asking you.

Two moments, and only one of them is in the tracker

Every working-time breach has two timestamps. There is the moment it becomes inevitable — the rota is published, the swap is approved, the callout is accepted — and the moment it becomes visible, which is when the hours land in the register.

In most operations those are weeks apart, and they live in different systems.

flowchart LR
  P[Rota published] --> A[Shift worked]
  A --> R[Hours recorded]
  R --> I[Inspection]
  P -. breach decided here .-> I
  R -. breach discovered here .-> I

A time tracker is an excellent witness and a poor control. It tells you accurately what already happened, which is what the law asks it to do and all it was ever built to do. If the only system that knows your rest rule is the one that reports last month, then every rule you have is enforced retrospectively, by exception, against work that has already been performed and already has to be paid.

Here is the Tuesday that produced those eleven records.

Eight hours between the Tuesday late and the Wednesday early, against a rule that says eleven. The supervisor who did that was not being careless — being free tomorrow morning is what finishing at ten tonight looks like from a rota board, and the rule is the only thing that distinguishes them.

The eleven hours in that figure are supplied by the spec, not by us. The engine ships the shape of a rest rule and never a jurisdiction's values, which is the same reason it cannot tell you whether your stand-by counts as working time.

The number a Monday-to-Sunday report cannot show you

The second failure is quieter and harder to spot by eye. Hour limits in the directive and in most agreements are measured over a period, not over a calendar week — any seven days, any four months. Weekly reports are drawn on a grid, and the grid has an edge.

Take an agreement that caps a person at forty-eight hours in any seven days. Tomas works Monday to Wednesday of the first week on eight-hour shifts — twenty-four hours — then twelve-hour shifts on the Thursday and Friday. That week reports forty-eight. The weekend is off. The following week he is back on twelves from Monday. That week reports forty-eight too, and neither report is wrong.

Sixty hours in the seven days that straddle the weekend, and no weekly report in the company shows a number larger than forty-eight. Priya works the same pattern at eight hours a day and comes out at forty. The rule is not exotic and the breach is not clever — it is invisible because it was measured on a grid the rule does not use.

The engine probes windows anchored on the shifts themselves rather than on the calendar, which is the whole difference. If your reference period is four months rather than seven days, the same trap is four months wide and correspondingly harder to find by reading.

Working time is not elapsed time

One more gap between what a clock records and what a rule tests.

A twelve-hour shift with a one-hour unpaid break is twelve hours of elapsed time and eleven hours of working time. Hour budgets and rolling averages run on the working minutes; rest gaps run on the wall clock, because rest is the distance from the end of one duty to the start of the next. Swap the two and a roster that passes on paper fails in fact, or the other way round.

Stand-by is the harder case, and the honest answer is that nobody can automate it. Whether time spent on call counts as working time depends on how constrained the worker actually is, a fact-specific test the Court has refused to reduce to a threshold across SIMAP, Jaeger, Matzak and the 2021 firefighter and technician cases (C-344/19, C-580/19). A scheduling system that decided this for you would be guessing about your case. Ours takes the classification as an input and does the arithmetic on what you declared, and records which classification was used.

One record, and it answers to an API

We built the register rather than integrating one, for the reason this post is about: the system that plans the shift and the system that records it disagreeing is the failure, and two vendors cannot be made to agree by a nightly sync.

What is under it is four tables and one rule. A shift row per stretch a worker is on shift, opened and closed from the worker's own phone; break rows inside it, so worked time is shift time minus overlapping breaks; task intervals underneath, opened automatically when work is accepted and closed when it ends, with a one-tap manual timer beside them for everything else. A shift that nobody closed is capped by a guard, and the cap is stored as a bound that must never be read as a clock-out — a distinction that matters the first time somebody is paid from it.

The rule is that the register can be corrected and never quietly. Every edit writes a correction row holding the whole record as it stood, not a diff, with a required reason and the editor's name denormalized so it survives their leaving. The question an inspector asks is "what did it say", and a diff cannot answer that if the row it applies to has itself been corrected since. Closing a pay period then refuses corrections inside it, and reopening is recorded rather than silent.

All of it is API-first and none of it is console-only. GET /v1/workers/{id}/time-entries returns the log; the worker's own twin, GET /v1/portal/me/time-entries, is fixed to the same window with no parameters — the parity is deliberate, and it is what keeps the log a timesheet rather than surveillance. Corrections, period closures and the payroll assembly have their own endpoints, and the same operations are registered as MCP tools, so an agent can read a working-time log, add a shift somebody forgot to clock, or correct one — correct_worker_time_entry demands the note and a closed period refuses it, exactly as a person's edit would be refused.

What to do this quarter

Most of this is worth doing before you change any software, and the first two steps are worth doing today.

1. Write your rest rule down as a number of minutes. Whatever the directive floor, your national law and your agreement combine to. Most operations discover at this step that two people in the office believe different numbers.
2. Do the same for your hours cap and name its period. "Forty-eight" is not a rule until you say over what, and "the week" is not a period until you say whether it is any seven days or Monday to Sunday.
3. Re-run last quarter's records against those numbers on a rolling basis, not by week. Whatever the grid was hiding will show up in that one query, and it is better found by you.
4. Move the check to publish time for one team. One rota, one rule, checked before it goes out. The point is to learn how many edits that rota needed.
5. Decide who may override a rule and how the override is recorded. Somebody will override it at 04:00. An override you can read afterwards is a managed risk; one you cannot is an unmanaged one.

Four things we do not do, and one of them is our own bug. There is no connection to a national system: Greece's Digital Work Card transmits to ERGANI II in real time and we speak to no government gateway, so that stays a separate integration. There is no inspector-facing access mode of the kind Spain's draft decree contemplates; records are read by the operator and by the worker whose hours they are. The retention sweep ships no number — a window is set per deployment, because deleting a working-time record early is the one error with no safe side, and if you are in Spain the four years is yours to configure. And the worker's own confirm-or-dispute of a period exists as an endpoint, is tested, and has no screen in the portal yet, which means today the attestation is reachable by API and not by the person whose wage it is. That one is a gap rather than a position, and it is next.

What we will never do is tell you a roster is compliant. The engine answers a narrower question: whether the rules you supplied were satisfied, which shift pair failed which one, and by how much.

Common questions

Does the EU require electronic time tracking?
No. The 2019 ruling requires a system that is objective, reliable and accessible; it does not prescribe the medium, and the German Federal Labour Court said explicitly that paper can suffice depending on the work. Several member states are separately legislating for digital records — Spain's draft decree and Greece's Digital Work Card are the clearest cases — so the practical answer is drifting towards yes, country by country.

We track hours accurately already. What is missing?
The order of operations. An accurate record of a rest gap that was too short is a record of a breach. The check that would have prevented it has to run when the rota is built, against the same numbers — which is the argument for the planner and the register being one system rather than two that reconcile.

Can we drive all of this from our own systems?
Yes. The working-time log, corrections, period closures and the payroll assembly are HTTP endpoints before they are screens, and the same operations are registered as MCP tools for agent use. The read half is bound in every SDK; the correction and payroll half is TypeScript-only today while the wage shapes settle, and the other three clients read the log rather than write it.

Can rules be checked automatically for every country we operate in?
Not by us, and be careful of anyone who says otherwise. We ship rule shapes — minimum rest, rolling windows, consecutive days, night bands, overtime baselines — and you supply the values that apply to that site and that agreement. A sectoral regime that replaces a directive rule is expressed by leaving that rule out, not by widening it.

Where does the assignment record fit?
Beside the working-time record and answering a different question: who was considered for this shift, who was excluded, and under which rule. That is the decision trace, and it is the thing that turns "we schedule carefully" into something a third party can read. Data residency and what we store is on the EU page.

---

Start with step one. Write the rest rule down as a number, then check last month's published rota against it — not last month's timesheets, the rota, because that is the artefact you can still change next time.

You can watch the rules run against a sample week in the browser, with nothing to install, at the roster simulator. What can be expressed as a rule, and what deliberately cannot, is set out in the rules documentation; what happens when a rota is published is in publishing. The endpoints behind the working-time log are in the rostering API reference, and the agent-facing half in the MCP documentation.

Photographs: Daniel Stiel and Centre for Ageing Better / Unsplash.