Timesheet Close: Why a Grid Is Still a Draft

Finance asks for last month's hours on the 3rd. Aleksandra still has Tuesday open on her week grid. She is not being difficult. Nobody ever asked her to stop. The grid looked finished because it was full. Full is not closed.
Most time-tracking tools sell the grid as the product. Cells, timers, a CSV. The hard part is not capturing hours. It is deciding, in writing, that those hours are the ones you will stand behind. Until that happens, a timesheet is a draft that happens to have numbers in it.
Three jobs pretending to be one
Logging, signing, and closing are different acts. Tools that collapse them produce one of two failures, both expensive.
The forever-editable sheet. Anyone can change last month until someone notices. Payroll exports a file on Friday. On Monday a manager "corrects" a cell. Now you have two truths and no record of which one the accountant used. The named wound in this category is "who changed my hours."
The frozen archaeology. Edits lock so early that honest mistakes become tickets. People wait until Friday afternoon, invent a plausible week from memory, and submit fiction because the alternative is a locked empty cell. We covered the culture of that failure in surveillance-free timesheets. The missing piece is the declaration: a point at which the person says this week is complete, a manager agrees, and an admin can freeze the books for payroll.
A grid without those two later acts is a notepad. Useful. Not a record.
Submit is a signature, not a reminder
The useful unit is a period, not a cell. A week (starting on the workspace's first weekday) or a month. The person who did the work submits the whole period. Submitting snapshots what was logged and what the schedule expected at that moment. Later edits to the live grid cannot rewrite the snapshot a manager will see.
That snapshot is the point. If Aleksandra logged 38 of 40 expected hours on Friday and submits, Monday's manager is reviewing 38 of 40, not whatever she typed over the weekend. The period locks for everyone until it is decided or withdrawn. "I will just fix it on Monday" is a withdraw, a change, and a resubmit, not a silent patch.
A manager reviewing their people should not be able to approve their own sheet. Self-dealing on hours is how a founder-operator ends up as the only signature on a capitalization claim. An admin can, and the audit log says so. Rejection is a return with a reason: the period opens again, the reason sits on the sheet, and the next submit is a new declaration.
Returned, not vanished. A timesheet that disappears when it is sent back teaches people to wait until the manager is in a good mood.
Close is the payroll lock, and it includes you
Submit and approve still leave an escape hatch: reopen, with a reason, and the cells move again. That is correct for a week that was signed off too early. It is not correct for a month payroll has already run.
Close is a date, not a status on a person. An admin sets "closed through" to the last day of the period that just hit payroll. Every entry on or before that date is read-only for everyone, administrators included. Moving the date earlier, or clearing it, needs a reason and lands in the audit log. Silent admin bypass is the same wound, just wearing a higher role.
Two things close does not do, on purpose. It does not freeze attendance punches; those have their own review queue. It does not freeze leave; an approved absence already changed the expected hours the timesheet compared against.
The rolling backdate window sits underneath both locks. It stops casual archaeology. It does not substitute for a close. A seven-day window on a 30-day payroll cycle leaves three weeks of last month editable after the file has gone.
Worked example
Northlake's period is a week. Aleksandra works Monday to Friday, 8 hours a day. By Friday 17:00 she has 38 hours on Platform v2 and 2 hours still on "I will log it on Monday." She submits anyway. The sheet records 38 of 40 and locks Monday through Friday.
Monday morning she remembers the missing two hours were Bug triage, not Platform. The cell will not take them. She withdraws, the period opens, she moves 2 hours, and she submits again: 40 of 40. Marta, her manager, opens Time tracking → Team timesheets, sees the awaiting-approval count, and approves the week. The snapshot still says 40 of 40.
On the 3rd of the next month, Marta (admin this time) sets Workspace settings → Time tracking → Close time through the last Friday. Aleksandra cannot edit. Marta cannot edit either. A missed sick day on that Thursday becomes a reopen with a written reason, a correction, and a close again. The accountant's file and the grid can finally be the same object.
The arithmetic that matters is not 40. It is that 38 was a real state, signed, then replaced by a second signature, then frozen. Three states, three people who can explain them.
What this is not
It is not auto-submit. A Friday cron that files people's weeks for them produces the archaeology the lock was meant to prevent, just with a timestamp. Reminders exist. Filing is still a person.
It is not a per-project approver. Hours against work are one period and one manager. Splitting approval by Jira project is how a week never closes.
It is not on the Free plan. Submit, approve, and close are Team and Enterprise. A workspace that later downgrades still sees its locked history; the lock does not evaporate because the bill did.
Where SquadBear keeps this
Time tracking → My week (or My month, when the workspace submits monthly) is where you file. Submit for approval locks every date in the period. You can Withdraw until a manager decides. The badge reads Submitted, Approved, Returned, or Reopened, and the line under it quotes the snapshot: logged of expected.
Managers decide on Time tracking → Team timesheets and in Inbox. The review page is /time/timesheets/<id>: submitted totals on top, live entries underneath, Approve or Return with a reason. Browsing a different week on that page does not shrink the decision. The decision is the period that was filed.
Workspace settings → Time tracking holds the other two knobs. Submit timesheets per is week or month (refused while anything is still awaiting a decision). Close time through is the payroll date. Backdate limit is the archaeology window for everyone who is not an admin.
If you'd rather not open the grid:
"Submit my current timesheet period, then tell me what was logged against what was expected."
The timesheet mechanics page is the week-to-week reference; classifying engineering time is why finance wanted the file in the first place.
Start free and file one real week before payroll asks, or open the demo and return a sheet with a reason.
Related reading: surveillance-free timesheets, which is the culture this lock sits on, and CapEx vs OpEx for engineering time, which is the money the closed file is supposed to support.



