Apers_
Sign InEnterprise Demo

Apers Open Model CollectionDV-004Institutional

How to Track Construction Costs Against the Budget

A working framework for running a development cost ledger. Three columns per line item, one source of truth for month-end reports, draw requests, and the eventual re-underwrite at stabilization.

Featuring Construction Project Cost Tracker, an Apers open model.

Get the model →Read the framework ↓

Why Development Projects Go Over-Budget Blind

Tracking construction costs against the budget is what separates a development project that stays inside its contingency from one that discovers overruns after the money is already spent. A team that only tracks cash out the door discovers cost overruns six months after the contracts that caused them were signed. By the time the invoice hits the check register, the GC has already framed the addition, the electrician has already run the extra conduit, and the money is committed whether or not a check has cleared. Reversing a commitment costs more than the original scope creep did.

A development team that tracks only against the day-one underwritten budget discovers the opposite problem. The budget is stale within weeks of the first bid package. Change orders accumulate. Line items get reallocated. The reference number the sponsor is reporting to the LP no longer reflects what the project actually costs to finish. Month-end variance reports become an exercise in explaining away numbers that everyone in the room already knows are wrong.

Workflow diagram. On the left a DV-001 Budget box represents the underwritten line items at day zero. An arrow labeled Budgeted Column flows into a highlighted DV-004 Cost Tracker box in the center, which shows three columns (Budgeted, Committed, Spent) across three rows (Hard costs, Soft costs, Contingency). Three arrows fan out to the right into three downstream consumers: LP Month-End Reports (variance vs budget, contingency remaining), DV-003 Draw Requests (committed minus spent, pipeline to lender), and DV-1xx Pro Forma Refresh (actuals feed the re-underwrite at stabilization). Bottom caption reads: one ledger, one project. The underwriting budget flows in on day zero; every LP report, draw request, and re-underwrite reads out of the same three columns.
fig1. Where the cost ledger sits in a development. One tracker in the middle, three downstream consumers on the right, all reading from the same set of line items.

The solution every well-run development converges on is a cost ledger that tracks three amounts per line item, not one. This article walks through the three-column discipline that separates a well-run project from a project that finds itself over-budget six months before it knows it, then shows how DV-004, the Apers open cost tracker, runs that discipline on a single ledger.

The Three Columns Every Line Item Needs

A proper development cost ledger carries three amounts for every general-ledger line item, from land acquisition through the final punch-list draw. Each column answers a different question, and the ledger is not doing its job unless all three are present and current.

  1. Budgeted. The amount underwritten at close, copied line-by-line from the DV-001 pro forma that got the deal approved. This column does not move. If it moves, the sponsor has quietly re-based the reference number and the variance report loses its meaning. The only sanctioned way to change a budgeted number is a formal budget revision approved by the investment committee, and even then the original number stays visible for audit.
  2. Committed. The dollars the sponsor has legally obligated. Signed GC contract, subcontract, purchase order, executed change order. This is money the sponsor owes whether or not the work is complete and whether or not the invoice has arrived. On a typical development, committed leads spent by two to four months.
  3. Spent. Cash disbursed. Draws funded, checks cut, wires sent. This is the number a cash-basis general ledger produces without any additional discipline, and it is the number a lazy project accountant reports as the whole story. It is the least informative of the three.

Two out of three columns is not a workable ledger. Budgeted plus spent misses the commitments already made. Committed plus spent loses the underwritten reference. Budgeted plus committed pretends the project is more current than it actually is. The three columns work together or they do not work at all.

Reading the Gaps

The value of the three-column layout is not in the columns themselves. It is in the two gaps between them, each of which tells the sponsor something the other two columns cannot.

Three-column horizontal bar chart with three rows for a sample $28M development at month 10 of an 18-month schedule. Hard costs row: budgeted $21.0M, committed $19.9M, spent $13.7M. Soft costs row: budgeted $4.5M, committed $4.2M, spent $3.5M. Contingency row (highlighted in orange): budgeted $2.5M, $1.15M committed, $0.85M spent, with $1.35M contingency remaining flagged as 54% at month 10. A legend at the bottom identifies the three fill styles (outline for budgeted from DV-001, cream fill for committed contracts and POs, solid dark for cash spent). A reading key at the bottom notes that budgeted minus committed equals contingency left, and committed minus spent equals the pipeline of draws already queued.
fig2. The two gaps that carry the story. The distance from spent to committed is the draw pipeline. The distance from committed to budgeted is the contingency the project still has to absorb the next surprise.

The first gap, budgeted minus committed, is what the sponsor has left to work with. Early in the project it is large by design; the whole budget is unspent and unobligated. By the middle of construction it should have shrunk in a controlled way that tracks the bid schedule. If it collapses to zero before the project is out of the ground, the project is out of contingency and the sponsor is one bad subcontractor bid away from a capital call.

The second gap, committed minus spent, is the draw pipeline. It is the work the sponsor is contractually on the hook for but has not yet paid. On a healthy project this gap breathes with the construction schedule: it inflates when a subcontractor signs on and deflates as that subcontractor draws. On a distressed project it inflates without deflating, which means invoices are piling up faster than draws are being funded. Either way, the gap is the next draw request the sponsor is going to submit to the lender, and knowing its size a month in advance is the difference between an orderly draw and a scramble.

