Project budget vs actual records: why the variance is the valuable part

What does budget vs actual project data contain in an A/E firm?#

Budget vs actual project data in an architecture or engineering firm is the set of records comparing the planned fee, hours and expenses for each project with what was actually spent. Most firms hold it in an ERP such as Deltek Vantagepoint, Deltek Ajera or BQE Core, with fee build-ups in spreadsheets that often predate the project's setup in the system.

The planned side comes from the fee proposal: hours by role and phase, consultant fees and reimbursable allowances. The actual side comes from timesheets, expense reports and consultant invoices posted against the same work breakdown. Between the two sit the project manager's monthly progress estimates and estimate-at-completion revisions, which most controllers treat as reporting artifacts rather than records worth keeping.

• 1Fee budgets by phase, such as schematic design, design development, construction documents and construction administration.
• 2Labor budgets by task and role, and the timesheet hours charged against them.
• 3Consultant and expense budgets compared with posted invoices and reimbursables.
• 4Monthly progress estimates and estimate-at-completion revisions from project managers.
• 5Write-off memos, additional services requests and change orders that explain why the numbers moved.

Why is the variance more useful than the budget or the actual?#

The variance is more useful because it is the only part of the record that demands an explanation. A budget is a forecast and an actual is a result; the gap between them is where a project manager had to notice a problem, decide what to do and live with the outcome.

AI developers building planning, estimating and project-control tools need examples of that loop: a plan, a deviation, a diagnosis and a response. A firm's history of overruns and recoveries, recorded consistently across many projects, shows how real work departs from plans in ways a textbook cannot. A clean budget with no recorded variance teaches almost nothing.

Variance also has a direction and a timing. An overrun caught in design development and recovered through a change order is a different lesson from one discovered at closeout and written off, even if the final totals look the same.

Which reason codes turn variance into decision data?#

Reason codes turn variance into decision data by attaching a cause to each gap, so a reader can tell a client-driven scope change from an internal estimating miss. A short, stable list applied at the phase or task level does more than a long list applied inconsistently.

The supporting record matters as much as the code. A reason code with no change order, RFI or note behind it is an opinion; the same code linked to the document that triggered it is evidence.

What does a usable variance record look like?#

A usable variance record is one row per project phase or task that carries the plan, the actual, the forecast history and the cause, with a pointer to the document that supports the cause. Controllers can usually assemble it from ERP exports and existing project files without new data entry.

Keep dates on everything. An overrun spotted in month three and one discovered at closeout look identical in a closed-project report; only the dated estimate-at-completion history shows the difference, and that difference is what a project-control tool needs to learn.

• 1Project key, project type, delivery method and client type, with no client name.
• 2Phase or task code, mapped to one firm-wide work breakdown if codes changed over the years.
• 3Budgeted hours and fee for the phase, both original and as revised by approved changes.
• 4Actual hours and cost to date by role, not by named person.
• 5Each monthly estimate-at-completion revision with its date.
• 6Variance in hours and as a share of budget.
• 7Reason code, a recorded-or-inferred flag and the ID of the supporting change order, RFI or memo.
• 8Resolution: absorbed, written off, recovered through an additional services request or still open.

What if your firm never used reason codes?#

Firms that never used reason codes can often reconstruct causes from adjacent records, but they should label reconstructed causes separately from causes recorded at the time. Mixing the two misrepresents how the firm actually managed its projects.

The common mistake is asking project managers to assign causes from memory years later. Memory tends to favor the client-caused explanation, which quietly removes the estimating misses that make the history honest and useful.

• 1Pull the projects with the largest phase-level variance from the ERP.
• 2Match each one to change orders, additional services requests and write-off memos from the same period.
• 3Read project manager notes and monthly review minutes for stated causes.
• 4Tag each cause as recorded or inferred, and note the source document.
• 5Stop when the pattern is clear; a well-documented sample beats a thinly tagged archive.

Illustrative: a civil engineering firm's write-off history#

Illustrative: a fictional civil engineering firm runs Deltek Vantagepoint and holds monthly project reviews where principals discuss overruns. Its controller keeps write-off memos in a shared folder, and project managers log additional services requests in the ERP, but nobody has ever linked the three.

During a fit check, the firm learns that its most distinctive material is not the fee totals but the review minutes explaining each overrun. The controller links phase-level variance to minutes, memos and change orders for one project type, municipal water and sewer design, and tags each cause as recorded or inferred.

The firm decides to include phase-level variance with reason codes, express overruns relative to budget instead of in dollars, replace client names with client types and remove billing rates. Internally, the exercise exposes a fee template that consistently underestimated permitting effort, and the firm corrects it before its next proposal round.

What should be removed or banded before licensing?#

Before licensing, remove the fields that identify clients and people and band the fields that reveal pricing, while keeping the structure that makes the variance meaningful. The pattern of overruns survives preparation; exact fee figures usually do not need to.

Check client agreements before the export, not after. Some owner agreements treat project financial information as confidential, and public-sector contracts may carry their own records terms. Counsel should confirm which projects can be included before any file is prepared.

How SourceX treats budget vs actual records#

SourceX treats budget vs actual records as workflow data and assesses them with the SourceX Enterprise Data Value Framework. Variance with recorded causes tends to rate well on its human-generated signal, domain expertise and AI utility drivers, while the framework counts preparation cost and privacy burden against net value. The initial fit check asks only which systems hold the records and how far back they reach; no files move.

If the firm proceeds, the controller signs off on each field treatment before anything is prepared, and the firm approves the finished package before it is released; those are the Preparation and Approval steps of the SourceX five-step transaction, which runs Supply, Rights, Preparation, Approval and Delivery. The SourceX Evidence Packet then shows the buyer which fields were removed or banded, which causes were recorded at the time and which were inferred later, and the permitted use agreed in the license.