Budget vs. Actual Report

Definition — what it is

A budget vs. actual report compares the current budget for a project against costs incurred to date, at the cost-code level, and expresses the difference as a variance in dollars and percentage. It sits on top of the job cost ledger and the budget structure, and its purpose is to surface where a job is spending more or less than planned while there is still time to change the outcome. It is a snapshot of position, not a forecast: a favorable variance today can hide a cost that is committed but not yet booked, which is why a mature BvA is read alongside commitments and cost-to-complete rather than alone. It is not the same as a WIP schedule, which reconciles cost and billing to recognize revenue; BvA is the operational drill-down that explains what the WIP summarizes.

Also known as: Budget-to-Actual, Cost Variance Report, BvA, Budget Comparison Report

Why it matters — what it protects

Budget vs. actual is the earliest routine warning that a job is drifting. A negative variance in a single labor cost code, three months into a nine-month schedule, is a signal that either the estimate was wrong or the work is being performed inefficiently - and both are fixable early and nearly unfixable late. Reading the variance at the code level, rather than the project level, is what separates management from bookkeeping.

The report is where margin is protected or lost, one code at a time. A project can be on budget in aggregate while a concrete code runs 20 percent over and an underground code runs 20 percent under, and the aggregate view hides a real problem behind an accidental offset. Because the codes that overrun are rarely the codes that underrun in the next phase, netting them together is how contractors convince themselves a job is fine until it is not.

Budget vs. actual is the connective tissue between the field and the office. The superintendent knows the crew is behind on drywall; the accountant knows the drywall code is over budget; the BvA is where those two facts meet and become a decision. When the report is stale or the codes do not match how the work is actually run, the field and the office argue from different numbers and neither trusts the other.

It is the raw material for every report above it. The WIP schedule, the profit fade analysis, the executive dashboard, and the cost-to-complete all inherit their credibility from the BvA underneath. If costs are miscoded, if commitments are missing, or if the budget has not been updated for approved change orders, the error propagates upward and the executive sees a confident number built on sand.

Lifecycle — how it moves

1. Budget establishment

   The original budget is loaded from the estimate at buyout, mapped to the cost-code structure. The quality of everything downstream is set here: if the estimate's assemblies do not map cleanly to how costs will be captured, every variance will be an argument about coding rather than performance.

2. Cost accumulation

   Labor from timecards, material from AP invoices, subcontractor billings from commitments, and equipment charges post to cost codes over the life of the job. The report is only as current as the last posting, and unposted invoices are the most common reason a favorable variance is an illusion.

3. Budget revision

   Approved change orders and internal budget transfers move the budget line. A disciplined shop keeps the original budget, the approved changes, and the revised budget as separate columns so a variance against the revised budget is never confused with a variance against the estimate.

4. Variance calculation

   For each code, actual-to-date is subtracted from budget, or from earned budget where percent complete is applied. The choice matters: comparing full budget against partial actuals makes every early-stage code look favorable and is the single most common misreading of the report.

5. Exception review

   Project managers and accounting review codes breaching a variance threshold. This is where the report earns its keep or fails to: a review that only looks at codes already over budget misses the codes trending toward it.

6. Explanation and coding correction

   Each material variance is explained - a miscode, a timing difference, a genuine overrun, or an unbooked commitment. Miscodes get corrected; genuine overruns get a recovery plan or a revised cost-to-complete.

7. Roll-up and forecast link

   Code-level variances feed the cost-to-complete and the WIP schedule. A variance that is real and permanent should change the forecast; a variance that is a timing difference should not.

8. Archive and post-job analysis

   At closeout, final actuals against final budget become the historical cost data that calibrates the next estimate. Contractors that skip this step re-learn the same overruns on every job.

Anatomy — the data it carries

Cost code

The account the work rolls up to, typically CSI MasterFormat or a company-specific structure. Codes too coarse hide problems; too granular and nobody codes consistently.

Cost type

Labor, material, equipment, subcontract, other. Variance behaves differently by type - labor overruns compound, subcontract overruns are usually fixed once bought out.

Original budget

The buyout budget from the estimate. Preserved unchanged so drift from the original plan stays visible even as the revised budget moves.

Approved changes

Budget added or removed by executed change orders. Separated from the original so scope growth is never mistaken for performance.

Revised budget

Original plus approved changes - the number a current variance should be measured against.

Actual cost to date

Posted costs from the job cost ledger. Its reliability depends entirely on coding accuracy and how current the AP and payroll postings are.

Committed cost

Purchase orders and subcontracts issued but not yet fully billed. A code can be within budget on actuals and blown on commitments.

Projected final cost / estimate at completion

Where the code is expected to land. The forward-looking number that turns a static report into a management tool.

Variance (dollars)

Budget minus projected or actual. The absolute number that tells you the size of the problem.

Variance (percent)

Variance over budget. Normalizes so a small code with a large percentage overrun is not lost next to a large code with a small one.

