What Is BAC in Earned Value? Budget at Completion Explained

<div class="ge-article-wrapper"><nav class="ge-toc" aria-label="Table of contents"><p class="ge-toc-label">In this article</p><ul class="ge-toc-list"><li><a href="#the-definition">The Definition</a></li><li><a href="#how-bac-anchors-every-evm-metric">How BAC Anchors Every EVM Metric</a></li><li><a href="#why-bac-matters-more-than-youd-think">Why BAC Matters More Than You'd Think</a></li><li><a href="#bac-on-nec4-option-c-why-it-isnt-static">BAC on NEC4 Option C, Why It Isn't Static</a></li><li><a href="#worked-example-how-stale-bac-corrupts-your-forecast">Worked Example: How Stale BAC Corrupts Your Forecast</a></li><li><a href="#common-mistakes-with-bac">Common Mistakes With BAC</a></li><li><a href="#frequently-asked-questions">Frequently Asked Questions</a></li></ul></nav><article class="ge-article-body"><p>Budget at Completion (BAC) is the total approved budget for the project, the number every other EVM metric hangs from. It sounds deceptively simple. It's "the budget." But BAC isn't just a number you set at contract award and forget about. On NEC4 Option C contracts, BAC shifts every time a compensation event is implemented. Forget to update it and your entire <a href="/en/earned-value">earned value management</a> system is measuring against a ghost.</p><p>I've watched commercial teams panic about forecast overruns that didn't exist, because nobody had updated BAC after three implemented CEs worth £1.4M. The spreadsheet still produced numbers. They just didn't mean anything.</p><p>BAC is part of the <a href="/en/earned-value/definitions">earned value definitions glossary</a>. For the full formula reference showing how BAC feeds into every other metric, see the <a href="/en/earned-value/formulas">earned value formulas page</a>.</p><h2 id="the-definition">The Definition</h2><div class="ge-formula-box ge-anim"><span class="ge-formula-label">Formula</span><code>BAC = total approved budget for the project (or package)</code></div><p>No formula produces BAC. It comes from the contract. Specifically, from the priced activity schedule (NEC4 Option A), the target total of the Prices (Option C), or the <a href="/en/earned-value/definitions/bill-of-quantities">bill of quantities</a> total (Option B). On a £12M contract, BAC = £12M. On a £50M programme with five packages, each package has its own BAC that rolls up to a programme-level total.</p><p>BAC is the denominator in percentage complete calculations (% Complete = <a href="/en/earned-value/definitions/earned-value">EV</a> / BAC) and the anchor point for every forecasting formula. Get it wrong and everything downstream is fiction.</p><h2 id="how-bac-anchors-every-evm-metric">How BAC Anchors Every EVM Metric</h2><p>Here's what makes BAC critical. It doesn't just appear in one formula. It's embedded in nearly all of them.</p><pre class="ge-ascii-diagram ge-anim"> BAC – The Anchor Point of EVM ================================ BAC (Budget at Completion) │ ├──&gt; % Complete = EV / BAC │ ├──&gt; PV curve endpoint ───────────────────────────┐ │ (BAC is where the S-curve tops out) │ │ │ │ £ │ │ │ ╭── BAC ─────── ▪ │ │ │ ╭──╯ │ │ │ ╭──╯ PV (planned) │ │ │ ╭──╯ │ │ │ ╭──╯ │ │ │╭──╯ EAC ── ▪ │ │ └────────────────────────────────── Time │ │ │ │ If EAC &gt; BAC → overrun (pain share on Opt C) │ │ If EAC &lt; BAC → underrun (gain share on Opt C) │ │ │ ├──&gt; EAC = BAC / CPI │ │ (forecast total cost) │ │ │ ├──&gt; TCPI = (BAC - EV) / (BAC - AC) │ │ (required future efficiency) │ │ │ ├──&gt; VAC = BAC - EAC │ │ (variance at completion) │ │ │ └──&gt; BAC + MR = CBB │ (contract budget base including │ management reserve) │ │ ────────────────────────────────────────────────────┘ One stale BAC corrupts ALL of these calculations. </pre><p>The relationship BAC + MR = CBB (Contract Budget Base) matters on larger programmes. Management Reserve (MR) is the contingency held at programme level for unknown risks. It sits outside BAC but within the total authorised budget. When a risk materialises and MR is drawn down, it increases BAC for the affected package. This is the formal mechanism, don't just absorb cost overruns into MR without adjusting the baseline.</p><h2 id="why-bac-matters-more-than-youd-think">Why BAC Matters More Than You'd Think</h2><p>BAC is the baseline against which everything else in EVM is measured. Get it wrong, or worse, forget to update it, and the downstream effects cascade:</p><ul><li><strong>EV</strong> = BAC x % Complete → wrong BAC = wrong EV</li><li><strong><a href="/en/earned-value/definitions/cost-performance-index">CPI</a></strong> = EV / <a href="/en/earned-value/definitions/actual-cost">AC</a> → wrong EV = wrong CPI</li><li><strong><a href="/en/earned-value/definitions/estimate-at-completion">EAC</a></strong> = BAC / CPI → wrong BAC AND wrong CPI = doubly wrong forecast</li><li><strong><a href="/en/earned-value/definitions/to-complete-performance-index">TCPI</a></strong> = (BAC - EV) / (BAC - AC) → three instances of BAC, all wrong</li></ul><p>One stale BAC corrupts the entire system. And the insidious part? The spreadsheet keeps producing numbers that look perfectly reasonable. They're just measuring against a budget that no longer exists.</p><h2 id="bac-on-nec4-option-c-why-it-isnt-static">BAC on NEC4 Option C, Why It Isn't Static</h2><p>This is where most teams get it wrong.</p><p>On NEC4 Option C, BAC equals the target total of the Prices. But the target adjusts every time a compensation event is implemented under clause 65. If the original contract was £20M and three CEs totalling £1.8M have been implemented, BAC is now £21.8M. Not £20M.</p><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Event</th><th>Adjustment</th><th>Running BAC</th></tr></thead><tbody><tr><td>Original contract</td><td>–</td><td>£20,000,000</td></tr><tr><td>CE-001 implemented (additional piling)</td><td>+£420,000</td><td>£20,420,000</td></tr><tr><td>CE-002 implemented (design change)</td><td>+£680,000</td><td>£21,100,000</td></tr><tr><td>CE-003 implemented (utility diversion)</td><td>+£700,000</td><td>£21,800,000</td></tr></tbody></table></div><p>Every EVM calculation from this point forward should use £21.8M as BAC. If you're still using £20M, your CPI is artificially low (making performance look worse than it is) and your EAC is forecasting an overrun that includes scope changes already paid for through CEs.</p><p>On one highways project I worked on, the commercial team was reporting a £2.1M forecast overrun to the project board every month. The project director was considering a formal cost recovery plan. When we audited the EVM setup, £1.4M of that \"overrun\" was implemented compensation events that hadn't been fed into the BAC baseline. The real overrun was £700K. Still a problem, but a different conversation entirely.</p><h2 id="worked-example-how-stale-bac-corrupts-your-forecast">Worked Example: How Stale BAC Corrupts Your Forecast</h2><span class="ge-worked-label">Worked Example</span><div class="ge-callout ge-anim"><p><strong>Scenario:</strong> A £12M NEC4 Option C bridge rehabilitation contract in South Wales. Over the first 9 months, three compensation events are implemented:</p><ul><li><strong>CE-005:</strong> Unforeseen asbestos in existing abutments → +£280,000</li><li><strong>CE-008:</strong> Client-instructed design change to parapets → +£145,000</li><li><strong>CE-012:</strong> Extended traffic management (statutory undertaker delay) → +£390,000</li></ul><p><strong>Correct BAC</strong> = £12M + £280K + £145K + £390K = <strong>£12,815,000</strong></p><p>At month 9, the commercial team measures:</p><ul><li>Physical progress = 48% complete</li><li>AC = £6,420,000</li></ul><p><strong>Using the WRONG BAC (original £12M):</strong></p><ul><li>EV = £12,000,000 x 48% = £5,760,000</li><li>CPI = £5,760,000 / £6,420,000 = <strong>0.897</strong></li><li>EAC = £12,000,000 / 0.897 = <strong>£13,378,000</strong></li><li>Forecast overrun = £1,378,000</li></ul><p><strong>Using the CORRECT BAC (£12,815,000):</strong></p><ul><li>EV = £12,815,000 x 48% = £6,151,200</li><li>CPI = £6,151,200 / £6,420,000 = <strong>0.958</strong></li><li>EAC = £12,815,000 / 0.958 = <strong>£13,377,000</strong></li><li>Forecast overrun = £562,000</li></ul><p>The EAC numbers are coincidentally similar in this case, but look at the CPI difference. 0.897 vs 0.958. That's the difference between \"we're burning cash at an alarming rate\" and \"we're slightly over budget, let's investigate two specific cost drivers.\" The correct BAC gives you a diagnosis you can act on. The wrong one gives you panic.</p><p>And here's the kicker: the £562K genuine overrun probably traces back to specific packages. Maybe the temporary works cost more than estimated, or preliminary costs are running high. With the right BAC, you can see where the real problem is instead of chasing phantom overruns caused by CEs that have already been valued and agreed.</p></div><h2 id="common-mistakes-with-bac">Common Mistakes With BAC</h2><p><strong>Not updating BAC after compensation events.</strong> The most common mistake by far. Set a process: every time a CE is implemented under clause 65, update BAC in your EVM tracker. Same day. No exceptions.</p><p><strong>Confusing BAC with the contract sum.</strong> At contract award, they're identical. But BAC diverges as CEs are implemented. On JCT contracts, the \"contract sum\" has a specific legal meaning that differs from BAC after variations are instructed. Track them separately.</p><p><strong>Using package BAC when you need programme BAC.</strong> On a multi-package programme, each package has its own BAC. The programme BAC is the sum of all package BACs. Make sure you're comparing EV and AC at the right level, I've seen teams compare package-level AC against programme-level BAC and wonder why their CPI is 3.2.</p><p><strong>Adjusting BAC for unimplemented CEs.</strong> Until a CE is formally implemented (clause 65), it shouldn't change BAC. Notified but not yet quoted? That's a risk, not a baseline change. Quoted but not implemented? Still a risk. Only implemented CEs adjust the target, and therefore BAC.</p><div class="ge-product-note ge-anim"><p><strong>How Gather helps.</strong> Gather's AI reads your site diaries daily and maps progress against your cost-loaded programme, giving you accurate earned value data without manual spreadsheet updates. <a href="https://gatherinsights.com/contact">Book a demo</a> to see it working on a live NEC4 project.</p></div><h2 id="frequently-asked-questions">Frequently Asked Questions</h2><h3>Does BAC ever decrease?</h3><p>Rarely. It happens when a scope reduction is formalised as a compensation event that reduces the target. In practice, BAC almost always grows. That's normal. It reflects genuine scope changes being properly administered. A growing BAC isn't a problem. A BAC that doesn't grow despite 15 implemented CEs is the problem.</p><h3>What's the difference between BAC and <a href="/en/earned-value/definitions/planned-value">PV</a>?</h3><p>BAC is the total project budget. <a href="/en/earned-value/definitions/planned-value">PV</a> is the cumulative budget for work scheduled up to a specific date. It's derived from the cost-loaded programme. At the end of the project, PV equals BAC (because all work should be scheduled by then). At any point during the project, PV is always less than or equal to BAC. Think of PV as the S-curve climbing toward BAC.</p><h3>How does BAC relate to the pain/gain share?</h3><p>On NEC4 Option C, the pain/gain mechanism compares final Defined Cost against the target (BAC). If Defined Cost exceeds BAC, the Contractor absorbs a share of the overrun. If it's below, the Contractor shares the saving. BAC is literally the line that separates profit from loss. Getting BAC right isn't just good EVM practice. It's the difference between claiming a gain share and wearing a pain share.</p><h3>Should I re-baseline BAC or adjust it incrementally?</h3><p>Adjust incrementally as each CE is implemented. Full re-baselines, where you recalculate from scratch, are reserved for major scope changes or contract re-negotiations. Incremental adjustments maintain the audit trail and match the contract administration process under NEC4.</p></article></div>