To track billable hours across multiple projects, attribute each commit, review, and meeting to a client automatically using repo names, branch patterns, and calendar metadata — not a running timer you have to remember to switch. The output is a reviewable timesheet per project, per week.
You jump between three client repos, take two calls on a fourth project, review a PR on a fifth, and end Friday with a timesheet that says “development — 40 hours” across all of them. That is the moment a week of billable work turns into a guess. This guide walks through why manual multi-project tracking fails, how to build a project taxonomy that holds up under audit, how to attribute developer signals automatically to the correct client, and the specific traps that quietly drain revenue from agencies and freelancers who juggle several engagements at once.
Why does multi-project time tracking fail for most developers?
The failure mode is not laziness. It is the mismatch between how developer work actually flows and how most trackers expect it to be logged. A developer who ships across three clients in a day is not forgetting to track time — the tool is forgetting to follow them.
Timer fatigue and the 20-switch day
A typical engineering day includes 15-20 context switches between projects, tickets, and tools. According to Atlassian’s 2025 survey of 3,500 engineers, context switching between tools is the third largest productivity killer for developers. Expecting a human to stop, start, and relabel a timer that many times is unrealistic. Most abandon the habit within two weeks.
Research on cognitive interruption has measured the cost directly. A developer juggling three projects operates at roughly 60% efficiency compared to single-project focus, and it takes an average of 23 minutes to refocus after each interruption. A tracker that adds another interruption is part of the problem, not the fix.
Misallocation and the Friday catch-up
When Friday afternoon arrives and the week needs to be allocated from memory, recall fails in predictable ways. Hours get attributed to the wrong client. Long meetings get rounded down. Quick Slack threads and email replies disappear entirely.
A 2024 industry analysis of mid-size agencies found that manual time tracking typically loses 6-30% of billable hours depending on team discipline. For a ten-person agency billing at £120 per hour, even a 10% gap represents over £250,000 in annual revenue that was earned but never invoiced. That is the real cost of the Friday catch-up — not timesheet fatigue, but unbilled revenue at scale.
How do you build a multi-project time allocation framework?
Before picking a tool, decide what you are tracking. A clear taxonomy turns an ambiguous pile of activity into a reviewable set of line items.
Step 1: Define a project hierarchy
Three levels cover most professional services work:
- Client — the legal entity you bill
- Project — a specific engagement with that client (retainer, fixed-price build, discovery, support)
- Task category — what the activity is (development, review, meetings, research, fixes)
A week of work is then a set of Client > Project > Task triples with durations attached. Reports roll up or drill down along any dimension without re-entering data.
Step 2: Map each project to a source of truth
Every project needs a signal source the tracker can read. For software teams, the mapping is usually:
| Signal | Maps to | Evidence captured |
|---|---|---|
| Repository | Client or project | Commits, PRs, reviews |
| Branch pattern | Project or ticket | Feature-level attribution |
| Issue tracker board | Project | Ticket activity, time-in-status |
| Calendar invite | Project | Meetings, kick-offs, reviews |
If a project has no signal source, it is invisible to automated tracking and you fall back to manual entry. The goal of the mapping step is to minimise that blind spot.
Step 3: Encode identifiers in branches and commits
Branches and commit messages should carry ticket references that the tracker can parse. A regex like \b[A-Z]+-\d+\b catches most formats. For teams that already map git commits to billable time, this is the layer that lets a single commit in a multi-repo week find its right home automatically.
Step 4: Set billing rates per project and per role
Different projects carry different rates. Standard development might be £90 per hour, urgent hotfix work £140, discovery and architecture £160. Different roles on the same project can also vary. Store the rate table alongside the taxonomy so export time is a multiplication rather than a negotiation.
How does automated multi-project tracking work?
Once the taxonomy is in place, automation closes the gap between activity and timesheet. The principle is the same as setting up time tracking with GitHub: watch the signals developers already emit, then group them into sessions tied to the right project.
Repository-level attribution
A commit in acme-checkout rolls up to Client Acme. A commit in widgetco-api rolls up to Client Widget. When a developer switches repos mid-afternoon, the tracker sees the switch and splits the day accordingly. No timer toggle required.
For monorepos, path-based rules do the same job. A commit touching packages/acme/** attributes to Acme; one touching packages/widget/** attributes to Widget. Mixed commits split proportionally by file count or line count, depending on the rule you pick.
Branch-to-project mapping
Some clients run several projects in a single repository. Branch patterns let the tracker separate them. A branch matching feat/ACME-* maps to the Acme feature build; hotfix/ACME-* maps to the Acme support retainer with a different rate. The mapping is a small configuration file, reviewed quarterly.
Calendar blending for meetings
Commit activity misses meetings. Calendar integration fills the gap. A one-hour kick-off call whose invite references PROJ-142 attributes to Project PROJ. A recurring standup tagged to a specific client bills to that client by default. Meetings without project metadata get dropped into a review bucket for quick manual tagging.
Real-time dashboards
The final layer is visibility. A good multi-project dashboard shows, for any given day or week, how each developer’s hours split across active projects — before the invoice window closes. Managers spot misallocation while there is still time to correct it, rather than after an invoice has been issued.
How do you prevent revenue leakage across multiple projects?
The biggest source of lost revenue is rarely a missing day of work. It is hundreds of small tasks that never made it onto a timesheet. Four traps account for most of the damage.
Trap 1: Billable internal work that looks non-billable
CI pipeline fixes, tooling upgrades, and shared infrastructure work often support billable delivery but get logged as “internal” because the repo sits outside a client boundary. If a client project depends on a shared library your team maintains, the maintenance is billable to that client — allocate it proportionally to who consumed it.
Trap 2: Invisible coordination work
Slack threads, email replies, and five-minute “can you just look at this” calls add up. Individually they are too small to log. Collectively they can exceed 5 billable hours per developer per week. Calendar integration catches the scheduled ones. For the unscheduled, a weekly review prompt that asks “did you help anyone on another project this week?” recovers most of the rest.
Trap 3: Code reviews on someone else’s client project
A senior engineer who spends Tuesday morning reviewing a junior’s PR on Client B’s project is doing billable work for Client B, not Client A. If the tracker only watches commits, that hour is invisible. Trackers that subscribe to pull_request_review events capture it automatically. For more on this specific gap, see our guide on tracking time spent on code reviews.
Trap 4: Rounding down instead of to the billing increment
Fifteen-minute increments are the industry standard for professional services. Six-minute increments are common for high-value consulting. Rounding down to the nearest hour — or worse, forgetting to round up — silently discards billable time. A twenty-five minute client call rounded down to zero is £37.50 gone at a standard developer rate, repeated several times a week.
An industry estimate suggests that for a 15-person agency at a £100 per hour blended rate, missing just 15 minutes of trackable time per employee per day loses roughly £97,500 per year. That is purely the rounding trap. Fix the rounding rule, recover the revenue.
How do you handle edge cases in multi-project billing?
Some scenarios resist clean automation. The honest approach is to name them, handle them explicitly, and keep the audit trail clear.
Work that spans multiple projects
A piece of work that genuinely serves two clients — shared infrastructure, platform fixes, a migration that benefits everyone — should be split proportionally. Use commit activity as the split basis when possible. A session that touches both client-a and client-b code can split 50/50, 70/30, or by file count, depending on what the contract says.
Retainer projects versus time-and-materials
Retainer clients pay a flat monthly fee regardless of hours. Time-and-materials clients pay by hour. Tracking is still the same — every hour gets allocated — but the invoice does not. A retainer report shows hours consumed against the monthly cap; a T&M report converts hours to a bill. Keep both flows clean by marking projects in the taxonomy with their billing model.
Fixed-price projects that still need time tracking
Even fixed-price work needs time data. You cannot measure project profitability, plan the next bid, or spot scope creep without it. The difference is that the hours do not appear on the invoice. They appear in the post-project review, the realisation rate analysis, and the rate card for the next client.
Freelancers juggling short engagements
Solo freelancers often run five or six projects simultaneously, each smaller than an agency’s typical engagement. The same framework applies at smaller scale. One repo per client, consistent branch prefixes, calendar tags per project, and a weekly review. Teams already using GitHub to track time across multiple repos typically cut weekly timesheet effort from an hour to about ten minutes.
What are the practical steps to start this week?
Four moves take this from theory to a working system by next Friday.
- Write your project taxonomy. List every active client, every project within each client, and every task category you bill against. Put it in a spreadsheet. Review it monthly.
- Map each project to a signal source. Decide which repo, branch pattern, board, or calendar filter represents each project. Document the mapping next to the taxonomy.
- Pick an idle threshold and a rounding rule. Thirty minutes between commits is the common default. Round to the nearest 15-minute increment at the line-item level. Stick with both for a full month.
- Wire approved hours straight into your invoicing tool. Re-keying hours from one system to another is where disputes start. An export with commit SHAs or PR numbers next to each line item rarely gets challenged. For the full flow, see our guide on generating invoices from tracked hours.
The teams that recover the most unbilled revenue are not the ones with the strictest timer discipline. They are the ones who stopped asking humans to be the allocation engine and started letting signals do it.
Key Takeaway
Track billable hours across multiple projects by mapping each repo, branch, and calendar invite to a client automatically — review the draft weekly, fix the edges, and approve.
Frequently Asked Questions
How do I handle time spent on tasks that span multiple projects?
Split the time proportionally based on the signal source. For shared-code work, split by commit or file count across client paths. For meetings, attribute to the primary project discussed and note the split in the session record. Activity-based trackers usually support a session split at approval time.
What billing increment should I use for multi-project tracking?
Fifteen-minute increments are the industry standard for professional services and balance accuracy with tidiness. Some high-value consulting firms use six-minute increments. Choose the increment specified in your client contract and apply it at the line-item level, not at the session level, to avoid compounding rounding errors.
Can I track billable hours across projects if my team uses different tools per client?
Yes. Activity-based trackers that connect to multiple git providers, issue trackers, and calendars unify time data regardless of the tools each project uses. The integration layer reads events from each source and stitches them into a single timeline per developer, tagged by project.
How do I separate billable and non-billable hours across multiple clients?
Tag every activity with a project and every project with a billing flag. Internal tooling, unassigned meetings, and company admin carry a non-billable flag and appear in reports but never on an invoice. The same tracker that captures billable time should capture non-billable time — both are needed for utilisation analysis and rate-setting.
What is the best way to allocate meeting time across multiple clients?
Use calendar integration with a naming rule. Meetings whose invite title or description contains a project identifier attribute automatically. Meetings without a project tag land in a weekly review bucket. Most teams settle into the habit of tagging calendar invites within two weeks once the tracker surfaces untagged meetings for approval.
How do I track time across multiple git repos for different clients?
Run extraction across every repo each developer contributes to, tag each row with the repo name, and merge into one chronological timeline per author. A commit in Repo A five minutes after one in Repo B counts as a repo switch, not a new session. Activity-based trackers handle this stitching automatically.
What if a client disputes hours spread across multiple projects?
Export a line-itemised view that shows the commits, PR numbers, or calendar events behind every hour. Clients who see “14.5 hours — commits abc123 through def456 on the checkout refactor” rarely dispute. Clients who see “development — 40 hours” often do. A per-project audit trail is the single strongest defence against invoice disputes.
Ready to track every billable hour across every project?
Connect your repos, issue tracker, and calendar to Keito. Activity from every project attributes to the right client automatically — review on Friday, approve in a click, export straight to your invoicing tool.