Project timesheets: tracking hours by project so client billing adds up
The project finished on time, the client is happy, and the margin is a mystery. The board says every card moved. The timesheet says 340 hours went somewhere that month. Neither one can say how many of those hours belonged to this client, because the board tracks work and the timesheet tracks people, and nothing joins them. Someone reconstructs an answer from calendar entries and chat, calls it close enough, and the next quote gets priced on that guess.
This is the ordinary failure of timesheet project management in small teams. It is rarely a discipline problem. It is a structural one: hours are recorded in a place that does not know what the projects are.
Why hours by project is a different problem from hours worked
Payroll needs one number per person per week. Project reporting needs that same total split across several projects, and the split is the hard part.
A person who spends a day on one project has an easy sheet. A person who answers a client question in the morning, works on a second project until lunch, joins an internal meeting, then reviews someone else's work on a third project has four entries for one day, and only the first is memorable by the afternoon. Multiply that across a week and the split becomes a reconstruction rather than a record.
Three things follow from this.
The split has to be recorded close to when it happened. Not because people are careless, but because the information genuinely stops existing. A day reconstructed on Friday is dominated by the largest task and loses everything under an hour.
The list of projects has to be fixed and short. If the person entering hours can type any name, the same project appears under several spellings, and the report that adds them up is wrong in a way nobody notices.
Work that belongs to no project needs its own home. Internal meetings, recruitment, admin and sales are real hours. Without a row for them, they get allocated to whichever client project happens to be open, which inflates that project and hides the true cost of running the business.
The shape of a usable project timesheet
The sheet that answers billing questions is a grid with two directions of totals.
- One row per project or client, plus one row for non project work.
- One column per day.
- A total at the foot of each column, which is the person's day.
- A total at the end of each row, which is the project's week for that person.
That second total is the whole point. A timesheet that only totals downward answers payroll and nothing else.
What each project row should carry
Beyond hours, two fields make the difference between a record and an invoice line.
A work type field, kept to a handful of values such as design, build, review, meeting, lets the same project be analysed by activity. It is also what makes a quote for the next similar project better than a guess.
A billable flag or a separate rate per row matters as soon as some hours are chargeable and others are not. Internal rework on a fixed fee project is real time that should not be invoiced, and a sheet with no way to mark it forces the distinction to be remembered at invoice time.
Increments
Pick one increment for the whole team, half hours or quarter hours, and use it everywhere. Finer grids do not produce finer truth. They produce estimates with more digits, which is worse than a rounded number that everyone knows is rounded.
The increment also caps how many rows a person can fill honestly. In half hour steps, four or five project rows a day stay believable. In five minute steps, the same day turns into twelve entries that were reconstructed rather than observed. If the team genuinely switches between projects a dozen times a day, the problem to solve is the switching, not the resolution of the sheet.
Keeping the project list honest
Every unreliable project report traces back to the same root cause. The list of projects on the timesheet is maintained separately from the list of projects the team actually works on.
The pattern is familiar. Work is planned on a kanban board or a Gantt chart. Hours are recorded in a spreadsheet that was set up once and copied each month. A new client arrives and goes onto the board immediately, because that is where the work is. It reaches the timesheet whenever someone remembers, often typed slightly differently. Three months later the report has "Northwind", "Northwind Ltd" and "NW site" as separate lines, and the person reading it has to know they are the same.
There are two ways out, and only one of them works long term.
The first is a naming convention and a monthly tidy up. It works while someone cares about it and decays when that person is busy.
The second is structural: the timesheet draws its project rows from the same place the work is planned. A new project appears on the sheet because it exists on a board, not because someone retyped it. This removes the class of error rather than catching it. Tools differ a lot on whether they do this, and many popular board tools carry no hours at all, so the comparison pages are a practical place to check which ones join the two.
Two decisions make that structure work in practice. The first is what counts as a project on the timesheet. A client with five separate pieces of work can be one row or five, and the right answer is whatever the invoice and the quote use, because those are the documents the totals have to reconcile against. The second is what happens when a project ends. Rows for finished projects should stop appearing on new sheets while their history stays intact, otherwise the grid grows every quarter until people skip rows out of fatigue and the entries drift to whatever is nearest the top.
Entry habits that survive a busy week
Even a well shaped sheet fails if it is filled in once a month.
End of day, not end of week
The most effective change available is moving entry from Friday afternoon to the last few minutes of each day. It costs a minute or two and it is the difference between a record and a recollection. A sheet that saves as numbers are typed, and opens from the same place the work already lives, makes that minute realistic.
Entry on behalf of others
Someone is always away on the day the sheet is due. A lead who can enter or correct hours for a team member, with that action visible, keeps the period closeable without inventing numbers in the payroll export.
Cross-checks, used lightly
Calendar entries show meetings. Card and board history shows what moved and when. Neither is a timesheet, and neither should be turned into one automatically, because a card moving does not mean hours were spent. They are useful for reconstructing a day that was missed, and useless as a substitute for daily entry.
A short weekly close
A fixed weekly close, for example sheets submitted Monday morning and approved by Tuesday, does more for data quality than any reminder. Once a week is approved it should lock, and a correction should mean sending it back rather than editing it silently, so that the numbers used for an invoice can still be explained a year later.
Turning hours into an invoice
Where hours become money, the sheet has to know what kind of arrangement each person is on. Treating everyone as hourly is the most common simplification, and it quietly corrupts the reporting.
| Arrangement | What the sheet needs | What the report should show |
|---|---|---|
| Hourly | Hours by project, a rate, a billable flag | Hours times rate, per project |
| Per project or fixed fee | Hours by project for cost only, never for the invoice | Cost against a fixed price, so margin is visible |
| Fixed monthly retainer | Hours by project for capacity | Hours consumed against what the retainer assumes |
The middle row is where most small teams lose money without seeing it. On a fixed fee, hours do not change the invoice, so nobody watches them, and the project that ran to double its estimate looks identical to the one that came in under. Recording hours on fixed fee work is not about billing. It is the only way the next fixed price is better than the last one.
For teams with a mix of employees and contractors, the same sheet has to hold all three arrangements at once, and produce totals per person, per project and per work type without manual copying. The features overview shows one arrangement that handles hourly, per project and fixed monthly contracts on the same timesheet, and the guide covers the setup.
Reading the totals without fooling yourself
A project hours report invites two mistakes.
The first is treating hours as productivity. They measure time spent, not value produced, and a team that is measured on hours will produce hours. The useful comparison is always hours against something else: against the estimate, against the fee, against the same work done last time.
The second is comparing people. Two developers on the same project will record different splits because they work differently and because one is more willing to write down the twenty minutes spent helping someone else. Comparing person to person punishes honest recording, and the data degrades within a month of anyone noticing.
The comparisons that hold up are project against estimate, project against fee, and the same project type across quarters. Those are the ones that change a quote.
There is a third trap worth naming: reading a single period as a trend. One month of hours on a project is noise, because a launch week, a holiday and one long client revision move the figure more than anything structural. Wait until the same project type has been measured three or four times before changing a price on the strength of it. The number that deserves attention immediately is the share of hours landing on non project work, since that is the one most teams have never measured at all and it usually turns out to be larger than expected.
What to change first
Add a row per active project to whatever sheet is in use, plus one row for non project work, and total each row as well as each column. Then move entry to the end of each day. If the project list on the sheet and the projects on the board have already drifted apart, keeping boards and hours in one place is the fix, and Pinateca is free for up to 5 people with timesheets available as an add-on.
Q1. How granular should project time tracking be?
Track to the project, and to a handful of work types within it, in half hour or quarter hour steps. Tracking to individual tasks sounds better and usually collapses within a few weeks, because the effort of switching entries exceeds the value of the detail. Start coarse and add detail only where a specific decision needs it.
Q2. Should hours be tracked on fixed fee projects?
Yes, but for cost rather than billing. On a fixed fee the hours do not change the invoice, so they are the only way to see whether the price was right and to price the next one better. Teams that stop recording hours on fixed fee work lose the ability to tell a profitable project from an unprofitable one.
Q3. Why do timesheet project totals never match the project plan?
Usually because the two lists are maintained separately, so project names drift apart and non project work gets allocated to whichever client is open. The second cause is entry from memory at the end of the week, which loses everything shorter than about an hour. Sharing one project list between the plan and the sheet removes the first cause.
Q4. Can time tracking be automated from task boards?
Partly, and with care. Card movements and calendar entries are good for reconstructing a day that was missed, but a card moving to done says nothing about how many hours it took. Automatic timers work for focused solo work and misreport days full of interruptions, so they are best treated as a prompt for entry rather than the record itself.
Q5. Who should approve project timesheets?
The person accountable for the project budget, rather than a central administrator, because only they can tell whether a split looks wrong. Keep the approval inside the timesheet with a visible submit, approve and send back step, so the trail is still there when an invoice is questioned months later.
