What is Budget at Completion (BAC)?

Budget at Completion (BAC) is the total approved budget for a project — the single number that anchors every other Earned Value Management (EVM) calculation. This guide explains what BAC is, how it is built, how it relates to EAC, and the mistakes that most often distort it in practice.

Last reviewed: 3 May 2026 · Source: Project Management Institute, The Standard for Earned Value Management

The short definition

BAC is the sum of all budgets allocated to the work to be performed on a project. It is established as part of the cost baseline at the beginning of the project and is the "100 percent point" of the planned spend curve. When a project finishes exactly on budget, the actual cost equals the BAC; when it overruns, actual cost exceeds BAC; when it underruns, actual cost falls below BAC.

In a simple project, BAC may be a single line item: BAC = total approved budget. In larger programs it is the rolled-up sum of every work package budget across the work breakdown structure (WBS). Either way, BAC is a fixed scalar — it does not change as the project progresses unless a formal change to the cost baseline is approved.

Why BAC matters

BAC is the foundation for every forecasting metric in EVM. Without an agreed BAC there is nothing to compare actual or earned values against. Specifically, BAC feeds three of the most-used EVM formulas:

• EAC (Estimate at Completion) is most often computed as BAC / CPI.
• VAC (Variance at Completion) is BAC − EAC — the projected surplus or shortfall against budget.
• TCPI (To-Complete Performance Index) is (BAC − EV) / (BAC − AC) — the cost efficiency required on remaining work to finish within BAC.

If BAC is wrong, every forecast above is wrong. That is why setting BAC carefully is one of the highest-leverage activities a project manager performs during initiation and planning.

How BAC is set

Setting BAC is a four-step process:

1. Decompose the scope. Break the project down to a level of detail (work packages) where each piece of work can be estimated with reasonable accuracy.
2. Estimate each work package. Use analogous, parametric, three-point, or bottom-up estimating to assign a budget to every work package. The PMBOK Guide recommends bottom-up estimating for the highest accuracy.
3. Aggregate to control accounts and to the project. Sum work package budgets up the WBS. The total at the top of the WBS is the budget without contingency or management reserve.
4. Add contingency reserves. Contingency reserves cover known risks ("known unknowns") and are part of the cost baseline. Once they are added, the total becomes BAC. Management reserves for unknown risks are held outside the baseline and are not part of BAC.

BAC versus EAC: a frequent source of confusion

BAC and EAC look similar — both are "total project cost" numbers — but they answer two different questions:

BAC is fixed; EAC is dynamic. BAC was set when the cost baseline was approved. EAC is recomputed every reporting period using the latest performance data. The variance between them — VAC — is the signal that tells stakeholders whether the project is heading for an overrun or an underrun.

Worked example

Imagine a one-year construction project with the following baseline:

• Work package budgets total: $920,000
• Contingency reserves for identified risks: $80,000
• BAC = $920,000 + $80,000 = $1,000,000
• Management reserves (outside BAC): $50,000
• Total project budget reported to the customer: $1,050,000

Six months in, performance data shows EV = $400,000 and AC = $440,000. CPI = 0.909. The forecast becomes:

• EAC = BAC / CPI = 1,000,000 / 0.909 = $1,100,000
• VAC = BAC − EAC = 1,000,000 − 1,100,000 = −$100,000

The project is on track to overrun by approximately $100,000. The team can decide whether to absorb the overrun by tapping the $50,000 management reserve, formally re-baseline (which would change BAC), or take corrective action to bring CPI back above 1.0.

Common pitfalls when setting BAC

1. Padding individual estimates

Estimators sometimes add hidden buffers to their work package estimates to protect themselves. The cumulative effect is a BAC that is artificially high — the project appears to come in "under budget" but actually consumed buffers that should have been visible. Use explicit contingency reserves at the project level instead.

2. Confusing BAC with the contract value

The contract value (what the customer is paying) and BAC (what the project intends to spend) are different numbers. Contract value typically includes profit margin and management reserve; BAC is the baseline cost only.

3. Forgetting non-labor costs

Software projects often build BAC from labor hours alone and forget licenses, cloud spend, contractor fees, and tooling. Construction projects forget permitting, inspections, or insurance. A complete BAC includes every dollar that will be spent on the project.

4. Re-baselining too quickly

It is tempting to change BAC the first time a project goes over budget. Doing so destroys the historical performance signal and prevents EVM from doing its job. Re-baseline only when scope formally changes, not when performance is poor.

5. Mixing constant and current dollars on long programs

On multi-year programs, inflation and exchange-rate movement matter. Pick one currency basis (constant-year or current-year) and stick to it across BAC, EV, and AC. Mixing the two corrupts every variance and index.

BAC and the cost baseline

BAC is the top of the cost baseline — the time-phased budget plotted as the planned value (PV) curve. As the project progresses, the cumulative PV grows from zero at project start to BAC at project finish. EV is then plotted on the same axes to show how much value has actually been earned at each point in time, and AC shows how much has actually been spent. The three curves together — PV, EV, AC — are the canonical EVM chart, and BAC is the value all three converge toward at completion in a perfectly executed project.

Practical tips for project managers

• Document assumptions. Every estimate that feeds BAC rests on assumptions. Capture them in a basis-of-estimate document so that future variances can be traced back to a specific assumption.
• Lock BAC at baseline approval. After the cost baseline is approved, treat BAC as a constant. Track changes through the integrated change control process.
• Report BAC alongside EAC every period. Stakeholders need both numbers to understand whether the project is forecasting an overrun or an underrun.
• Use BAC in the right denominator. TCPI and the typical EAC formula both depend on BAC; getting the denominator wrong is a top cause of misleading forecasts.
• Reconcile BAC against the WBS. Periodically re-roll work-package budgets up the WBS to make sure the recorded BAC still equals the sum of its parts.

BAC on the PMP exam

The PMP exam tests BAC in two main ways. First, you may be asked to calculate forecasts (EAC, VAC, TCPI) using a given BAC. Second, you may face conceptual questions that distinguish BAC from EAC, contract value, or management reserves. Memorize the definition — "the total budget allocated to the project" — and remember that BAC is fixed once baselined, while EAC is a recomputed forecast.

Summary

Budget at Completion is the anchor of Earned Value Management. It is a single, baselined number representing the total approved cost of a project, built from the bottom up across the WBS plus contingency reserves. Once approved, BAC is fixed; every periodic forecast (EAC, VAC, TCPI) compares current performance against that fixed reference. A clean BAC, set with explicit assumptions and free of hidden padding, is what makes EVM forecasts trustworthy. Get BAC right and the rest of EVM follows; get BAC wrong and every downstream metric inherits the error.

Frequently asked questions

Disclaimer: Educational reference only. Verify against your organization's project controls policies and the latest PMI / PMBOK guidance.