A timesheet is a financial document. Every invoice a consultancy sends is a claim that certain people spent certain hours on certain work, and the timesheet is the evidence behind that claim. For internal platform teams, the stakes are the same in a different suit: capitalized development hours land on the balance sheet, and at year end someone with an audit checklist asks how those hours were recorded, who approved them, and whether anything changed after approval.
Most timesheet setups cannot answer those questions. Not because people are dishonest, but because the tooling never treated the timesheet as a record.
How time records fall apart under review
The failure patterns repeat across every firm we have talked to.
History stays editable forever. Someone notices in July that a March entry looks wrong and quietly corrects it. The invoice went out in April. There is now a mismatch between what the client was billed and what the system shows, and no trace of when the number changed or who changed it.
Approval happens in email. A manager replies “looks fine” to a spreadsheet attachment. Six months later nobody can say which version of the spreadsheet was approved, because the file kept changing after the reply.
Timezones turn into mush. A contractor in another timezone logs hours on Friday evening that land on Saturday in the system’s local time. If weekend work bills at a different rate, that ambiguity is money. If the system never recorded which business date the hours belong to, the ambiguity is permanent.
Hours float free of the work. A week of “Development - 8h” rows ties to no work item, no project phase, no deliverable. When the client disputes an invoice line, there is nothing underneath it to point at.
Problems surface after invoicing. Gaps, duplicates, and 26-hour days get noticed when a client questions the bill, which is the most expensive possible moment to notice them.
What a defensible record looks like
None of this needs exotic tooling. It needs a small number of properties, enforced by the system rather than by discipline.
Entries move through states: draft, submitted, approved, locked. Each transition records who did it and when. A locked week is closed arithmetic; corrections happen as new entries in the current period, not as silent edits to history, so the record the invoice was built on still exists.
Time is stored in UTC with an explicit business date. The question “which day do these hours belong to” gets answered once, at entry, instead of re-litigated at every rate boundary.
Every entry says what the time was for. Attribution to an activity, and to a project or work item where one exists, is the difference between a number and evidence.
Anomalies get flagged before approval, not after invoicing. Gaps in a week, overlapping entries, and days that exceed plausible hours should be visible in the approval view, because the approver is the last person who can fix them cheaply.
Access follows need. The person approving a subcontractor’s week does not need to see the whole company’s rates, and an auditor granted read access to one project should see exactly that project.
The surveillance detour
At some point in this conversation someone proposes screenshots, keystroke counts, or a webcam check. It is worth being clear about why that answers the wrong question.
An audit asks whether recorded hours match real work. Surveillance tools answer whether a person appeared busy at their desk, which is a different claim, and a weaker one: activity theater is easy to produce and mouse-jigglers cost ten dollars. Meanwhile the legal exposure is real, under the GDPR in Europe and the DPDP Act in India, and the message to your best people is that you do not believe them. Firms that go this route tend to collect worse data, because staff who feel watched enter time defensively instead of accurately.
The honest input you need comes from a system that makes accurate entry cheap and dishonest entry structurally visible, then leaves people alone.
Where LynxSprint fits
We build LynxSprint around exactly this model. Timesheets move through draft, submitted, approved, and locked states with a permanent audit trail on every decision; time is attributed to activities and work items; a weekly grid flags gaps and anomalies before the approver signs off; and record-level permission scopes keep data on a need-to-know basis. There are no screenshots, no keystroke logging, and no productivity scores, as a matter of design rather than a settings toggle. Early access is open, and the details are on the LynxSprint product page.