Approved hours vs logged hours: the number your margin depends on
Logged time is a claim. Approved time is a decision. Treating them as the same number is why so many services firms are surprised by their own utilisation figures.
Logged hours are what a developer reports; approved hours are what a manager has confirmed was productive work. Most services firms track only the first and report it as if it were the second. Separating them gives you an honest utilisation figure, a defensible productivity measure, and an early warning signal in the gap between the two.
Ask a services firm what its utilisation is and you will usually get a number derived from timesheets. Ask how that number is verified and the answer is often that the timesheet was submitted, and the manager did not object. Those are different things, and the distance between them is where margin quietly disappears.
This is not about distrust. Developers log hours honestly and still produce a figure that overstates productive work, because a timesheet has no field for the two hours lost to a broken environment, the rework caused by an unclear requirement, or the meeting that should have been an email. All of it lands under the ticket it interrupted.
The three numbers, and what each one is
Every task in a services business carries three hour figures, and they answer different questions. Conflating any two of them produces a report that looks precise and is not.
A worked example
Take a single sprint for one developer. The estimate was 40 hours across four tickets, and the timesheet came back at 44. On the face of it, a small overrun and nothing to discuss.
| Ticket | Est. | Logged | Approved | Why the difference |
|---|---|---|---|---|
| Claims submission API | 18 | 17 | 17 | Clean delivery, approved as logged |
| Claims validation rules | 10 | 13 | 10 | 3h rework after a requirement change |
| Document upload service | 8 | 9 | 6 | 3h lost to a broken staging environment |
| Upload edge-case tests | 4 | 5 | 3 | 2h waiting on a blocked dependency |
| Total | 40 | 44 | 36 | 8h of logged time was not productive delivery |
Reported on logged hours, this developer looks 10 per cent over estimate. Reported on approved hours, they delivered the sprint in 36 productive hours against a 40-hour estimate — and the business absorbed 8 hours of environment problems and rework that nobody had visibility of. Those are two entirely different conversations, and only one of them leads to a fix.
What the gap tells you
Once you record both figures, the difference becomes the most useful number on the page. It is not a measure of the developer. It is a measure of the conditions they are working in, and it tends to cluster in revealing ways.
Approve as-is, or moderate
The objection to all of this is that it sounds like extra work for managers who have none to spare. In practice it is not, provided the default is right. Most tickets should be approvable in one click at the figure the system suggests, with moderation reserved for the ones where something actually happened.
The important design detail is that a moderated approval must be visibly marked as moderated, and attributed. A silent adjustment is worse than no adjustment, because it destroys the developer's ability to understand their own numbers — which is the thing that makes the whole system tolerable to them.
If a manager reduces someone's hours, the developer should be able to see that it happened, who did it, and by how much. Anything less and you have built a black box with a person's performance inside it.
Why this has to sit next to delivery
Approval is only cheap if the approver is already looking at the work. A manager reviewing a sprint they planned, in the same screen as the tickets and their estimates, can approve a fortnight of hours in a few minutes. The same manager asked to open a separate timesheet product and reconcile it against a project tool will do it late, badly, or not at all.
This is the practical case for keeping delivery, hours and measurement on one data model rather than three integrated products. Not elegance — approval rates. A process that depends on someone switching systems is a process that degrades.
Where to start
You do not need new software to test the idea. Take last month's timesheets for one team, sit with the delivery lead, and mark for each ticket what they would actually have approved. The exercise takes an hour and the total will not match what you reported. That difference is your real starting position.
If the gap is under three per cent, your current reporting is close enough and this is not your problem. In most firms we have done this with, it lands between eight and fifteen — which is the difference between a project that made money and one that did not.
In Goalz, approved hours default to zero until a manager signs them off or moderates them, and only approved hours count toward productive time. Bring a sprint of real timesheets and we will run the approval flow on the call.