Dev agencies lose 10–15% of billable revenue to time tracking inaccuracies. When developers work across five clients in a single day, hours get misallocated, forgotten, or simply dropped from invoices entirely.
The challenge is structural. A developer starting work on one client’s codebase and switching to a second client’s bug fix by 11am has no natural prompt to log either session. By end of day, both entries get a rough time estimate, one client gets slightly too much, another gets too little, and neither number reflects what actually happened. Multiply this across ten developers for a year and you understand why agencies with strong pipelines still struggle to hit profitability targets.
The most reliable fix is automatic allocation — tracking time based on activity signals rather than memory. This guide explains why multi-client tracking fails, what the revenue cost looks like, and how to set up a system that bills accurately without adding overhead.
Why Is Multi-Client Time Tracking Uniquely Hard for Dev Agencies?
Most time tracking problems exist for every services business. Multi-client tracking adds a layer that makes manual approaches structurally unreliable.
Developers Work Across Clients Within the Same Day
Context-switching between client projects is the norm at any agency with more than a handful of clients. A senior developer might start the morning on a client’s data pipeline, join a second client’s standup at 10am, spend the afternoon on a code review for a third client’s PR, and end the day handling an urgent request from a fourth.
Each switch point is a billing decision. Get it wrong and one client gets overbilled while another is subsidised without knowing it. When this happens across a team of ten developers over 250 working days, small inaccuracies compound into significant revenue distortions.
Manual Entry Fails at the Context-Switch Moment
Traditional time tracking tools require developers to start a timer when they begin a task and stop it when they switch. This works when work is linear. It breaks down in agency environments where the switch happens in the middle of a Slack conversation, a sudden git checkout, or an impromptu call.
Research from time tracking practitioners consistently shows that only around 30% of context switches result in an immediate timer update. The rest get reconstructed at the end of the day, where memory bias systematically underestimates total time and blurs which client the time belonged to.
Different Clients Have Different Billing Arrangements
A fixed-price client doesn’t need granular time reports, but you still need the data to understand profitability. A time-and-materials client needs precise hours. A retainer client needs hours tracked against a cap. Each arrangement creates a different reporting requirement, and a single developer can be working under all three simultaneously.
This variety makes it impossible to set one time tracking standard that satisfies every engagement. The agency ends up with a patchwork of manual entries, spreadsheet exports, and bespoke reports — all of which introduce error.
What Does Inaccurate Client Allocation Actually Cost?
The 10–15% revenue leakage figure cited across agency benchmarks understates the damage for some teams. Understanding where the losses come from makes the fix easier to prioritise.
Unbilled Hours
Hours that developers work but never log are the most direct loss. These tend to be short sessions — a 20-minute bug investigation, a quick config change, a five-minute PR comment thread — that feel too small to log but occur dozens of times per developer per week.
A ten-developer agency where each developer fails to log one hour per day loses £500K per year at a blended rate of £100 per hour. That single metric justifies almost any time tracking improvement.
Revenue from the Wrong Client
Hours logged to the wrong client don’t disappear from your invoices — they get charged to the wrong place. This creates two problems: the overbilled client eventually notices and disputes, while the underbilled client gets subsidised work they haven’t paid for. Both erode profitability and client trust simultaneously.
Profitability Blind Spots
When client time allocation is unreliable, you cannot identify which clients are actually profitable. A client that looks profitable based on invoice totals may be consuming disproportionate developer attention. A client that generates modest revenue may be extremely efficient to serve. Without accurate time data, those signals are invisible, and resource planning happens on instinct rather than evidence.
For a deeper look at the mechanics of billable hours tracking and what the benchmark ratios should look like, that guide covers the foundations in more detail.
How to Structure Time Tracking for Multiple Clients
The agencies that handle multi-client tracking well share one structural principle: they map work to clients at the source, not in a spreadsheet after the fact.
Map Repositories to Clients
For most dev agencies, each client has one or more dedicated repositories. This one-to-one relationship between repo and client is the most reliable allocation signal available. When a developer commits code to a client’s repo, the system knows which client to attribute that time to — no manual entry required.
Setting this up involves connecting your time tracking tool to your version control platform and tagging each repository with the appropriate client identifier. Every git event — commits, PRs, code reviews, branch checkouts — then generates an automatic time attribution.
For agencies using monorepos with code from multiple clients, branch naming conventions carry the allocation signal. A branch named client-a/feature-payment-gateway attributes all activity on that branch to Client A automatically.
Use Project Codes for Non-Code Work
Meetings, calls, and review sessions don’t generate git activity but still consume billable time. These need a lightweight coding system — typically a short client identifier added to calendar events or meeting notes — that allows the same automatic attribution to apply.
Most agency time tracking setups combine git-based attribution for coding work with calendar-based attribution for meeting work. The two streams together capture 90%+ of billable activity without requiring developers to manually track anything.
Separate Billable from Internal Work
Internal projects — R&D, tooling, business development, company admin — consume developer time that should never reach a client invoice. Many agencies track this separately under an internal “client” code, which creates an accurate utilisation picture without distorting client reports.
This separation also matters for understanding true capacity. A developer who spends 20% of their time on internal work has 80% available for clients. Without the separation, that 20% either disappears into estimation error or gets accidentally attributed to clients.
For agencies billing multiple clients simultaneously, our guide to tracking billable hours across multiple projects covers the project-level mechanics in more detail.
How Does Automatic Git-Based Tracking Work for Agencies?
Git activity is the most complete record of what a developer worked on and when. Every commit has a timestamp, an author, and a repository context. Every PR has review activity, comments, and merge events. Code review time — often undertracked because it’s not “writing code” — is captured automatically when reviewers interact with PRs.
The Automatic Attribution Flow
When a developer pushes a commit to a client’s repository, the time tracking layer reads:
- Who did the work (developer identity from git config)
- When they worked (commit timestamps, not submission time)
- What client owns it (repository-to-client mapping)
- What task it relates to (branch name, commit message, linked issue)
These four signals produce a time entry with enough context to include in a client report, verify during a dispute, or aggregate for profitability analysis — without the developer doing anything beyond their normal work.
Handling Edge Cases in Multi-Client Environments
Shared libraries, internal tooling repos, and cross-client work create attribution ambiguity. Robust agency tracking setups handle these through rules:
- Commits to shared-libraries repo → split by a predefined formula or assigned to overhead
- Cross-client work explicitly tagged in branch names → split per tags
- Untagged internal work → attributed to overhead, flagged for weekly review
Developers then do a five-minute review once a week, not a 30-minute reconstruction every evening. They confirm auto-generated entries, adjust the handful that need correction, and close the timesheet.
How Do You Generate Client-Ready Time Reports from This Data?
Accurate time data is only useful if it translates into reports clients can read and accept. Agencies that track well but report poorly still face invoice disputes.
What Clients Actually Want to See
Different clients need different levels of detail. A startup on a T&M engagement wants task-level breakdowns — what the developer worked on, how long each task took, and how that maps to the sprint. An enterprise client on a managed retainer may only need a monthly summary against the agreed hours cap.
Most agencies offer two report formats: a detailed view for clients who want granular data and a summary view for clients who prefer high-level totals. Both should be exportable as PDF and CSV, and both should pull from the same underlying time data.
Integrating with Invoicing Tools
Time reports that need to be manually re-entered into invoicing software create a second source of error. The most reliable flow is a direct export from your time tracking system to your invoicing platform — whether that is a cloud accounting tool, a billing platform, or a bespoke invoicing workflow.
This connection also creates an audit trail. If a client queries an invoice, you can trace every line item back to a specific commit, meeting, or work session. That traceability reduces dispute frequency and resolution time simultaneously.
For a complete walkthrough of the invoice generation process from tracked data, see our guide on generating invoices from tracked hours.
Building Trust Through Transparency
Clients who can see exactly what developers did — linked to commits, PRs, and calendar entries — are significantly less likely to dispute invoices. Verifiable time records shift the relationship dynamic from “trust me” to “here is the evidence.” Agencies that provide this level of transparency consistently report shorter payment cycles and fewer escalations.
Key Takeaway
Dev agencies lose 10–15% of billable revenue to time tracking inaccuracies. Mapping git repositories to clients and automating attribution captures this revenue without adding developer overhead.
Frequently Asked Questions
What is the best time tracking tool for a dev agency with multiple clients?
The most effective agency time tracking setups connect directly to your version control platform — typically GitHub or GitLab — and attribute commits, PRs, and code reviews to clients automatically. This removes the allocation step from developer workflows entirely. Look for tools that support repository-to-client mapping, calendar integration for meeting time, and per-client report exports.
How do I track time when one developer works on multiple client projects per day?
The most reliable approach is automatic attribution based on git activity. When a developer works in a client’s repository, the system assigns that time to the correct client without requiring manual entry. For non-code work like meetings, calendar event tagging provides the same automatic attribution. Developers review and confirm their weekly timesheets in around five minutes rather than rebuilding them from scratch.
How do agencies handle time tracking for shared or internal projects?
Shared libraries and internal tooling repos are typically assigned to an overhead category rather than billed to any client. Some agencies create explicit rules for shared code — splitting the time proportionally across current clients or assigning it to an internal project code. The key is defining the rule upfront and applying it consistently, so the data is comparable across reporting periods.
What utilisation rate should a dev agency target?
Agency benchmarks typically target 70–80% billable utilisation for developers. Below 70% and the agency is likely carrying too much non-billable overhead. Above 80% and developers have limited capacity for internal work, professional development, and overhead tasks, which creates burnout risk and quality problems. These targets vary by agency type, seniority mix, and service model, but most profitable agencies land between these numbers.
How do I bill different rates for different clients?
Rate variation by client is handled at the reporting layer, not the time tracking layer. Set up a rate card per client in your invoicing or billing tool, and configure exports from your time tracking system to map developer IDs to the correct rates per client engagement. For agencies with senior/junior rate differences, the developer identity on each time entry carries the seniority signal, which maps to the appropriate rate automatically during invoice generation.