Percent complete

How far along the work is, used to earn budget for a fair comparison. Missing or wrong percent complete is why BvA gets misread.

Variance explanation / note

The narrative for each flagged code. A report without explanations is a scorecard; a report with them is a decision tool.

Failure modes — how it breaks

Comparing full budget to partial actuals

Every code looks favorable at 30 percent complete because the full budget dwarfs the costs booked so far. Without earning the budget by percent complete, the report systematically flatters early-stage jobs and the first real warning arrives far too late.

Unbooked commitments hiding overruns

A subcontract or purchase order is issued but the invoices have not arrived, so the actual cost looks fine while the money is already spent. Reading actuals without commitments is how a code shows green the month before it goes deep red.

Miscoded costs shuffling variances

A crew charges the wrong code, or material lands on a catch-all code. One code shows a phantom overrun while another shows a phantom saving, and hours are wasted investigating variances that are pure coding noise.

Budget not updated for approved changes

Executed change orders add scope but the budget line never moves, so the added cost shows as an overrun against the original budget. The PM spends the review defending a variance that is really just missing budget.

Netting overruns against underruns

The project total looks on budget because an underrunning code masks an overrunning one. The masking code is often about to finish while the overrunning code has months to run, so the aggregate view is quietly optimistic.

Stale report driving current decisions

The BvA reflects last month's postings because this month's payroll and AP have not closed. Decisions get made on data that is thirty days old, which on a fast-moving code is a different job entirely.

No link between variance and forecast

A code runs over and everyone agrees it is real, but the cost-to-complete is never revised. The overrun is acknowledged and then forgotten, and it reappears as a surprise at the WIP true-up.

Metrics — how it is measured

Total cost variance

Revised budget minus projected final cost across all codes, in dollars and percent. The headline, but the least diagnostic - always drill in.

Number of codes over threshold

Count of codes breaching the variance tolerance. A rising count is an early sign of estimating or execution problems even when the total looks fine.

Labor cost variance

Isolated because labor is the most volatile and controllable cost type. Persistent labor overrun points to productivity, not price.

Committed vs. actual gap

How much cost is committed but not yet booked. A large gap means the actuals-only view is unreliable and forecast risk is high.

Coding accuracy rate

Share of postings that land on the intended code without correction. Low accuracy makes every other metric noisy.

Variance explanation coverage

Percent of flagged codes with a current, documented explanation. Measures whether review is happening or the report is just being filed.

Forecast reconciliation lag

Time between a variance being confirmed real and the cost-to-complete being updated to reflect it.

The AI shift — what actually changes

Conversational

The report stops being a grid you scan code by code. You ask which codes are trending over budget after adjusting for percent complete, which favorable variances are actually unbooked commitments, and which overruns are new this period versus carried forward - and get the answer with the underlying postings cited, not just a colored cell.

Generative

Instead of a manager typing a variance narrative for each flagged code, a draft explanation is produced from the underlying transactions: the invoices, timecards, and change orders that moved the number, with the likely cause proposed and the offsetting entries identified. The manager confirms or corrects rather than reconstructs from scratch.

Orchestrated

The BvA stops living apart from the systems that feed it. A confirmed overrun on a code is checked against open commitments, matched to the change events that should have added budget, reconciled against the schedule activity's percent complete, and pushed into the cost-to-complete and WIP so a real variance updates the forecast automatically rather than by memory.

Autonomous

The routine motion runs continuously: postings screened for likely miscodes on entry, variances recomputed on an earned-budget basis as costs land, codes crossing threshold flagged with a drafted cause and the supporting transactions attached, and unbooked commitments surfaced before they become surprises - while humans decide what is a real overrun, approve any budget revision, and own the recovery plan.

Prompts — put it to work

Tool-agnostic and copy-ready. Adapt the specifics — thresholds, contract windows, cost codes — to your own project before you run them.

Conversational — Preparing for the monthly job review on a project you do not run day to day.

Review the budget vs. actual for this job. Earn the budget by each code's percent complete before you compare, then show me every cost code where the projected final cost exceeds the revised budget by more than 5 percent or 25,000 dollars, whichever is smaller. For each, give me the code, cost type, revised budget, actual to date, committed but unbilled, projected final, and the dollar and percent variance. Separate genuine overruns from timing differences and unbooked commitments, and rank by dollar exposure. Do not net favorable codes against unfavorable ones.

What good output looks like: A ranked, earned-budget view of real exposure with timing and commitment effects stripped out - not a raw dump of every red cell in the grid.

Follow-ups:

• Which of these overruns are labor, and are they price or productivity driven?
• Which favorable variances are really just commitments that have not been invoiced yet?
• Show me the codes that are not over budget yet but are trending that way.

Generative — You have to write variance explanations for eight flagged codes before the review.

