The rules decide which products are viable. Everything else is detail
Timesheet software is chosen from demonstrations and fails on rule configuration, payroll reconciliation and the things nobody wrote down. Fifty notes on selection, integration, implementation and the years afterwards.
All 50 notes, in order
The sections run in the order the work does. Skipping an early one makes a later one harder, which is why they are numbered rather than listed.
Requirements
10 notesFour different products share this category name, and the rule engine decides which are viable at all. Plus the requirements that start with "not", which are the ones that get skipped.
Evaluation
4 notesConvert every claim into a question with a checkable answer, then make the vendor demonstrate your own awkward case rather than their example.
The data model
6 notesThe fields that decide disputes are the ones nobody looks at until there is one. Plus the three time cases that break products and are entirely predictable.
Integrations
6 notesEvery integration here is a join between systems, and the join fails on whatever identifier someone chose casually. The reconciliation is what turns a silent failure into a Tuesday email.
Implementation
6 notesInstallation is an afternoon. Rule discovery, reconciliation and organisational agreement are the project, and plans that allocate time the other way round run late in the same place every time.
Running it
9 notesThe project ends at go-live; the system generates work every period indefinitely. That work is routinely unassigned, and every failure below follows from it.
Commercial terms
5 notesTwo vendors quoting the same per-seat figure can differ threefold over a term. And the lock-in is not in the data, which exports, but in everything built around it.
Reference
4 notesWhat no product resolves, the asks that should be declined, and a description of the end state to measure a proposal against.
What this is
Fifty notes on timesheet software, written for whoever has to choose it, implement it, and still be running it in three years.
The core notes are vendor-neutral. A separate comparisons section applies the same requirements to named products.
Four things that hold
The rule engine decides which products are viable. Everything else can be worked around; a fixed engine that cannot express your overtime rules cannot be configured into one that can.
Rule discovery is the project's critical path. Most organisations cannot list their own pay rules, and the list determines the shortlist, the configuration effort and the timeline.
Three parallel periods, compared line by line. One period finds gross errors and leaves the rule errors to reach a payslip. Totals match while individual figures are wrong in both directions.
The system generates work every period, indefinitely, and someone must own it. Almost every operational failure in these notes follows from nobody having been named.
Where to start
Nothing chosen yet: requirements, particularly what you are actually buying and the rule engine.
A product chosen and a date set: implementation.
Live and troublesome: operations, then common failures.
A renewal approaching: commercial terms, and the note on where lock-in actually lives.
What this is not
Not legal advice. References to recording duties, retention and consultation requirements are general and vary by jurisdiction.
It does not describe how to configure screen capture, activity scoring or automatic idle deduction. Those appear only in the notes about excluding them.
Independent software comparisons
Use the notes to define the rules, then compare products against them. Start with our guides to 7 time tracking tools, 9 attendance systems and 12 workforce operations platforms. For a featured product reference, visit Monitask.