Software Studio: Hours, Milestones and Invoices Against a Project Budget

On a fixed-price project there are two numbers called "percent complete", and they are almost never equal: the share of milestone weight accepted, and the share of budget consumed. Invoicing follows the first, margin follows the second, and anyone watching only one of them discovers the gap in the final month.

Three definitions of percent complete, and they only agree at the end

This article is about operational measurement and contractual invoicing triggers. It does not cover revenue recognition or accounting treatment, which are decided elsewhere.

• Effort consumed. Hours logged divided by budgeted hours. Easy to compute, and it assumes the budget was right to begin with.
• Deliverable acceptance. Weight of milestones accepted over total weight. This is the only number connected to invoicing, and it moves in steps rather than continuously.
• Estimator judgement. Hours logged divided by hours logged plus the estimate to complete. The only number carrying new information, and the only one that requires somebody to keep it current.

The difference is not academic. The first rises even when nothing has been finished, the second sits still for weeks and then jumps, and the third is the only one capable of falling when unforeseen work surfaces. A studio already tracking hours and expenses against a single job ID has the foundation for this, as covered in profitability by project under one identifier. This article sits one layer above: what may be invoiced, and against which budget.

The worked project: 55% invoiced, 89% of the budget spent

Project S-2026-0731. Fixed fee 216,000. Budget 480 hours. Internal cost rate 190 per hour, so the cost budget is 91,200.

Two numbers come out of that table and both are true at once: 55% of the weight has been accepted and invoiced, and 426 of 480 hours have been consumed, which is 88.75% of the budget. The gap is not evidence of carelessness, it is the finding: 54 budgeted hours remain to finish the rest of M3 and the whole of M4, which together carry 45% of the weight.

What makes a milestone invoiceable?

Documented acceptance, not a statement from the team that the work is done. Three fields, all mandatory before an invoice exists:

1. A named approver. A person on the client side identified in the agreement, not "the client agreed in the meeting".
2. An acceptance date. The date approval was received, from which payment days are counted.
3. A deliverable reference. A version, an environment link, a build number or a document. Something openable a year later.
4. A list of exceptions. What was accepted with reservations and what stayed open. A reservation that was never recorded returns as a claim at the end of the project.

Alongside these, one common case needs a decision: what happens when the client does not respond. Agreements usually define an acceptance window, and where one exists the system counts it from the delivery date and warns before it lapses. Without such a window a milestone can hang for two months and the cash never arrives. The document chain from quote through to invoice is covered in quote, order and invoice under one identifier.

Forecasting the finish against a fixed fee

Percent complete describes what happened. The estimate to complete describes what will happen, and it is the only one that can be acted on. On the same project, the project manager estimates at the end of that week that M3 needs another 95 hours and M4 needs 70.

This is the moment when something can still be done. On a fixed fee the revenue is locked, so every additional hour comes straight out of margin, and the decision is between reducing scope, staffing differently, absorbing it deliberately, or opening a change-request conversation. That decision is available in week six and unavailable in the final week, and the only difference is whether somebody maintained the estimate.

• The estimate is refreshed on a fixed cadence, weekly in most studios, rather than only when something breaks.
• An estimate that has not moved for three consecutive weeks is a sign it was not updated, not a sign of stability.
• The cost rate is stored with a date range. A rate that gets overwritten makes any quarter-on-quarter comparison impossible.
• Hours are held per role. 111 hours of a senior developer and 111 hours of a tester are not the same amount of money.

Where does a change request go?

Into a new milestone with its own budget, never into an existing one. This is the rule most studios break, and it is exactly the one that destroys the information:

• Expanding M3 from 30% to 38% erases the original variance, and a month later M3 appears to have come in on budget.
• A new milestone M5 with its own hours budget, invoice amount and weight preserves both facts: the original overran, and the change was added.
• Every change request gets an identifier, an amount, an hours figure and a written approval before work starts on it. Work started before approval is logged against internal work, not against the project.
• A rejected change request is recorded too. The history of what you declined to build is worth exactly as much as the history of what you built.

Why does unbilled work matter most on a fixed fee?

Because it is cost already out of the door with no document covering it. On the same project, the 118 hours invested in M3 are 22,420 of cost accrued against a milestone that has not been accepted and therefore not invoiced.

• The figure is measured in cost, not sell price, otherwise it presents profit that has not been earned.
• It is read against cash flow rather than only against margin: a profitable project with three milestones pending can still be a cash problem.
• It is counted by age. Hours accrued against a milestone delivered six weeks ago and still unaccepted are the strongest signal of a stall on the client side.
• Its source is time entry. The reliability of this number depends entirely on hours being logged as work happens, as covered in time clock and monthly review.

What you look at every week

• Actual hours against budget, as a percentage, for every active project.
• Milestone weight accepted beside budget consumed, side by side.
• The estimate to complete, and when it was last updated.
• Milestones delivered and not yet accepted, by age in days.
• Work accrued and not yet invoiced, in cost.
• Hours logged against a closed project.
• Open change requests being worked on without approval.

The last two are quality metrics for the measurement itself. When they grow, every other number loses value, because it is computed from data that no longer reflects what is happening. Pricing the projects in the first place, as distinct from controlling them, is covered in software development pricing in Israel.

Sources

• Microsoft - Record usage on projects in Business Central
• Microsoft - Invoice projects in Business Central