For cost code 03-3000 (cast-in-place concrete, labor), the projected final cost is 41,000 dollars over the revised budget of 260,000. Draft the variance explanation for the monthly report. Read the underlying timecards, AP invoices, and any related change events, identify the most likely driver, distinguish rate from productivity, note whether any of the overrun should have been covered by an approved change, and propose whether the cost-to-complete needs revising. Write it in factual, non-defensive language a project executive would accept, three to five sentences, and cite the specific transactions you relied on.

What good output looks like: A grounded, transaction-cited explanation that names a specific cause and a forecast action, not a generic 'costs were higher than expected' line.

Follow-ups:

• Redraft assuming the recovery plan is to add a second crew for two weeks - what does that do to the forecast?
• Write the same explanation for a code where the variance is purely a miscode we need to correct.
• Summarize all eight explanations into a three-sentence project-level narrative.

Orchestrated — A concrete code just breached threshold and you need to know what it touches.

Cost code 03-3000 crossed our variance threshold this period. Trace it end to end: pull the transactions that moved it, check whether any of the cost should map to an approved or pending change event that would add budget, verify the code's percent complete against the related schedule activity, check open commitments on the code for cost not yet booked, and determine whether the cost-to-complete and WIP schedule need updating. Return one summary with each conclusion tied to the specific record that supports it, and flag anything you are not confident about instead of guessing.

What good output looks like: A cross-referenced trace linking the variance to transactions, change events, schedule, commitments, and forecast - with citations and explicit uncertainty flags.

Follow-ups:

• If budget is missing, draft the change event and the budget revision entry for approval.
• Update the cost-to-complete for this code and show me the effect on projected job margin.
• Which other codes on this job share the same driver and should be checked now?

Autonomous — Standing policy for how budget vs. actual monitoring should run itself between reviews.

Monitor budget vs. actual continuously across active jobs under these rules. On posting: screen each cost entry for a likely miscode against the code's history and the vendor or crew, and hold suspected miscodes for review rather than letting them distort variances. Between reviews: recompute variances on an earned-budget basis as costs land, and flag any code whose projected final exceeds revised budget by more than 5 percent or 25,000 dollars with a drafted cause and the supporting transactions attached. Surface unbooked commitments before they show as overruns, and surface codes trending toward threshold, not only those already past it. Never revise a budget line, reclassify a posting, or change a cost-to-complete without my approval, and route every suspected genuine overrun to me with your reasoning.

What good output looks like: A continuously current BvA with a short exception queue and full audit trail, where budget and forecast changes never happen without a person.

Follow-ups:

• Show me everything you flagged this week and everything you held for miscode review.
• Which of your flagged overruns turned out to be timing, and how should you adjust your threshold logic?
• Roll your confirmed overruns into a draft cost-to-complete update for my approval.

Get the full Construction AI Prompt Catalog — every prompt in the library in one document.

Maturity — locate yourself honestly

0. Level 0 - Spreadsheet after the fact

   Actuals are exported to a spreadsheet weeks after the period closes and compared to a budget by hand. Variances are historical curiosities by the time anyone sees them.

1. Level 1 - Standard report

   The accounting system produces a code-level BvA on a schedule. Variances are visible, but percent complete and commitments are added manually if at all.

2. Level 2 - Earned and committed

   Budget is earned by percent complete, commitments are included, and variances are read against a revised budget that reflects approved changes. The report is a real management tool.

3. Level 3 - Assisted

   Likely miscodes are flagged on entry, variance explanations are drafted from transactions for review, and confirmed overruns are linked to the forecast automatically.

4. Level 4 - Operated

   Variance monitoring runs continuously between reviews inside guardrails - screening, recomputation, trending, and exception flagging - while humans own what is real, every budget revision, and every forecast change.

Common questions

What is the difference between budget vs. actual and a WIP schedule?

Budget vs. actual is an operational drill-down: it compares budget to cost at the code level to explain where a job is spending more or less than planned. The WIP schedule is a summary reconciliation that uses those same costs, along with the contract value and billings, to recognize revenue and surface over- and under-billing. BvA answers 'which codes are in trouble'; WIP answers 'what should this job's revenue and margin be this period'. They must tie to each other, and when they do not, the BvA is usually the one that is right.

Should I compare actuals to the original or the revised budget?

Both, in separate columns. Variance against the revised budget tells you whether you are executing the work you are now contracted to do; variance against the original budget tells you how much the job has drifted from the estimate through change orders and scope growth. Reading only the revised budget can hide a job that has grown 40 percent through changes; reading only the original can make approved, funded scope look like an overrun.

Why do favorable variances make experienced people nervous?

Because early favorable variances are usually timing, not performance. A code that is 20 percent under budget at 15 percent complete almost always has costs that are committed but not yet booked, work not yet performed, or invoices not yet received. A genuine, durable saving is real and worth capturing, but it has to be proven against commitments and percent complete before it is believed, because a favorable variance that reverses is worse than an overrun you saw coming.