Change Orders and Contingency Discipline

A change order is a signed amendment to a contract that raises (or occasionally lowers) the committed amount for a line item. Change orders are the vehicle through which scope creep, subcontractor substitutions, and unforeseen site conditions actually enter the project cost. A ledger that does not track them separately loses the ability to distinguish a well-run project from a project where the budget is quietly being rewritten.

The framework treats change orders as a first-class line item, not a plug. Every change order carries a date, an amount, a category (owner-directed, unforeseen condition, design revision), and a source of funds. The source-of-funds field is what enforces contingency discipline. Every change order either draws against the project contingency reserve, against an owner-funded scope addition, or against a reallocation from a favorable variance elsewhere in the budget. If the source of funds is left blank, the change order is not approved.

The cumulative change-order log, read against the contingency remaining, is the earliest reliable signal that a project is heading over budget. A project that burns half its contingency in the first third of construction is not on plan, and the ledger surfaces that in month three rather than in month thirteen.

The Three Handoffs the Ledger Feeds

A cost tracker earns its place in the workflow because three downstream artifacts depend on it, and without a single source of truth those three artifacts drift apart.

  • Monthly LP reports. Every institutional LP expects a monthly project update with committed and spent against budget, variance explanations for the largest line items, and remaining contingency. Producing that report from a spreadsheet that was not designed as a ledger is how three analyst days per month get lost to reconciliation instead of analysis.
  • Construction draw requests. The lender's monthly draw package pulls from the same committed-minus-spent gap the LP report references. A tracker that is not the source of truth for the draw request forces the project accountant to maintain two ledgers and reconcile them, which is exactly how the numbers in the two documents start to diverge.
  • Re-underwriting at stabilization. When the project stabilizes, the DV-1xx pro forma that sized the deal at close is refreshed with actuals for the eventual sale, hold, or refinance decision. Actual total project cost is the input that pins the refreshed IRR. A ledger built for that handoff exports cleanly; a ledger that was not exports painfully.

How DV-004 Runs the Framework

DV-004 is the Apers open institutional-tier model that implements this framework on a single ledger. The top of the sheet imports the budgeted column directly from a DV-001 pro forma export, so the reference numbers are the ones the investment committee approved rather than a re-typed copy. The committed column is populated by contract entry: signed GC contract, executed subcontracts, issued purchase orders, approved change orders, each with a date and a source of funds. The spent column is populated by draw entry: funded draw amount by line item, cross-referenced to the lender's draw package number and the bank's cash confirmation.

The change-order log sits alongside the main ledger with the four fields the discipline requires: date, amount, category, source of funds. Contingency remaining and pipeline (committed minus spent) are computed columns, not entered ones, so the sponsor cannot accidentally overwrite them. Month-end views roll the ledger up to the categories the LP report and the lender draw package expect.

The model deliberately excludes several things a larger project-controls platform would include. There is no construction schedule with critical-path dependencies: DV-004 is a cost ledger, not a scheduling tool, and cost tracking is a distinct discipline from schedule tracking even though the two share inputs. There is no draw-certification workflow with GC pay-app approval routing: that lives in the lender's construction-loan servicing platform, and duplicating it in the model creates two systems of record. There is no accounts-payable subledger: DV-004 tracks committed and spent at the line-item level, not the invoice level, because invoice-level accounting is what the general ledger is already for. Each omission traded scope for solvability at the ledger tier.

When DV-004 Stops Being Enough

DV-004 is built for a single development project from land closing through stabilization. It stops being the right sheet when the workflow expands past what a project-level ledger can carry. Pick the model or platform that matches the actual scope:

The handoff preserves the ledger's structure. Line-item budget, committed, and spent at stabilization are the actuals that refresh the DV-1xx pro forma. Committed-minus-spent at any given month is the input to the DV-003 draw request. The three columns do not translate; they transfer directly.

DV-001 Ground-Up Development is the upstream pro forma that produces the budgeted column DV-004 tracks against. The two models share a line-item taxonomy by design, so the export from DV-001 lands in DV-004 without a translation step. Teams underwriting a ground-up project use DV-001 to size the deal at close and DV-004 to track it from close to stabilization.

DV-002 Redevelopment / Adaptive Reuse is the adjacent underwriting model for conversion projects, and it feeds DV-004 the same way DV-001 does. The tracker does not care whether the budget it is tracking came from a ground-up pro forma or an adaptive reuse pro forma; the discipline is identical, and the line-item categories are the same. A team running both strategies uses one DV-004 per project regardless of which upstream model sized it.

DV-003 Construction-to-Perm Loan Transitionis the debt-side companion. Where DV-004 tracks the sponsor's cost side of the project, DV-003 tracks the lender's debt side and sizes the permanent loan against stabilized NOI. The two are used together in the last quarter of construction: DV-004 confirms the final cost, DV-003 sizes the takeout, and the gap between them is what the sponsor either returns to equity or refinances back into the deal.

Ready to try Apers?

Start using Apers today. No credit card required.

Start for Free