What a Week of Recorded Time Is Made Of

The approver sees a total. The system holds something considerably larger, and the difference between the two is where most disputes are decided.

The record described in “What a Week of Recorded Time Is Made Of” should be created close enough to the work that people are not reconstructing a polished week from memory. When teams assess the official Monitask resource for capital efficiency ratio, they should keep entry, project selection and correction simple, while explaining which optional activity data is collected and how employees can review it.

A week of recorded time is not seven numbers. It is a set of entries, each carrying a date, a duration, an allocation, a narrative and a provenance, plus a layer of metadata the interface never shows. Understanding which of those fields exist, and which are empty, tells you what your records can and cannot support.

For a separate benchmark relevant to “What a Week of Recorded Time Is Made Of”, consult the NLRB employee-rights guidance. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.

The fields the person fills in

Date and duration, which are the only ones most people think about. Allocation — the project, client, matter, cost centre or work package the time is charged to, and in some systems more than one of those at once. And narrative, the free-text description, which is optional in most configurations and therefore mostly absent.

In clock-based systems the duration is replaced by a start and an end, which is a materially different record and a stronger one. A duration of eight hours asserts a quantity. A start of 07:42 and an end of 16:11 asserts a shape, and a shape can be checked against other records in a way a quantity cannot.

The fields the system fills in

Created-at, which is when the entry was first saved. Modified-at and modified-by, for each subsequent change. Submitted-at. Approved-at and approved-by. The device or client used. In mobile capture, often a location. And in better systems a version history holding what each field contained before it was changed.

These are the fields that matter in a dispute, and almost nobody looks at them until there is one. An entry for Tuesday created on Friday afternoon is a reconstruction. An entry created on Tuesday morning before the work happened is a plan. An entry created on Tuesday evening is a record. The three are indistinguishable in every report the organisation runs, and entirely distinguishable in the audit table.

Contemporaneity, and why auditors ask

Grant funders, defence contracts, research councils and most public procurement require records that are contemporaneous — made at or near the time of the work rather than assembled later.

The test they apply is exactly the created-at field. An organisation whose entries are all created within a few hours of the work passes. One where ninety percent of entries are created on Friday between four and six passes nothing, regardless of how accurate the hours happen to be. This is the single most common audit finding in time-based claims and it is entirely visible in the organisation's own data before anybody from outside asks.

What is missing by default

Two things, usually. The first is any record of what was not worked: unrecorded absence, authorised time off taken informally, hours the person worked and chose not to claim. The record is one-sided by construction, which means it can establish an upper bound on hours worked and never a lower one.

The second is the link to anything external. A timesheet entry stands alone. It does not reference the ticket, the job number, the delivery note, the site visit record or the calendar entry it corresponds to, and in most organisations nothing joins them afterwards. Adding even a weak link — a reference field, a job number, a ticket identifier — converts an unverifiable assertion into one that can be reconciled, and costs nothing but a column.

Reading your own record

Export one week of raw entries, with every field, for one team. Not the report; the underlying table. Most people who run timesheet processes have never done this and are surprised by what is in it.

Count the entries per person per week — three entries for a five-day week tells you the granularity is weekly regardless of what the policy says. Look at the gap between work date and creation date. Count how many entries have a narrative. Count how many were modified after creation and by whom. Look at how many distinct allocation codes appear and how many of those account for ninety percent of the hours.

Five numbers, half an hour, and they describe the actual quality of the record more honestly than any dashboard the system produces. Everything else in this collection assumes you know them.

Two fields that cost almost nothing

The first is a free reference: a ticket number, a job number, a purchase order, a site identifier. It converts an unverifiable entry into one that can be joined against another system, and it is the difference between a record that stands alone and a record that can be corroborated. Most systems have a spare field and most implementations left it empty.

The second is a marker for how the entry was created: typed, timed, imported from a rota, copied from last week, or entered by somebody other than the worker. Copied and proxied entries behave very differently from typed ones and are indistinguishable in every report. Knowing which is which turns several of the measurements described elsewhere here from estimates into facts.