Budget at Completion (BAC) Explained

What is budget at completion?

Budget at completion is the total approved budget for the project at the point of approval. It represents the sum of the budgets established for all work in scope, including the cost baseline and its contingency reserves, but excluding management reserve. It is also the total planned value (PV) the project expects to earn by its finish date.

The PMBOK definition is deliberately plain: the sum of all budgets established for the work to be performed. The operational meaning is more useful. BAC answers three questions at once:

1. What did we agree this project would cost?
2. What is 100% of earned value worth?
3. What number does every forecast get measured against?

If a project is approved at $1,080,000, then BAC is $1,080,000. A CPI of 0.90 means the project has earned 90 cents of that budget for every dollar spent. An EAC of $1,200,000 means the forecast is $120,000 above it. Without BAC, none of those statements has a reference point.

> Important note: BAC is a budget, not a bank balance. It does not change because an invoice arrived early, because a purchase order was prepaid, or because finance re-phased cash flow. Those events change actual cost, not BAC.

How is BAC built, step by step?

BAC is assembled from the bottom up, then approved as a baseline. The sequence matters, because a shortcut at any step produces a number that will not survive an audit or a change request.

Step 1: Define scope through the WBS

Start with the work breakdown structure. Every work package should be small enough to estimate, assign, and measure. If a work package is described as “phase 2” with no decomposition, its estimate will be a guess dressed as a budget.

Step 2: Estimate each work package

Use a consistent method: analogous estimating for early stages, parametric for repeatable work, three-point for uncertain work, and bottom-up for the packages that carry the most cost. Record the basis of estimate for each, because “why is this $240,000?” is the question you will be asked in month five.

Step 3: Add contingency reserve

Contingency covers known risks — the identified risks in the register, with a probability and impact. Calculate it rather than guessing: expected monetary value analysis, or a percentage applied to the uncertain packages. Contingency belongs inside the cost baseline, and therefore inside BAC.

Step 4: Time-phase the baseline

Spread the approved costs across the schedule to produce the cost baseline curve. This is what makes planned value possible. A BAC with no time phasing is a total, not a baseline, and it cannot tell you whether you are ahead or behind at any given date.

Step 5: Approve and freeze

The sponsor or governance body approves the baseline. From that moment, BAC changes only through change control. The approval date and version number belong in the cost management plan.

Worked example: building a BAC

A five-package implementation project has these estimates and an 8% contingency on the work packages.

The BAC is $1,080,000. The management reserve is a separate approval held by the sponsor for unknown unknowns. It is not part of BAC, and spending it requires a change to the baseline rather than a quiet withdrawal.

What belongs inside BAC and what stays outside?

The distinction between contingency and management reserve is the most common source of disagreement between project managers and finance teams. Get it wrong and the project appears to have more money than it does.

Two rules keep this clean. First, write the inclusion rules into the cost management plan before the first status report. Second, never describe BAC as “the total money available.” It is the total budget for approved scope, and the reserve structure around it determines what is actually available.

How does BAC differ from the cost baseline?

The cost baseline is the time-phased, approved budget for the project, usually drawn as an S-curve. BAC is the total value of that curve at completion. In most projects they are numerically identical, which is why the terms are often used interchangeably — but they are not the same concept.

The baseline includes the shape: how much should be spent in month one, month six, month twelve. BAC is the endpoint. You need the baseline to calculate planned value and therefore SPI; you need BAC to calculate cost ratios and forecasts. The practical distinction is that BAC without a curve cannot produce PV.

How do BAC, EAC, ETC, and VAC relate?

These four numbers describe the same project at different points in time. BAC is the plan, EAC is the forecast, ETC is the remaining work, and VAC is the gap between plan and forecast.

The relationships are simple but easy to misstate. EAC includes money already spent; ETC does not. VAC is negative when the forecast exceeds the budget, which is the opposite sign convention from cost variance. TCPI above 1.00 means the remaining work must be more efficient than plan to hit BAC.

Worked example: forecasting from BAC

The project has spent $450,000 and earned $405,000 of value. BAC is $1,080,000.

• CPI = EV ÷ AC = 405,000 ÷ 450,000 = 0.90
• EAC = BAC ÷ CPI = 1,080,000 ÷ 0.90 = $1,200,000
• ETC = EAC − AC = 1,200,000 − 450,000 = $750,000
• VAC = BAC − EAC = 1,080,000 − 1,200,000 = −$120,000
• TCPI = (1,080,000 − 405,000) ÷ (1,080,000 − 450,000) = 675,000 ÷ 630,000 = 1.07

The last number is the useful one for a steering meeting. The team must deliver the remaining $675,000 of value for $630,000 of actual cost — 7% better efficiency than the original plan — to finish within BAC. If that is not plausible, the conversation should be about scope or budget, not about working harder.

What happens to BAC after an approved change?

Approved scope changes revise BAC. Unapproved ones do not. That sentence is the entire governance rule, and most project reporting failures come from breaking it in one direction or the other.

Suppose the sponsor approves an additional $90,000 of scope in month four. The revised BAC becomes $1,170,000. If the project’s cost efficiency stays at 0.90, the new forecast is 1,170,000 ÷ 0.90 = $1,300,000, with a VAC of −$130,000. The overrun grew by $10,000 even though the change was fully funded, because the new work will also be delivered at 90 cents on the dollar.

