Auditing the System

Time records are examined in three situations: a labour inspection, a financial audit, and a dispute. Each asks for different things and most of them cannot be reconstructed.

A labour inspection

Can you produce the daily record of start, end and breaks for a named worker, for a named period?

Is it objective and reliable — and can you explain how?

Is it accessible to the worker? Demonstrate it.

Are rest periods and weekly limits being observed, computed from actuals?

How long are records retained, and can you show one from the earliest part of the period?

Is there evidence of employer alteration? The edit log answers this and its absence is itself a finding.

A financial audit

Does recorded effort support the revenue recognised?

How is unbilled work identified and treated?

Where development effort is capitalised, how is qualifying work distinguished — and does the category structure actually support that distinction, or was it inferred at year end?

Are approvals evidenced, and is approval meaningful or a bulk action?

Can a sample of entries be traced from record to invoice to payment?

A dispute

The specific entries at issue, with their creation timestamps.

Every edit, with who and when.

What the worker was shown and when.

The rules in force at the time, which is why rule versioning matters.

Whether the person raised a concern, and what happened.

What cannot be reconstructed

When an entry was actually made, if creation timestamps are not retained.

What the rules were two years ago, if they were not versioned.

Whether the worker saw their record, if access is not logged.

Whether an edit was disputed, if disputes are not recorded.

The reasoning behind a configuration choice, if it was not written down at the time.

Each is cheap to capture continuously and impossible to produce afterwards, which is the whole argument for doing it as habit rather than before an inspection.

The self-audit

Run it before someone else does.

Take five workers and produce their complete records for a month. Time how long it takes.

Check them against the rules: rest, weekly limits, break handling.

Take five matters and trace record to invoice to payment.

Pull the edit log and look for patterns: manager reductions, bulk changes, retrospective adjustments near payroll cut-off.

Whatever you find, an inspector would find.

What to keep permanently available

The rules in force, versioned, with dates.

The purpose limitation and when it was published.

Consultation records.

The assessment, where one was required.

Configuration history: what the system was set to do, from when, including whether monitoring features were ever enabled.

Capturing what cannot be reconstructed

Five things that are cheap continuously and impossible afterwards.

Entry creation timestamps, retained separately from the entry.

The rules in force, versioned with dates.

Worker access events, so it can be shown the record was visible.

Disputes and their outcomes.

Configuration history, including whether monitoring was ever enabled.

None costs anything to record as habit. All are decisive in an inspection or a claim, and none can be produced convincingly after the question is asked.

Running the self-audit

Do it before someone else does, and time how long it takes.

Five workers: produce complete records for a month.

Check against the rules: rest, weekly limits, break handling.

Five matters: trace record to invoice to payment.

Pull the edit log and look for patterns — manager reductions, bulk changes, adjustments near payroll cut-off.

Whatever you find, an inspector would find, and fixing it beforehand with the fix documented is a materially better position.

A useful implementation prompt

During configuration, inspect this service connection can be used as a prompt for questions about fields, ownership and output. Confirm current capabilities with the provider and document any plan, integration or policy assumption behind the decision.