To separate billable and non-billable hours, apply a three-test framework: would this work not exist without the client, does it directly produce a deliverable, and would the client agree it was spent on their behalf?
Every software team and freelancer knows they should track billable and non-billable hours separately. But the line between them is blurrier than it appears, especially in software development. A standup meeting with a client is obviously billable. A standup with your internal team is obviously not. But what about setting up a CI/CD pipeline for a client project? Or spending two hours learning a new framework their codebase requires? These grey areas cause billing disputes, undercharging, and profitability problems that compound quietly over months.
A clear classification framework — agreed upon upfront and applied consistently — prevents these problems. Here is how to build one.
What Are Billable vs. Non-Billable Hours?
Billable hours are time spent directly on client-deliverable work that you can legitimately charge for. The client receives value; you receive payment.
Non-billable hours are time spent on activities that support your business but are not directly chargeable. They are necessary, but they come out of your margin.
Why the distinction matters beyond invoicing:
- Profitability analysis. Knowing your true billable ratio reveals how much of your working time actually generates revenue.
- Pricing accuracy. If your estimates ignore non-billable overhead, you underprice every engagement.
- Utilisation metrics. For teams, billable ratio is one of the clearest indicators of capacity and efficiency.
The hidden danger is misclassification. Non-billable time that should be billable means you leave money on the table. Billable time marked as non-billable inflates your costs. Both distort your financial picture. Before tackling separation, make sure you understand what billable hours are — the definition shapes everything downstream.
Common Billable and Non-Billable Categories for Software Teams
Most activities fall clearly on one side of the line.
Clearly billable:
- Feature development and implementation
- Bug fixes on client code
- Code review of client repositories
- Client-facing meetings and calls
- Deployment, QA testing, and release management
- Architecture decisions and technical design for the client
Clearly non-billable:
- Internal team meetings (standups, retrospectives without client involvement)
- Sales calls and proposals
- Administrative work — timesheets, invoicing, project setup
- Professional development and training (unless client-required — see grey areas)
- Company-wide events and off-sites
The grey areas that cause disputes:
| Activity | Common Classification | Reasoning |
|---|---|---|
| Daily standup (client project team) | Billable | Direct coordination on client deliverables |
| Internal retrospective | Non-billable | Process improvement — no direct client output |
| Slack/email with client | Billable | Client communication is client work |
| Environment setup | Billable (first time) | Required to deliver; client benefits directly |
| Learning new framework for client project | Billable (bounded) | Client-required skill; cap at a agreed hours |
| CI/CD pipeline configuration | Billable | Infrastructure for delivering client code |
| Writing technical documentation | Billable | Deliverable the client receives and uses |
| Fixing your own introduced bug | Debated | Many firms absorb this; agree upfront |
| Scope creep rework | Non-billable until contract updated | Must be flagged and re-scoped before billing |
The key principle: define your grey-area policy upfront and put it in your statement of work or contract. Disputes almost always arise from ambiguity, not dishonesty.
A Practical Framework for Classifying Hours
Three tests help you categorise borderline activities consistently.
Test 1 — The Client Benefit test. Would this activity not exist if this client did not exist? Setting up a development environment specifically for their codebase: yes. Maintaining your general development machine: no.
Test 2 — The Deliverable Connection test. Does this activity directly produce something the client will receive or use? Writing a feature, drafting documentation, or deploying code: yes. Attending an internal finance review: no.
Test 3 — The Transparency test. Would the client agree this time was spent on their behalf? Most clients accept environment setup, framework learning (within reason), and team standups. Few would accept your tax filing or new business pitch preparation.
Decision rule: If any two of the three tests pass, classify the activity as billable.
Document this framework and share it with your team and your clients. When everyone uses the same tests, classification becomes fast and disputes become rare.
Build a Shared Classification Reference
Create a reference document your team can consult for recurring activities. Include:
- A table of 20-30 common activities with their standard classification
- The grey-area policy (e.g. “framework learning for client projects is billable up to 4 hours per sprint, with prior notice”)
- The escalation path for activities not covered
Review the reference quarterly. Client relationships and project types change.
How to Implement Billable/Non-Billable Tracking
Getting the framework right is half the work. The other half is making it stick in day-to-day practice.
Step 1: Define your categories and get team agreement. A classification system imposed without explanation will be applied inconsistently. Walk through the framework with your team. Work through five or six real examples together until everyone reaches the same answers.
Step 2: Set up project codes. Every project should have at least two codes: one for billable time, one for non-billable overhead related to that project. Some teams add a third for internal activities. Whatever structure you choose, keep it simple — complexity leads to guessing.
Step 3: Use automated time capture. Manual classification is where the framework breaks down. When a developer has to remember what they were doing three hours ago and assign it to a code, accuracy drops and non-billable work gets absorbed into billable buckets (or disappears entirely). Automated capture tied to git activity, PRs, and calendar events removes the memory problem.
Step 4: Tag git activity as billable by default. Work in a client repository is billable. Work in your internal repositories is not. Automated tools can use this repository-level signal to pre-classify time, leaving only genuine edge cases for manual review.
Step 5: Review and reclassify weekly, not monthly. The longer you wait, the less accurate your recollection. A weekly fifteen-minute review catches misclassifications while context is still fresh. Monthly reviews often result in best-guess timesheets.
Step 6: Track your billable ratio over time. Calculate billable hours as a percentage of total tracked hours. Set a target — 65-80% is typical for software development teams — and monitor the trend. If your ratio drops, investigate why before the end of the month. A guide to how to track billable hours covers the tooling choices in detail.
What Your Non-Billable Time Reveals About Your Business
Non-billable time is not wasted time. But the breakdown tells you a great deal about how your business operates. For a deeper look at the cost of untracked non-billable time, see non-billable hours: what they are and how to minimise them.
High internal meeting time signals communication overhead. If your team spends more than 20% of non-billable hours in internal meetings, examine whether all those meetings are necessary or whether they could be replaced by written updates.
High admin time suggests process gaps. If invoicing, timesheet entry, and project setup together consume more than 15% of non-billable hours, there is tooling or automation work worth doing.
High sales and business development time with low conversion means your pipeline is inefficient. The time is not the problem; the conversion rate is.
High learning and training time is a double-edged signal. It either reflects investment in growth (healthy) or poor project scoping (unhealthy). If training time spikes on a particular client project, review whether the original scope accounted for the technical requirements.
Industry benchmarks for billable ratios:
| Team Type | Healthy Billable Ratio |
|---|---|
| Freelance developers | 70-80% |
| Small digital agencies | 65-75% |
| Software consultancies | 65-80% |
| Managed service providers | 75-85% |
Ratios below 60% consistently signal structural problems — too much overhead, too little client work, or poor time classification. Ratios above 90% consistently signal burnout risk and underinvestment in business development.
Key Takeaway
Use the Client Benefit / Deliverable Connection / Transparency framework to classify grey-area hours. Agree on billable definitions upfront, track everything, and review your billable ratio weekly.
Frequently Asked Questions
What percentage of hours should be billable for a software developer?
Software developers in agency or consultancy settings typically target 65-80% billable hours. The remaining 20-35% covers internal meetings, professional development, and administrative work. Freelancers working directly with clients often achieve 70-80% since they have less internal overhead.
Are standup meetings billable or non-billable?
Daily standups are billable when they involve the client’s project team and coordinate directly on client deliverables. Internal standups — where the team discusses work across multiple clients or internal projects — are non-billable. When in doubt, ask: is the client a participant or beneficiary of this meeting?
Should code review time be billed to the client?
Yes, code review on client repositories is billable. It is a direct quality control activity that produces a client deliverable (reviewed, merge-ready code). Code review on your internal codebase or open-source contributions is non-billable.
How do I bill for time spent learning new technology for a client project?
Learning time is billable when the client’s project specifically requires it and the skill has no application beyond that engagement. Cap it at an agreed number of hours (typically 4-8 hours per new technology), notify the client in advance, and document it in your timesheet. Ongoing professional development unrelated to the current project is non-billable.
What is the difference between non-billable and overhead hours?
Non-billable hours are all hours that are not charged to a client, including both project-related non-billable work (internal reviews, non-chargeable fixes) and general overhead. Overhead is a subset of non-billable time — it refers specifically to business operation costs: admin, finance, sales, and facilities. Some firms track them separately to distinguish client-project non-billable from pure business overhead.
Track Billable and Non-Billable Hours Automatically
Keito auto-classifies developer time as billable or non-billable based on git activity. Work in a client repository is flagged as billable. Internal repositories stay non-billable. Stop guessing — start your free trial at keito.ai.