What a Time Entry Actually Contains

A time entry looks like a duration with a label. The fields that matter in a dispute are the ones nobody looks at until there is one.

The visible fields

Who, as a stable identifier rather than a name that changes on marriage or transliteration.

When: start and end as instants, not a duration alone. A duration cannot be checked against rest periods or shift boundaries.

What: project, matter, cost centre, activity type.

How long, derived rather than stored where possible, so that a correction to start or end cannot leave a duration that contradicts them.

Narrative, where billing needs one.

The fields that decide disputes

Created-at, as a separate value from the period the entry covers. This is what distinguishes a contemporaneous record from one written three weeks later, and it is the single most valuable field in any argument about hours.

Created-by, which is not always the same person as the subject.

Source: typed, timer, clock terminal, imported, generated by a rule.

Every edit, with who, when, old value, new value and a reason.

Approval, with who and when, and whether approval was individual or bulk.

Locked state, and what locked it — a payroll run, a period close, a legal hold.

Products vary enormously here, and the gaps are invisible until you need them.

How to check a product

Create an entry, edit it, and export. Does the export contain the original value and the edit, or only the current state?

Change an entry after approval. Is the approval invalidated or silently retained?

Change a rule and recalculate. Is the pre-change value preserved?

Delete an entry. Is it gone, or marked deleted with the record intact? Hard deletion in a system feeding payroll is a defect rather than a feature.

Ask for the data dictionary. A vendor who has one is a vendor who has thought about this.

The practical minimum

If a product cannot provide these, the rest of the evaluation is academic.

Start and end as instants.

Created-at, separate and immutable.

A complete edit trail, exportable.

No hard deletion.

Rule version recorded against calculated values, or at least a rule change log with dates.

The five-minute product test

Five actions that reveal the record model faster than any documentation.

Create an entry. Edit it. Export. Does the export contain the original and the edit, or only the current state?

Edit after approval. Is approval invalidated or silently retained?

Change a rule and recalculate. Is the pre-change value preserved?

Delete an entry. Gone, or marked deleted?

Ask for the data dictionary. A vendor who has one has thought about this.

Derived against stored

A principle that decides what can be explained later.

Store what was observed: start, end, breaks, who, what.

Derive what was computed: duration, overtime bands, premiums, amounts.

Storing derived values without the rule version that produced them means a historical figure cannot be explained or reproduced after a rule changes.

Ask whether the product records the rule version against calculated values. Most do not, and that is why two-year-old payroll questions go unanswered.

Compare the record model

To contrast the fields in this note with one implementation, learn more here, then export sample records and inspect identifiers, timestamps and amendments directly.