How far back timesheets go
Letting people log time whenever they like guarantees that some of them log a whole month on the last Friday, from memory. A logging window sets how far back a person may go, and choosing that number is a real decision with a cost on both sides.
A configurable window, plus a baseline of five working days for everyone.
What memory does to a timesheet
Recalled hours are smooth. Eight, eight, eight, eight, eight. Real weeks are not smooth, and the smoothing all goes one way: toward the project the person remembers best.
Small work vanishes first. The twenty minutes on a review, the interrupted afternoon, the half day helping someone else. Those are exactly the hours that explain where capacity went.
So a month logged from memory is not slightly wrong. It is wrong in a patterned way that makes utilisation look tidier than the month actually was.
The window, and what it costs
Set it too tight and you punish anyone who had a genuine reason to be away. A person back from a week of leave meets a closed window on their first morning.
Set it too loose and the window stops doing anything at all.
The product makes this a setting rather than a rule. Administrators configure how far back logging is allowed, and there is a separate baseline the product treats as ungovernable: everyone can log their own recap for the last five working days, whatever else their role permits.
The lifecycle the window sits inside
Timesheets are more than entries. They carry a status, and the audit log shows draft moving to submitted as a recorded change.
Administration works from a grid of people against weekdays, with hours in each cell, plus an approvals queue and a needs-attention view for the weeks that do not add up.
In daily use that approvals queue runs into dozens of pending items. A backlog is not a scandal, but an approvals queue nobody clears turns the status field into decoration.
The employee side shows the week's total against an expected forty hours, with a completion percentage, so the gap is visible before anyone chases it.
- A configurable window for how far back logging goes.
- A five-working-day baseline every employee keeps.
- A draft and submitted lifecycle, recorded in the audit log.
- An approvals queue and a needs-attention view.
- Expected hours and completion shown to the person logging.
Picking a number
Most teams land somewhere between one and two weeks, because that spans a normal leave absence without inviting month-end reconstruction.
Whatever you choose, pair it with a reminder rather than only a deadline. A weekly nudge into a chat channel closes more timesheets than a tighter window does.
And watch the approvals queue, rather than only the submissions. Time logged and never approved is a status field lying quietly.
The exceptions worth building in
A window with no exception path produces the worst outcome of all: hours that were worked and never recorded anywhere.
Somebody back from leave. Somebody who was ill. Somebody who joined mid-month and had no access in week one. Each is ordinary and each meets a closed window.
So decide who can log on another person's behalf, or reopen a period, and write it down. An undocumented exception becomes a favour, and favours are granted unevenly.
Keep a record of each one. A period reopened three times in a quarter is telling you the window is too tight, and that is a useful signal rather than an irritation.
Why the window is not really about discipline
It is tempting to read a tight window as a way of making people comply. That framing produces the wrong number.
The point is accuracy, and accuracy decays with time rather than with attitude. Two days later most people are roughly right. Three weeks later almost nobody is, however conscientious.
Which means the reminder does more work than the deadline. A weekly nudge in a chat channel closes more weeks than a shorter window, and it does it without a conversation about compliance.
Set the window to protect the data. Use reminders to get the behaviour. Mixing the two produces a rule people resent and data that is no better.
Making the logging itself quick
Most resistance to timesheets is not about being measured. It is about the form taking eleven minutes when it should take two.
The things that make it slow are usually fixable. A project list containing every project the company has ever run. No memory of what somebody logged yesterday. A required field nobody can answer at five in the afternoon.
Logging a day should be a short, dull action done at the end of it. Anything that turns it into a weekly reconstruction exercise has already lost the accuracy the window was protecting.
It also helps to show people their own totals. A week's logged hours against expected, with a completion figure, turns an obligation into a thing somebody can close.
Fix the friction first, then worry about the deadline. Most teams do it the other way round and wonder why the queue never clears.
Questions people ask
Can administrators change how far back people log time?
Yes. The logging window is configurable. Separately, every employee keeps a baseline of logging their own recap for the last five working days.
Do timesheets have an approval step?
Yes. Entries move through a draft and submitted lifecycle into an approvals queue, with a needs-attention view for weeks that look wrong.
What expected hours does the product assume?
Forty hours a week by default on the employee view, shown against what has been logged with a completion percentage.