In this article

    A property under budget on paper can still be bleeding cash if half its capital plan sits uninvoiced in a contractor's queue. CapEx tracking breaks down not because teams lack data, but because budget, commitment, spend, and forecast get treated as the same number until a request for funds proves they aren't. An AI assistant pulled into that mess can answer a question fast — "what's our CapEx spend this quarter?" — without knowing which of four different figures the person asking actually needs. This article works through how CapEx data behaves at the property and portfolio level, where AI-assisted analysis genuinely speeds up variance review, and how CapEx fits into a broader [[LINK: commercial real estate analytics platform -> A21]]. It ends with a property-to-portfolio rollup example and a variance framework you can apply to your own capital plan.

    Key takeaways

    • CapEx moves through at least four distinct financial states — budgeted, committed, spent, and forecast — and collapsing them into one figure is the most common source of inaccurate variance reporting.
    • Property-level CapEx rollups require consistent project coding; a renovation split across multiple GL categories will double-count or disappear depending on how a query groups it.
    • AI can accelerate retrieval and comparison of these states once they're modeled distinctly, but it can't reconcile a commitment that was never logged as a change order.
    • Fiscal-year carryover — capital work approved in one year but spent in the next — is one of the most common reasons AI-generated variance answers look wrong on first read.
    • A capital project that's "80% spent" can mean 80% invoiced, 80% paid, or 80% of a stale budget line; the phrase alone doesn't say which.
    • Cost-category taxonomy (structural, mechanical, tenant improvement, deferred maintenance) shifts how the same expenditure rolls up depending on which category convention a firm uses.

    What CapEx Analysis Means at the Property and Portfolio Level

    Capital expenditure (CapEx) analysis in commercial real estate is the practice of comparing what a property or portfolio planned to spend against what it has committed, actually spent, and is now forecast to spend, broken out by project, cost category, and time period. That comparison sounds simple until you notice it depends on four different numbers instead of one.

    Analysis happens at three grains that don't automatically roll up cleanly into each other. Project-level analysis tracks a single capital initiative — a roof replacement or an elevator modernization — from approval through close-out. Property-level analysis aggregates every open project at one asset, which matters for cash planning and lender covenants. Portfolio-level analysis aggregates across properties, funds, or joint ventures, which is where CapEx figures usually feed investor and executive reporting.

    Getting from one grain to the next starts with the same discipline covered in [[LINK: governed CRE metric definitions -> A28]]: a name, a formula, a grain, and an owner for every figure that shows up in a report. The friction shows up when a project spans grains inconsistently. A tenant improvement allowance might sit inside a lease document, get logged as a commitment in the accounting system, and get reported at the property level in an asset management deck — three systems, three timings, one dollar amount that rarely matches across all three on any given day.

    The Four States of a CapEx Dollar

    A single capital dollar moves through up to four states before a project closes, and most CapEx confusion comes from treating two of them as interchangeable.

    Budgeted is the amount approved during planning, usually set months or a full fiscal year before work starts. Committed is the amount obligated once a contract, purchase order, or signed change order exists — work hasn't necessarily happened yet, but the dollar is spoken for. Spent is the amount actually invoiced or paid, depending on whether a firm tracks CapEx on an accrual or cash basis. Forecast is the current best estimate of the project's total cost at completion, which may run higher or lower than the original budget once change orders and field conditions are known.

    The table below shows where each state typically originates and what goes wrong when it's confused with another.

    StateWhat it representsTypical source documentRisk if confused with another state
    BudgetedApproved plan, set before work beginsCapital plan, board/IC approvalReads as spending that hasn't happened yet
    CommittedObligated once a contract existsPurchase order, signed contract, change orderLooks like available budget when it's already spoken for
    SpentInvoiced or paid, per accrual or cash policyAP ledger, GL postingsUnderstates real exposure if committed-but-unpaid amounts are excluded
    ForecastCurrent estimate of total project costProject manager's cost-to-complete estimateGets reported as fact when it's a working estimate

    [[SME: In a live CRE CapEx deployment, what's a specific example of a committed amount that wasn't in the accounting system, and how did the workflow surface that gap?]]

    Why Property-to-Portfolio Rollups Break

    Rolling CapEx up from an individual project to a portfolio total introduces three separate failure points, and each one produces a plausible-looking wrong number.

    Cost-category taxonomy is the first. One firm might code a roof replacement as "structural," another as "deferred maintenance," and a third might split it across both depending on scope. If an analyst or an AI assistant groups spend by category without knowing which taxonomy a given property uses, the rollup either double-counts the project or drops part of it from the total.

    Project coding is the second. A renovation that spans multiple general ledger accounts — materials, labor, contractor fees, permits — has to be tagged with a consistent project ID across every line, or the rollup will only capture whichever GL account happens to match the query's filter.

    Fiscal-year carryover is the third, and it's the one that trips up variance review most often. Capital work approved in one fiscal year frequently gets spent in the next, especially on projects with long lead times. If a portfolio report compares this year's spend against this year's original budget without accounting for prior-year carryover, the variance looks far worse, or far better, than the project's actual pace justifies.

    [[SME: What's a real example of a cost-category mismatch — say, a roof replacement coded as "structural" in one property and "deferred maintenance" in another — that caused a rollup discrepancy?]]

    A Property-to-Portfolio Rollup, Walked Through

    Here's how those failure points show up in practice. Assume a three-property portfolio with one active roof project at each asset, all coded under the same "structural" category, all approved in the prior fiscal year.

    PropertyBudgetedCommittedSpent (YTD)Forecast at completionVariance to budget
    Property A$850,000$820,000$410,000$860,000+$10,000
    Property B$600,000$600,000$600,000$600,000$0
    Property C$1,200,000$1,150,000$300,000$1,340,000+$140,000
    Portfolio total$2,650,000$2,570,000$1,310,000$2,800,000+$150,000

    At the portfolio level, spend to date ($1,310,000) is only 49% of budget, which on its own would read as a healthy underspend. But forecast at completion is $150,000 over the original budget, driven almost entirely by Property C, where the committed amount ($1,150,000) is already close to the full original budget before the project is even a third of the way through spending.

    An assistant asked "are we over budget on CapEx this year?" needs to surface the forecast-to-budget variance, not the spend-to-budget variance, or the answer misleads the asset manager into thinking the portfolio has headroom it doesn't have. The useful diagnostic isn't the portfolio total. It's the property-level detail showing that Property C's commitment pace, not its cash spend, is the real signal.

    Approvals, Change Orders, and Where the Numbers Diverge

    Approval workflows are the mechanism that moves a dollar from budgeted to committed, and they're also where most of the divergence between the two gets created.

    A capital project typically starts with an approved budget line, often set during annual planning with a rough scope and a contingency allowance. Once a contractor is selected, a signed contract converts part of that budget into a firm commitment. From there, change orders — unexpected field conditions, permitting delays, material cost increases — add to the committed amount without necessarily touching the original budget line. Depending on a firm's policy, a change order might require a new approval before it counts as committed, or it might be logged provisionally and formalized later.

    That approval lag matters for anyone querying CapEx data with AI. A commitment that exists in a project manager's spreadsheet but hasn't cleared formal approval yet may or may not appear in the system an AI assistant queries, depending on where in the workflow that data gets recorded. Asking "what's committed on this project" can return two different, both defensible, answers: what's contractually obligated versus what's been formally logged in the accounting system.

    Where AI Actually Speeds Up CapEx Variance Review

    Once budget, committed, spent, and forecast are modeled as distinct fields rather than folded into one CapEx number, AI-assisted analysis is genuinely useful for a specific set of tasks.

    Retrieval is the clearest win. Pulling spend to date for a single property, a single project, or a cost category across the whole portfolio, in seconds instead of a spreadsheet request, removes real friction from a weekly review cycle. Comparison is the second. Asking for every project where forecast exceeds budget by more than a set threshold turns a manual scan of a portfolio-wide CapEx tracker into a direct answer. Drill-down is the third. Going from a portfolio-level variance to the specific property, then the specific GL line or change order driving it, is exactly the kind of multi-step follow-up that a conversational interface handles better than rebuilding a filter in a spreadsheet each time. That retrieve-compare-drill-down sequence is the same pattern behind [[LINK: broader AI portfolio analysis workflows -> A22]]; CapEx is simply the domain where timing and commitment status make the pattern hardest to get right.

    [[SME: When users ask about CapEx variance, what's the underlying data object it actually queries — a GL line, a project ledger, a purchase order — and what does the citation show?]]

    What AI can't do is decide which of the four states you meant when you asked a vague question, invent a committed amount that was never logged anywhere, or resolve a cost-category mismatch between two properties that were coded inconsistently before the data ever reached the assistant. It accelerates analysis of numbers modeled correctly. It doesn't fix numbers that were wrong going in.

    The CapEx Variance Grid

    Most CapEx variance questions collapse into a single number when they should be broken into five. The CapEx Variance Grid separates any capital line — at the project, property, or portfolio level — into the fields that actually explain what's happening.

    DimensionQuestion it answersWhere it typically lives
    BudgetWhat was approved, and when?Capital plan, IC/board approval
    CommitmentWhat's contractually obligated right now?Purchase orders, signed contracts, change orders
    SpendWhat's actually been invoiced or paid?AP ledger, GL postings
    ForecastWhat will this project likely cost at completion?Project manager's cost-to-complete estimate
    TimingDoes the current period compare against the right budget, given carryover?Fiscal year of approval vs. fiscal year of spend

    Applied to a single project, the grid reframes "are we on budget" into five smaller, more answerable questions: was the commitment made within the approved budget, is spend tracking ahead of or behind the commitment pace, does the forecast still fit inside budget plus contingency, and does the timing of the comparison account for work carried over from a prior period. A variance that looks alarming on the budget-versus-spend line often disappears once commitment and timing are added back in, and a variance that looks fine on budget-versus-spend can hide a forecast overrun that hasn't shown up in cash yet.

    Applied at the portfolio level, the same grid works as a screening tool: sort every open project by the gap between commitment and budget, and the properties worth a closer look surface immediately, without waiting for a formal forecast update.

    Where This Falls Short

    AI-assisted CapEx analysis has real limits, and they're worth naming before this gets built into a recurring reporting workflow.

    Source-system errors propagate downstream. If a change order was approved verbally and never entered as a formal commitment, an assistant querying the accounting system will report the project as under budget when it isn't. It can only see what was logged.

    [[SME: What's the most common way property teams mislabel a "spent" CapEx line that turns out to still be an accrual or committed cost?]]

    Cost-category and accounting-treatment conventions aren't universal. Whether a given expenditure gets capitalized or expensed, and which category it's coded under, depends on firm policy and, in many cases, fund or joint-venture agreement terms. An assistant tuned to one property's coding conventions can misclassify spend at another property in the same portfolio if the underlying data wasn't normalized first.

    Fiscal-year carryover requires explicit modeling, not inference. A system that compares current-year spend against current-year budget without knowing a project carried commitments from the prior year will consistently overstate or understate variance on multi-year capital work.

    [[SME: How does Bayaan handle a capital project that spans two fiscal years — does the budget figure a user sees reflect the original approval or a revised carryover budget?]]

    Forecast quality depends on the project manager's estimate, not on the AI. A cost-to-complete forecast is still a human judgment call informed by field conditions. An assistant can surface that number and flag when it changes, but it can't independently verify whether the estimate itself is accurate. Left unresolved, that kind of drift is also one of the earliest signals feeding into broader [[LINK: portfolio risk signals -> A27]], since a forecast quietly moving past budget often shows up as a risk flag before it shows up in cash.

    Turn portfolio questions into governed answers

    See how Bayaan helps CRE teams connect governed business data, investigate portfolio questions, and generate trusted outputs.

    Talk to Bayaan

    A CapEx Data-Readiness Checklist Before You Turn AI Loose on Capital Data

    Before treating AI-generated CapEx answers as reliable enough for asset management or investor reporting, confirm the following are true of your underlying data:

    • Every project has a single, consistent project ID applied across every GL line, purchase order, and change order tied to it.
    • Budget, committed, spent, and forecast are tracked as separate fields, not derived from each other after the fact.
    • Cost categories follow one taxonomy across the portfolio, or the differences between properties are documented and queryable.
    • Change orders and verbal commitments have a defined point at which they become a logged, system-of-record commitment.
    • Fiscal-year carryover is tagged so current-period variance can be calculated against the right comparison base.
    • Someone owns the reconciliation between the project manager's field estimate and the forecast figure in the reporting system.

    If more than one of these isn't true yet, an AI assistant will still return an answer. It just won't be the answer you think you're getting.

    [[SME: In practice, how often do asset managers ask CapEx questions that actually need forecast data the system doesn't have yet, and how does the assistant respond in that case?]]