Most consultancies build their timesheet approval workflow around two steps: a consultant submits, and someone approves. It looks complete on a whiteboard. In practice, submit-then-approve is not a workflow at all. It is a queue with a name, and everything that happens between those two points, who is meant to look at it, how long they have, and what happens if they do not, gets left to whoever remembers to chase it.
A timesheet approval workflow that actually holds up needs more than two steps. It needs distinct stages, each with a clear time boundary and a named owner: a submission window, a first review, an escalation route, a correction step, and a final sign-off. Skip any one of them and the workflow degrades in a specific, predictable way. This guide goes through each stage, what breaks when it is missing, and how to design it for a consultancy billing client hours.
Why submit-then-approve breaks down
Submitted and Approved, or Rejected, describe an outcome. They do not describe a process. A workflow built on just those two steps tends to fail in the same four ways.
Nobody owns the wait. If a timesheet has been sitting in a queue for six days, whose job was it to notice? With only "submitted" and "approved" as markers, a stalled timesheet looks identical to one that was reviewed an hour ago. There is no stage boundary to say it has been waiting too long.
Decisions get inconsistent. Without a defined first-review stage with its own standard, what to check, how fast, what counts as done, different approvers apply different bars. One approves anything that looks roughly right; another queries every ambiguous row. The workflow, not the individual approver, should set that bar.
There is no route around a blocked approver. An approver on leave, an approver who has left the client altogether, a project whose named approver nobody remembers assigning: a two-step model has no answer for any of these. The timesheet just waits.
Correction and rejection get conflated. Rejected often gets treated as the end of the story rather than the start of a fix. Without a distinct correction stage, a rejected timesheet either stalls with nobody sure whose move it is, or gets nudged back into the queue with nothing actually changed.
The five stages a timesheet approval workflow needs
A workflow that avoids all four failures names five stages, not two. Each one has an owner and a boundary.
- The submission window, owned by the consultant filing the timesheet (or whoever files it on their behalf), bounded by a submission deadline the consultancy sets.
- First review, owned by the named approver on that project, bounded by a decision window measured in days, not "whenever".
- Escalation, owned by a consultancy admin, triggered when first review stalls or the named approver cannot act at all.
- Correction, owned by the consultant, bounded by however long it takes to fix what the reviewer flagged, and nothing else.
- Final sign-off, owned by a consultancy admin, distinct from first review and the point at which hours actually become billable.
Here is what each one is for, and how to build it.
1. The submission window
This stage runs from the moment a consultant starts logging hours to the moment they submit. Its owner is the consultant filing the timesheet, or an admin filing on their behalf for a consultant who cannot log in themselves. Its boundary is a submission deadline the consultancy sets and holds to, tied to the invoicing run it feeds. If invoices go out on the first of the month, the submission window has to close early enough that everything downstream still fits.
What breaks without it: hours arrive on a rolling, unpredictable schedule, so every other stage inherits the unpredictability. An approver cannot plan a review day if timesheets land whenever consultants get around to it.
In TimeSubmit, a timesheet can only be edited while it is a Draft. Submitting locks it, and the only person who can write to it at all, at every stage, is the person who filed it, or the admin who filed it on someone's behalf. That ownership rule holds across every edit, so the submission window has exactly one person accountable for closing it.
2. First review
This stage runs from submission to a decision by the named approver on that project. Its owner is that approver, not whoever happens to be free. Its boundary should be a decision window in days, agreed as policy and short enough to leave room for correction and sign-off before an invoicing run.
What breaks without it: approval time becomes a function of how busy the approver happens to be that week, and consultants learn not to expect a decision on any particular day.
TimeSubmit scopes this stage tightly: an approver only ever sees timesheets carrying at least one entry on a project they are actually set up to approve, both in their queue and when opening a timesheet directly. Approve fires the moment it is clicked, and reject is deliberately the harder path: it stays disabled until a reason is typed, and on the full review screen a confirmation step echoes that reason back before the rejection goes through. The same decision is available from the queue row itself, where rejecting opens the reason field in place, so a routine week can be cleared without opening the full review screen at all.
3. Escalation
This is the stage a two-step workflow has no room for. It runs whenever first review stalls: an approver on leave, an approver who has moved on, a project whose named approver record was never kept up to date. Its owner is a consultancy admin, and it should trigger on a defined condition, the decision window from stage two passing, or the approver being known to be unavailable, rather than someone eventually noticing.
What breaks without it: the timesheet does not get rejected and it does not get approved. It just sits, and everything after it, invoicing included, sits with it.
TimeSubmit gives escalation a real mechanism rather than leaving it to a manual workaround. A consultancy admin can force-approve or force-reject any timesheet through admin override, but only with a written reason, and that reason, along with who used it and when, is stored on the timesheet and, on Margin and Enterprise, where the plan keeps an audit log, written there too. It exists precisely for the case the normal route cannot reach, an approver who has left being the clearest example, not as a shortcut around a working queue. Where several approvers are involved and a consultancy has turned on sequential approval, available on Margin and Enterprise, escalation is partly designed out at the source: an approver who cannot act, an inactive record, a deleted or deactivated account, or someone whose stored role there is no longer timesheet approver, is skipped automatically, so they never hold up the approvers who come after them.
4. Correction
This stage runs from a rejection to a resubmission, and it belongs to the consultant, not to whoever rejected the timesheet. Its boundary is simply "as long as it takes to fix what was flagged", but it needs to be a distinct step with its own state, not a silent return to the submission queue.
TimeSubmit treats correction as a deliberate, two-part handback rather than an automatic reset. Rejecting moves a timesheet to Rejected, with the hours left exactly as they were and the approver's reason attached; it does not drop straight back into Draft on its own. The consultant has to take a separate Reopen action to move it into Draft, and only from there can anything actually be edited and resubmitted. That extra step matters: a rejected timesheet sitting untouched, with its reason attached, is a record of what needs fixing, and it stays legible until the consultant deliberately picks it back up.
One thing worth building into this stage as policy, even though it is a small piece of it: a rejection reason that names the specific row and what is wrong with it gets fixed once. A vague one just produces a second round trip through the whole workflow.
5. Final sign-off
This is the stage a simple submit-then-approve model erases entirely, by folding it into first review. It runs after every named approver on the relevant projects has approved, and it belongs to a consultancy admin, distinct from whoever gave first review. Its boundary is short, because everything else has already been checked; it is a control point, not a second detailed read.
What breaks without it: a project with two or three approvers has no single moment where a timesheet becomes billable, and no one person accountable for that last check before hours reach a client invoice.
This is exactly how TimeSubmit's own approval chain is built, not an analogy borrowed from elsewhere. Every active approver on the projects a timesheet covers has to approve their own part; only once all of them have done so can a consultancy admin give the final approval, and it is that action, not any individual approver's, that actually moves the timesheet to Approved. Admin override sits alongside this stage rather than inside it: it can bypass the whole chain when the escalation stage needs it to, but the ordinary route always ends with a named admin's sign-off. Only an approved timesheet becomes eligible for invoicing, so final sign-off is the actual gate between logged hours and money asked for.
Designing each stage for your consultancy
Use this as a working checklist when you set, or reset, your own timesheet approval process.
- Write down the submission deadline and tie it to the invoicing date it feeds, not to a vague "end of week".
- Name one approver per project, not one manager for the whole team. A project's approver should be able to vouch for the work first-hand.
- Set a decision window for first review in days, and treat a timesheet that crosses it as stalled rather than merely slow.
- Decide, in writing, who escalates and on what trigger. "Someone will notice eventually" is not an escalation stage.
- Require a reason on every rejection, and make it specific enough that a consultant can act on it without a follow-up question.
- Separate correction from resubmission review. Fixing a flagged row is not the same task as reviewing a whole timesheet again from scratch.
- Give final sign-off to a named role, not to whichever approver happens to finish last. On a project with several approvers, that role has to be someone other than the approvers themselves.
- Confirm the gate between approval and invoicing is real: hours should not reach a client invoice before they are actually approved.
TimeSubmit's approval workflows are built around exactly these owners: per-project approvers for first review, a consultancy admin for final sign-off and for escalation through admin override, and a locked, ownership-checked path for correction. The consultant's side of this same process, what to log and how a timesheet moves through the statuses once it is filed, is covered in the timesheet submission process, an approver's guide.
Common questions about timesheet approval workflow stages
What are the stages of a timesheet approval workflow?
Five, ideally: a submission window bounded by a deadline, a first review by a named approver, an escalation route for when that approver cannot act, a correction stage for anything rejected, and a final sign-off distinct from first review that makes hours billable. Submitted and approved describe an outcome rather than a process.
What is the difference between first review and final sign-off?
First review is the per-project check by the person who can vouch for the work: did it happen, is the amount plausible, is it on the right project. Final sign-off is a separate, later check, once every relevant approver has already approved, that turns those individual approvals into one billable decision. Folding the two together removes the one point where a project with several approvers gets a single, accountable answer.
Who should own escalation in a timesheet approval workflow?
A consultancy admin, not another peer approver. Escalation exists for the cases the ordinary review stage cannot resolve on its own, an unavailable or departed approver being the clearest case, and it needs a role with the authority to force a decision and the accountability that comes with a written reason for doing so.
How do I reject a timesheet properly?
Reject with a reason that names the specific row and what is wrong with it, rather than a general comment. A specific reason gets fixed in one pass; a vague one produces another round of the same mistake. Treat the correction that follows as its own stage: the consultant fixes what was named and resubmits, rather than the timesheet quietly resetting to the front of the queue.
Why does a timesheet approval workflow need a distinct correction stage?
Because rejection and correction are different jobs, done by different people, at different times. Without a separate stage, a rejected timesheet either stalls because nobody is sure whose move it is, or gets nudged back into the review queue unchanged. A correction stage gives the consultant a clear, bounded task: fix what was named, then resubmit.
Does every consultancy need all five stages?
A very small team with one approver and one admin can sometimes fold escalation into final sign-off, since the same person may hold both. What should not be folded together is first review and final sign-off on any project with more than one approver, and correction should never be silently merged into resubmission. The five stages describe roles that need separating, not necessarily five different people.
Want to run a five-stage approval chain, submission through admin sign-off, on your own projects? Start a 60-day trial on the Practice plan, then $39 a month.