Somebody wants your timesheet. It is due Friday, you half remember what you did on Tuesday, and you would rather be doing almost anything else.
Timesheet submission is a small job that turns into a large one when it goes wrong. Fill it in carelessly and it comes back four days later with a one-line comment that does not say what to change. Fill it in properly and it is fifteen minutes a week you never think about again.
So here is the practical version of how to submit a timesheet: what the form is for, what to put in each entry, what your approver is looking at, and the five reasons yours might bounce.
What a timesheet submission is actually for
Most people assume the timesheet exists to check up on them. In a consultancy it almost never does. The timesheet submission process exists because your hours are the invoice.
The chain is short and entirely mechanical. You record hours against a project. Somebody with authority confirms they happened. Those hours become a line on a client invoice, the client pays it, and that money pays everybody, including you. Break the first link and every link after it waits.
So an empty Wednesday is a problem and a vague Wednesday is a bigger one. Nobody is reading your week to judge your productivity. They read it because in a fortnight a client finance team reads a version of the same thing, and it has to survive that reading.
Unbillable time still goes on the timesheet: internal work, training, pre-sales, sick leave, holiday. A week showing 22 hours because you logged only the billable ones looks like a week you half worked, and somebody will ask.
The weekly rhythm, and why Friday matters
Most consultancies run a weekly cycle with a deadline on Friday afternoon or first thing Monday. That deadline is not arbitrary. Behind it sits an approval queue, and behind that an invoicing run on a fixed date.
Miss Friday and you have not only inconvenienced yourself. Your approver now reviews your week in the middle of theirs, with less context and less patience. Miss it badly enough and your hours drop past the invoicing run and get billed the following month. That is real money standing still for four weeks, and it gets traced back to you.
The other reason Friday matters is memory. Reconstructing a week at half past five on Friday is guesswork, and guesses produce the entries that get queried. Two minutes at the end of each day beats forty at the end of the week.
One habit is worth more than any of this advice: put a recurring 15-minute block in your calendar for Friday at four. Not five, because at five you are already gone.
What goes in each entry
A timesheet row is usually four things: the project, the date, the hours, and a description. The last one is what gets your week sent back.
Pick the right project, and if you do not know which of two codes a piece of work belongs to, ask before you submit rather than after. Time on the wrong project is worse than time missing entirely, because it quietly bills the wrong client. Put the work on the day it happened, too: backdating Thursday into Friday looks tidy to you and wrong to anybody comparing your week against a stand-up log.
On hours, follow whatever rounding convention your firm uses, usually to the nearest quarter or half hour, and be honest about the awkward ones. A 45-minute call is 0.75, not "call it an hour". If you worked eleven hours on Tuesday, put eleven hours on Tuesday. Smoothing a long day across the week to look normal is falsifying a billing record, which is a different problem entirely.
The description is the bit a client might read, so write it for them. "Development work" tells nobody anything. "Fixed the duplicate-invoice bug in the billing export and added a regression test" tells your approver it happened and a client what they bought. Ten words is usually enough. Anything you would be comfortable seeing quoted back at you in a dispute is the right standard.
Two small things cause disproportionate trouble. Set billable and non-billable deliberately rather than leaving the default, which is wrong about half the time. And if a day was annual leave or a bank holiday, say so, so a zero reads as an explanation rather than an omission.
What your approver is actually checking
The timesheet approval process is not an audit of you. Your approver is usually a project lead or a client-side manager with a queue of these to get through, answering four questions.
Did this work happen? They match your rows against what they saw: stand-ups, meetings they sat in, work they asked for. Anything they cannot place is a query.
Is the shape plausible? Twelve hours on a Sunday with no note, or forty hours on a project scoped at twenty, gets stopped. Not because either is impossible, but because both need a sentence and neither has one.
Is this the right project? They check the code, especially if you split time across two engagements for one client.
Would the client accept the wording? This is the one people underestimate. Your approver is the last reader before your description becomes something a client sees, and they bounce anything they would not want to defend.
Write with those four in mind and most approvals take about eight seconds, which is exactly what you want.
Five reasons a timesheet gets sent back
- The description is too vague. "Project work", "meetings", "admin". Rewrite the row naming what you produced or attended. If the work really was administrative, say which: "Weekly status report and updated the risk log."
- The hours are on the wrong project. Common when two engagements run for one client, or when a project code changes mid-quarter. Move the hours rather than adding a note explaining that they are in the wrong place.
- The week does not add up. A missing Wednesday, or a total that does not match a contracted pattern. Add the day, or a line saying what it was. Leave, illness, and a bank holiday are all legitimate answers, and none can be read off a blank cell.
- The work is outside what was agreed. You went over the budgeted hours, or did something nobody asked for because it obviously needed doing. Both are fine and both need a sentence in the description, before you submit rather than in an email afterwards.
- It arrived too late to review. The approver has closed their period, so your week becomes an exception somebody handles by hand.
Resubmitting without redoing the week
A rejected timesheet is not a deleted one. In most tools it returns to draft with your hours intact and a reason attached, so you are editing, not starting again.
Read the reason properly first. Rejections are terse, and the temptation is to make a cosmetic change and fire it straight back, which earns a second rejection and another four-day round trip. If the reason does not say what to change, ask once, naming the row you think they mean.
Then change only what was named. Rewriting rows nobody queried hands your approver a whole fresh document to check. Keep the conversation in the timesheet tool rather than in email, too: when somebody asks in March why an invoice line reads the way it does, a comment on the timesheet is findable and an email thread is not.
The check before you press submit
Thirty seconds, once a week.
- Every day has either hours or a stated reason for having none
- The weekly total is what you expect it to be
- Every row sits on the project it was actually done for
- Every row with hours has a description naming something specific
- Billable and non-billable are set deliberately, not left on the default
- Anything unusual, a long day or an overrun, carries a one-line explanation
- Leave and bank holidays are recorded the way your firm asks
- It goes in before the deadline, not after it
Common questions about timesheet submission
How do I submit a timesheet?
Open the current period in whatever system your firm uses, add a row for each project you worked on, and enter your hours against the day they were worked, with a short description of what you did. Check the weekly total, then use the submit or send for approval control. Submitting usually locks the timesheet, so settle anything doubtful first.
What happens after I submit a timesheet?
It moves into an approval queue rather than straight into an invoice. Somebody who can vouch for the work approves it or rejects it with a reason, and in many consultancies a second sign-off follows before the hours count as final and billable. A submitted timesheet is therefore not an approved one, which is why the status is worth checking a day or two later.
What should I write in the description on a timesheet?
Write what a client would need in order to accept the charge. Name the deliverable, the meeting, or the ticket, and say what changed: "Drafted the data migration plan and reviewed it with the client architect" rather than "Migration work". Ten words is usually enough. Avoid internal shorthand and project nicknames, which the reader at the other end may not know.
What happens if I submit my timesheet late?
Your hours may miss the invoicing run for that period, so the client is billed the following month instead. Your approver also reviews your week outside their normal cycle, with less context, which is why late timesheets get queried more often than punctual ones. If you know you will be late, say so in advance.
Can I change a timesheet after submitting it?
Usually not directly. Most systems lock a submitted timesheet so the version under review cannot move while somebody is reading it. If you spot a mistake, tell your approver, who can reject it back so you can correct it and resubmit. Once it has been approved and invoiced, the correction normally lands as an adjustment in the next period.
If you run the consultancy
Everything above is for the person filling the thing in. If you are the one chasing them, the part worth your attention is what happens after the submit button, because that is where invoices go wrong more often than the entry does.
A recorded hour is not an hour you can bill. It has to be confirmed by somebody who knows whether the work happened, then confirmed again by somebody accountable for what leaves the building. In TimeSubmit that is three steps rather than two: the consultant submits, the timesheet approver approves their part, and a consultancy admin approves after that. Only then does the timesheet reach Approved, and only an Approved timesheet can be pulled into an invoice. Where several approvers cover a week, all of them have to approve before that final confirmation is available.
Rejection is deliberately not symmetric. An approver's rejection sends the week straight back to the consultant on its own, because a wrong week should stop moving at once, while a right one can wait for the second signature.
That makes the two failure modes consultancies actually suffer from hard to reach. Unreviewed hours cannot be invoiced, and nobody loses track of who signed off what, because the decision sits on the timesheet rather than in somebody's mailbox.
The two pages worth reading next are approval workflows, on who can approve what and what an approver sees, and invoicing, on what happens to those hours once approved.