Learn Budget at Completion (BAC), how to calculate it, formula, examples, and why it matters for cost control, billing accuracy, and project profitability.
06 May 2026
Inzo
Budget at completion (BAC) is the total approved budget for a project — every dollar authorized to complete the full scope of work, nothing more.
You set BAC before work begins, typically during the proposal or contracting phase. It becomes the fixed baseline against which all spending is measured. As Monograph notes, for services firms this means BAC is established at the point you sign the contract, not adjusted as work progresses.
Inside earned value management, BAC is the anchor number. Every EVM metric — Schedule Variance, Cost Performance Index, Estimate at Completion — references it. Without a clearly defined BAC, those calculations produce numbers with no meaningful baseline to compare against.
BAC in project management is also distinct from your working budget or internal cost estimate. It represents what the client or sponsor approved, not what you privately expect to spend. That distinction matters when you need to track actual project costs against your approved budget and explain variances to a client.
One practical note: BAC only holds if defining project scope before you set your BAC was done with precision. Vague scope produces a BAC that drifts before the first invoice goes out.
Most IT projects don't fail because the work was bad. They fail because no one caught the cost drift early enough to act on it.
Gives you the fixed reference point that makes early detection possible. Without it, you're comparing actual spend to a moving target, which means every status update is a guess dressed up as a number.
Three outcomes depend on getting this right.
Starts with knowing what "on budget" actually means. Once your BAC is set, you can run earned value analysis in project management to see whether your cost variance is a blip or a trend worth escalating.
Is the one most teams skip. If your approved budget shifts mid-project without a formal change order, your invoices lose their paper trail. That's a dispute waiting to happen on fixed-price contracts.
Ties directly to how well your BAC reflects reality at the start. Defining project scope before you set your BAC is the single best way to avoid the underestimation that quietly eats margin.
The budget at completion formula and project cost forecasting both depend on this number being trustworthy. A BAC that was rushed or guessed produces forecasts that compound the error at every stage.
The budget at completion formula is straightforward:
That means you add every cost element approved in your project plan: labor hours, software licenses, infrastructure, subcontractors, and any contingency reserves that are formally included in the baseline. If a cost wasn't approved in the baseline, it doesn't go into BAC.
Each variable breaks down like this:
Direct costs: hardware, software, third-party services tied to specific deliverables
Indirect costs: overhead allocations your organization assigns to the project
Contingency reserve: buffer approved at project initiation, not management reserve (which sits outside the baseline)
A short example: an IT migration project has $80,000 in labor, $15,000 in infrastructure, $3,000 in software licenses, and a $7,000 approved contingency reserve. BAC = $105,000. That single number becomes your denominator for every earned value analysis in project management calculation that follows.
Getting this right depends heavily on defining project scope before you set your BAC. A vague work breakdown structure produces a BAC that drifts the moment work starts.
Once you have a verified BAC, you can track actual project costs against your approved budget in real time rather than discovering overruns at invoice time.
Start with your Work Breakdown Structure (WBS). Before you can calculate budget at completion, every deliverable needs to exist on paper. A WBS forces you to decompose the project into discrete work packages — software modules, testing phases, deployment tasks — so nothing gets priced in your head and forgotten on the invoice. If you're still fuzzy on defining project scope before you set your BAC, do that work first. An incomplete scope produces an incomplete BAC.
For each item in your WBS, assign a direct cost: labor hours multiplied by rate, plus materials, licenses, or subcontractor fees. Use analogous estimation (based on a similar past project), parametric estimation (unit cost × volume), or expert judgment for anything novel. Don't mix methods inside a single work package — pick one and document it.
Overhead, project management time, and contingency reserves belong in BAC. A common mistake is treating contingency as optional. It isn't. If your contract allows a management reserve on top of contingency, track it separately — it doesn't enter the BAC calculation, but you need to know it exists.
Cross-check your sum against: (a) a comparable past project, (b) a bottom-up re-estimate from a senior engineer, and (c) the client's stated budget ceiling. If two of three checks flag a gap, revisit your estimates before you baseline. Monograph's guidance on BAC notes a 19% utilization gap that commonly appears between estimated and actual resource use — worth building that buffer into labor-heavy phases.
Once validated, record BAC as a fixed figure in your project management system. This is the number that anchors all future earned value management calculations: Schedule Variance, Cost Variance, and eventually Estimate at Completion. Do not revise BAC mid-project to absorb overruns. Revising it destroys the baseline you need for project cost forecasting.
A BAC sitting in a spreadsheet doesn't protect your margin. Map each work package budget to a billing milestone so you can track actual project costs against your approved budget in real time. For example, a $120,000 IT migration project with six phases should have six corresponding invoice points — each one tied to a percentage of BAC. When actuals start drifting from plan, you'll see it before the client does.
BAC in project management is fixed the moment the project is approved. You set it once, based on your defining project scope before you set your BAC and the full work breakdown structure. It does not change when reality does.
Estimate at Completion (EAC) is the opposite. Unlike BAC, which is fixed, EAC evolves throughout the project, taking into account actual costs incurred and current performance trends. You recalculate it at each reporting cycle using earned value data.
The gap between the two is where the signal lives. When EAC starts climbing toward BAC, you have a warning. When EAC exceeds BAC, you have a problem that needs a decision, not a note in the status report.
A practical example: a 12-week software delivery project has a BAC of $180,000. By week six, actual costs are tracking 15% over plan. The recalculated EAC comes out at $207,000. That $27,000 divergence tells you the original budget ceiling has already been breached on the current trajectory.
For a deeper look at how these metrics interact in practice, earned value analysis in project management covers the full framework. To track actual project costs against your approved budget in real time, you need those numbers feeding into a live system, not
On a fixed-price engagement, BAC is your margin ceiling. The moment you sign the contract, your profit is the gap between what the client pays and your BAC. That gap doesn't grow. Every dollar of unplanned cost that creeps in eats directly into it.
This is where earned value analysis in project management becomes practical rather than academic. When your actual costs start tracking toward BAC before the project is 60–70% complete, you're not just behind schedule — you're compressing margin in real time. At 100% of BAC spent with work still remaining, you're billing the client for your own losses.
The budget at completion formula doesn't change mid-project, which is exactly what makes it useful for project cost forecasting. It gives you a fixed reference point. Every week, you compare cumulative actual costs against it. If that ratio is climbing faster than your percent-complete, profitability is deteriorating.
The fix rarely happens at the billing stage. It happens earlier, during scope definition. Defining project scope before you set your BAC is the single most effective way to protect the margin you built into the original estimate.
Most teams start with a spreadsheet. For early-stage projects or simple fixed-price work, that's fine. A shared sheet tracking planned vs. actual costs will show you your BAC in project management and flag when actuals are creeping up. The problem appears around week six, when the sheet has seventeen tabs, three owners, and no single source of truth.
Purpose-built tools solve this by connecting cost tracking to the work itself. When you track actual project costs against your approved budget inside a billing-aware tool, your BAC updates as scope changes, not after your next finance meeting. Inzo specifically ties expense tracking to project-based billing, so when actual costs approach your approved budget, you can trigger an invoice or a scope conversation before margin disappears.
For teams doing earned value analysis in project management, that live cost visibility is what makes EAC calculations meaningful rather than historical.
Budget at Completion works as a fixed anchor only when you calculate it once, validate it thoroughly, and then refuse to move it. The five-step process locks in your baseline, connects it to billing milestones, and gives you the early warning system you need to catch cost drift before it becomes a margin problem.
But here's where manual calculation hits a wall: once you're running five or more engagements at once, spreadsheet-based BAC tracking becomes a liability. You lose visibility into the gap between approved budget and actual spend across projects, and by the time you reconcile everything, the variance is already baked into your invoices. Inzo connects your project cost data directly to your billing workflow, so BAC stays visible and actionable without the spreadsheet overhead. Ready to see how it works?
Q. How do I calculate budget at completion for my project?
A. Build a complete Work Breakdown Structure, sum every cost element (labor, materials, overhead, contingency), and baseline the total in your project system.
Q. What is the formula for calculating budget at completion?
A. BAC = labor costs + direct costs + indirect costs + approved contingency. Exclude management reserve, which sits outside the performance measurement baseline.
Q. Why is calculating budget at completion important in project management?
BAC gives you a fixed reference point for earned value analysis and cost control. Without it, overruns stay hidden until invoice time.
Q. How does budget at completion affect project profitability?
A. A BAC built on vague scope drifts before the first invoice, eroding margin before work begins. Accurate estimation at project start is the only reliable protection.
Q. What tools can I use to calculate budget at completion?
A. Use a spreadsheet for single projects. For five or more concurrent engagements, connect project cost data to your billing system so BAC-to-actuals gaps stay visible without manual reconciliation.
Q. What is the difference between budget at completion and estimate at completion?
A. BAC is the fixed approved budget set at project start and never revised. EAC is a live forecast that updates as actuals diverge from plan.
Q. Can BAC change after a project starts?
A. No. BAC is a frozen baseline. Scope changes require a formal change order, not a BAC revision.
Start your 14 day Pro trial today. No credit card required.