That is the part change requests often miss. Adding budget at the same efficiency does not remove the existing overrun; it adds to it. The correct conversation is: approve the scope change, revise BAC, recompute EAC, and then decide whether the contingency or management reserve covers the resulting gap.

Worked example: releasing management reserve

The project has a $50,000 management reserve. The forecast overrun is $120,000. Releasing the full reserve reduces the uncovered gap to $70,000, but it does not fix the project. It converts an unapproved overrun into an approved budget increase and leaves $70,000 to be resolved through scope reduction, a sponsor decision, or accepting a reported variance.

The discipline is to record the release as a baseline change with a date and an approver, not as an adjustment in a spreadsheet. Otherwise next month’s BAC will be different from this month’s, and nobody will be able to explain why.

Which forecast formula should you use?

The simple CPI-based EAC is the default, but it assumes current efficiency persists. Three alternatives matter when that assumption is wrong.

For the example above, the composite forecast would be 450,000 + 675,000 ÷ (0.90 × SPI). If SPI is 0.85, the result is 450,000 + 675,000 ÷ 0.765 = $1,332,353. That is $252,353 above BAC and materially worse than the simple CPI forecast. Projects that are both late and over budget usually land closer to the composite number, which is why it is worth calculating before the sponsor asks.

Why is BAC sometimes misleading?

BAC is a strong reference point with a few sharp edges. Knowing them prevents the number from becoming a comfort blanket.

BAC excludes management reserve. A project can be “within BAC” and still need a sponsor bailout, because the unknown-unknown reserve sits outside the baseline. Report both numbers.

BAC is not cash flow. A project can be 40% through its BAC and 60% through its calendar while cash spend is only 25%, because invoices lag. Confusing budget consumption with cash movement produces false alarms and false comfort.

A stale BAC corrupts every metric. If approved changes are not reflected, CPI compares new work to an old budget. If unapproved overspend is absorbed into BAC, CPI is flattered and the variance disappears.

BAC is a total, not a distribution. Two projects with the same BAC can have different risk profiles. Look at the shape of the baseline and the concentration of cost in the largest three work packages.

When should you rebaseline BAC?

Rebaseline when three conditions are all true: the change is approved, the change is material enough to affect the cost baseline, and the original baseline can no longer support useful measurement. Rebaselining for any other reason is reporting management, not project management.

A practical threshold helps. Many organisations rebaseline when approved changes exceed 5% to 10% of BAC, or when a stage gate resets the plan. Below the threshold, track changes as variances against the original baseline, because the comparison itself carries information.

Above the threshold, rebaseline deliberately: issue a new baseline version, record the reason, restate the forecast, and tell every stakeholder which version is current.

Does BAC work in agile projects?

It works if you define it at the right level. In agile, BAC is usually the approved budget for a release, a fixed-price engagement, or a funding increment — not for an entire product roadmap that is expected to change.

Three adaptations make it usable:

• Set BAC per funding cycle. A six-month increment with a fixed budget and a flexible backlog is a legitimate baseline.
• Earn value on accepted increments. Count work as earned when it meets the definition of done and is accepted.
• Keep contingency visible. Agile scope flexibility is not a licence to hide reserve; put a discovery and rework allowance in the budget and label it.

If the organisation cannot commit to a budget for any increment, skip BAC and manage burn rate against a rolling forecast.

Where does BAC live in practice?

BAC fails operationally more often than conceptually. The number is approved in a business case, then copied into a finance system, a spreadsheet, and a slide deck, and within a quarter the three versions disagree.

Keeping the approved budget, the time-phased baseline, actual costs, and progress in one workspace removes most of that drift. Doitify is our project and team management platform: it holds project budgets, milestones, tasks, risks, and progress reports together, so the BAC you approved is the BAC the team reports against. It does not replace a project controls function on a capital programme; for a team that needs one reliable budget reference, having the inputs in one system is the difference between a five-minute report and a two-day reconciliation.

Common BAC mistakes to avoid

• Calling the total budget “BAC” without time-phasing it. You get a number that cannot produce planned value.
• Including management reserve in BAC. It inflates the baseline and hides the need for sponsor approval.
• Double-counting contingency. Contingency inside the work package estimate and again as a reserve inflates BAC twice.
• Rebaselining to hide an overrun. This destroys the audit trail and the credibility of every future forecast.
• Reporting BAC consumption as progress. Spending 40% of BAC is not 40% complete. That is what earned value is for.

Conclusion

Budget at completion is the anchor of every cost conversation on a project. Build it from the work breakdown, include contingency deliberately, exclude management reserve, time-phase it, and approve it once. Then treat it as a reference that moves only through change control.

The number itself is simple. The discipline around it is not: keeping the baseline honest, reporting variances instead of editing them away, and recalculating the forecast when scope changes. Teams that protect BAC can explain their project in one sentence. Teams that quietly revise it spend the rest of the project explaining why last month’s report was wrong.

If this post on budget at completion was helpful, you might also enjoy Doitify vs Asana and How to Reduce Context Switching at Work (2026 Guide).