Budget consumption measures how much of a defined cost budget has been used. Percent complete estimates how much agreed work has been completed. They require different inputs and should not be substituted for one another. A gap is a review signal, not proof of an overrun, because timing, work mix, procurement, rework, or progress-measurement rules may explain it.
What does each measure answer?
Budget consumption answers a financial question: how much supported cost has been recorded relative to a chosen budget? Percent complete answers a delivery question: how much of the defined work is complete? The denominator and evidence must be named for both figures.
Budget consumption = actual costs recorded to date / defined cost budget x 100
Percent complete = completed work / total defined work x 100
The second expression is conceptual unless the project has a governed method for valuing completed work. Counting completed tasks equally may misstate progress when tasks differ greatly in size. A milestone-weighted, quantity-based, or formal earned-value method can be more defensible if the rules and evidence fit the work.
How formal earned value differs
In EVM, the Department of Energy defines earned value as completed work expressed in budgeted-cost terms and actual cost as the amount spent for work performed. Formal percent complete is therefore tied to earned value and budget at completion, not merely a project manager's subjective estimate. A services dashboard that shows a manually entered completion percentage is providing useful context, but it is not automatically an EVM system.
Managed Margin's supported budget-consumption figure divides actual labour plus supported actual partner and infrastructure costs by the deliverable budget. An authorised user supplies actual hours and completion context manually. The application does not calculate earned value.
Worked example: 68% consumed and 55% complete
A project has a USD 90,000 deliverable budget for the supported consumption measure. By the review cut-off, it has USD 61,200 of applicable recorded cost. The delivery owner reports 55% complete under the team's stated milestone method.
| Input or result | Value | What it means |
|---|---|---|
| Defined deliverable budget | USD 90,000 | The denominator for this consumption measure. |
| Supported actual cost to date | USD 61,200 | Labour and included actual cost through the cut-off. |
| Budget consumption | 68% | USD 61,200 / USD 90,000. |
| Reported completion | 55% | Progress under the stated milestone method. |
| Simple gap | 13 percentage points | A signal to investigate, not a forecast. |
The project has consumed budget faster than its reported progress. Possible explanations include intentionally senior-heavy discovery, an early software purchase, rework, delayed client decisions, additional scope, or an optimistic completion assessment. The gap does not tell reviewers which explanation is true, and it does not calculate the final cost.
What should reviewers ask when the figures diverge?
| Check | Question | Evidence |
|---|---|---|
| Cut-off | Do cost and progress cover the same date? | Timesheet close, invoice accrual policy, progress-status date. |
| Denominator | Which costs does the budget include? | Approved baseline and documented exclusions. |
| Progress method | How was completion determined? | Milestones, accepted quantities, or documented weights. |
| Timing | Did an early cost purchase support later work? | Purchase order, service period, and delivery schedule. |
| Delivery | Was effort spent on rework or blocked work? | Issue log, change record, and resource-level hours. |
| Scope | Has approved work or price changed? | Signed change and labelled baseline version. |
DOE guidance for formal project analysis emphasises current, accurate, complete, repeatable, and auditable data, and describes triggered metrics as reasons to investigate rather than automatic evidence of failure. The same discipline improves a lighter services review even when the organisation is not using EVM.
What if completion is ahead of consumption?
The opposite gap also needs investigation. Using the same USD 90,000 deliverable budget as the worked example above, suppose the project instead has USD 43,200 of recorded cost by the review cut-off, and the delivery owner reports 65% complete.
| Input or result | Value | What it means |
|---|---|---|
| Defined deliverable budget | USD 90,000 | Same denominator as the worked example above. |
| Supported actual cost to date | USD 43,200 | Labour and included actual cost through this cut-off. |
| Budget consumption | 48% | USD 43,200 / USD 90,000. |
| Reported completion | 65% | Progress under the same stated milestone method. |
| Simple gap | 17 percentage points | Still a signal to investigate, not proof of an underrun. |
The team may have delivered efficiently, but cost entries may also be late, an invoice may be missing, early milestones may be overweighted, or lower-cost work may happen first. Do not declare an underrun until the cut-off, accrual treatment, progress method, and remaining work have been checked.
How does this play out on a multi-site infrastructure rollout?
Consider a professional-services firm deploying network switches, access points, and workstations across 40 branch sites for a client, priced against a defined cost budget and tracked site by site. The two measures above diverge in specific, predictable ways at different stages of a rollout like this.
- At kickoff, sites vary enormously in size — a 5-user branch and a 200-user regional hub both count as "one site." Counting completed sites equally overstates progress once the small sites are done first. Handling: use the milestone-weighted or quantity-based progress method described above, weighted by site size or connected-device count, not a simple site count.
- Mid-rollout, the team buys hardware for the remaining sites in one bulk order to secure a vendor discount, so consumed budget jumps to 70% while only 40% of sites are actually deployed. Handling: this is the "Timing" check from the review-questions table above — confirm the early purchase supports later work before treating the gap as an overrun, and track it the way a margin variance review would.
- At a scope change, the client adds 10 more branch sites partway through. If the cost budget is revised but the site count used for percent complete is not, every subsequent report looks like a growing overrun that scope caused, not spend. Handling: apply the "Scope" check above — update both denominators from the same signed change record, at the same time.
- At monthly review, field technicians report some sites "90% done" before formal acceptance testing has run. Handling: the "Progress method" check calls for accepted quantities as evidence, not a technician's verbal estimate — do not let self-reported completion outrun what has actually passed sign-off.
- At project close, the last few sites are cost-complete but stuck waiting on client-side scheduling for final acceptance, so spend hits 100% while reported completion lags for weeks. Handling: the "Delivery" check applies here too — document the block explicitly rather than forcing a site to 100% complete to close the file early.
In every case, the gap between the two measures is the same kind of signal described above: a reason to ask a specific question, not a verdict on the rollout.
Limitations and safe interpretation
- A percentage is only as reliable as its cut-off, cost coverage, and progress method.
- Actual cost can lag work when invoices or cost entries arrive later.
- Progress can lag spending when costs are incurred before related work is completed.
- A manually supplied completion estimate is not earned value unless a formal EV method supports it.
- Neither measure estimates remaining effort or final project margin.
Use the comparison to create a better question, then test that question against source records and the remaining plan. For the broader method, read planned versus actual project margin. To turn the finding into a repeatable operating process, see the project margin review cadence guide.
Sources and methodology
- U.S. Department of Energy, Earned Value Management. Used for the definitions of planned value, earned value, actual cost, baseline, and the warning against reading cost without progress.
- U.S. Department of Energy, Earned Value Management System and Project Analysis Standard Operating Procedure. Used for data-quality and investigation principles in a formal EVM context.
- Managed Margin's consumption formula and manual actuals workflow were verified against the current implementation on 24 August 2026. The worked example is original and illustrative.