Working Time Records

What a System Has to Do

This is not legal advice.

The standard is three words — objective, reliable, accessible. Seven functional requirements follow from them, and they are a better basis for evaluating a system than any feature list. For an additional implementation-oriented example, see online timesheets.

Reviewed August 9, 2026.

Derived from "objective"

One. Records made at the time. Same-day entry, or as close as the operation permits. A system that encourages weekly reconstruction is working against the standard, whatever it stores. For additional workplace and technology context, see German Federal Ministry of Labour and Social Affairs.

Two. Actual times, not scheduled times. A system that defaults each day to the contracted hours and asks for confirmation is recording a schedule and calling it a record.

Derived from "reliable"

Three. A change history. Every correction retained with who, when and what changed. This is the single requirement that most cheaply distinguishes a defensible system from a spreadsheet nobody versioned.

Four. No silent overwriting. Not the same as three — a system can log changes and still present only the current value, which is fine, provided the history is retrievable.

Five. Retention for the applicable period, with the records producible in order.

Derived from "accessible"

Six. The employee can see their own record, without asking a manager for it.

Seven. Export in a readable form. For an auditor, for a dispute, and for the day you change supplier. A record you cannot get out of the system is accessible to the vendor rather than to you.

What is on every product page and satisfies none of them

Worth listing, because feature comparisons run on these.

Mobile clock-in. Convenience, not compliance.

Geofencing and location. Not required by the duty, and it raises separate data protection questions.

Project and task attribution. Commercially useful, legally irrelevant.

Dashboards and analytics.

Integrations. Genuinely valuable if payroll depends on the record, and unrelated to whether the record is lawful.

None of that is bad. It is simply not what the standard asks for, and a system chosen on those features can still fail the seven above.

The evaluation, in one conversation

Six questions to a supplier. The answers take five minutes and discriminate better than a demonstration.

Can you show me the change history for a corrected entry?

What happens if an employee edits yesterday's record — is the original retained?

Can an employee see their own records without a manager?

Can we export everything, in a readable format, ourselves?

What is the retention configuration, and what happens at the end of it?

And can the location and monitoring features be disabled — not hidden, disabled?

A supplier who answers all six directly is a good sign. One who redirects to features is telling you what they optimise for.

The thing that no system supplies

Configuration and use.

A compliant system badly configured produces non-compliant records: overwriting enabled, retention wrong, employees unable to see their own data, everyone defaulting to contracted hours.

Software does not confer compliance, and the seven requirements above are as much about setup as about purchase. The work is the configuration, and it is nobody's product.

The short version