The assumptions register is the most underrated document in commercial real estate analysis. Financial models produce numbers, but those numbers are only as reliable as the inputs that drive them, and without a disciplined record of where each input came from, who approved it, and when it was last tested, a model becomes a black box that no senior stakeholder should trust.
Why Assumptions Registers Fail in Practice
Most real estate financial models carry assumptions that were reasonable at the moment they were entered and quietly became stale as markets moved. An analyst changes a cap rate, a broker updates rent guidance, or a lender revises their underwriting criteria, and the model absorbs each change without any record of what replaced what. The result is a model that reflects a series of undocumented conversations rather than a defensible analytical position.
The failure almost always has a process root, not a talent root. Experienced teams make this mistake because the pressure to produce a number fast is constant, while the discipline of recording context is treated as optional. Building a register forces the team to slow down just enough to ask two questions for every input: what is the source, and who is accountable for it.
A secondary failure mode is confusing sensitivity analysis with assumption documentation. Running a range of cap rates through a model tells you how returns respond to change, but it does not tell you which cap rate is the working assumption, why that rate was chosen, or whether a lender or equity partner has already given feedback on it. Those two activities serve different purposes and should live in separate parts of the analytical workflow.
Defining What an Assumptions Register Actually Is
An assumptions register is a structured record that captures every material input to a financial model, the source or basis for that input, the name of the person or institution that provided or approved it, the date it was last confirmed, and a flag for whether it has been stress-tested. It is not a summary of model outputs, and it is not a sensitivity table. It is the audit trail that sits beneath the model and makes every number traceable.
The register should cover three broad categories of assumption. The first is market-derived: rents, vacancy, cap rates, land values, construction costs, operating expense benchmarks, and financing terms. The second is project-specific: agreed lease terms, tenant allowance commitments, zoning constraints, and site-specific cost adjustments. The third is strategic: target returns, hold period, disposition timing, and any client-defined constraints on leverage or exposure.
Separating these categories matters because they carry different levels of confidence and different refresh cycles. Market-derived assumptions need to be re-confirmed whenever a material period passes or the market shifts, while strategic assumptions are set by the client or investment committee and should not drift without a documented decision to change them. Conflating the two creates models where the team cannot tell whether a number changed because the market moved or because someone internally made a different call.
Establishing the Register's Structure Before the Model Is Built
The best time to set up an assumptions register is before a single formula is written. When the register is built in parallel with model construction, the analyst is forced to identify every variable that will appear as an input, trace a source for it immediately, and flag the ones where the source is weak or missing. This discipline shapes better models from the start.
Each row in the register should represent a single assumption. The columns should capture at minimum: the assumption name, the section of the model it feeds, the current value, the unit of measurement, the source or basis, the date sourced, the name of the person or institution that provided it, the date last reviewed, the reviewer's name, and a status indicator that shows whether the assumption is confirmed, provisional, or pending. Teams that add a "sensitivity priority" column — ranking each assumption by how much model output moves when the input shifts — gain a natural starting point for stress testing.
The structure should be simple enough that a non-analyst can read it. If the register requires deep modeling knowledge to interpret, it will not survive a client review or a legal diligence process. Plain language descriptions of each assumption, written alongside the technical specification, make the document genuinely portable.
Sourcing Assumptions Responsibly
Every confirmed assumption needs a traceable source, and "experience" or "market knowledge" is not a source for a document that will be shared with clients, lenders, or equity partners. The register should distinguish between primary sources — a broker-provided comparable, a lender's term sheet, a third-party appraisal, a published market report — and derived or adjusted values where the team has applied a judgment to a primary source.
For lease-economics assumptions specifically, the sourcing standard should be high. Effective rent, net present value of lease obligations, tenant improvement allowances, free rent periods, escalation structures, and operating expense pass-through treatments all have material effects on comparison outcomes. Each of these should reference a specific document: a proposal, a letter of intent, a lease abstract, or a confirmed broker guidance note with a date and contact.
Where a primary source does not exist — which happens frequently in early-stage feasibility work — the register should say so explicitly and flag the assumption as provisional. A provisional assumption is not a problem; an unacknowledged gap is. Teams that mark gaps clearly can track whether those gaps close as the project progresses, and they can avoid presenting a model as fully confirmed when portions of it are still speculative.
Borrowing assumptions from prior projects without verification is one of the most common quality failures in real estate modeling. Prior-project data makes a reasonable starting point, but the register should label it as such and assign a review task to replace it with current-market evidence before the model moves into client presentation or investment committee review.
Building the Approval and Review Workflow
A register without a review workflow is just a spreadsheet. The value comes from the process that surrounds it: who must review each category of assumption, at what stage of the project, and what constitutes a valid approval. Structuring that workflow before the project starts prevents arguments about whether an assumption was validated.
Market-derived assumptions should require sign-off from someone with current market access — a capital markets adviser, a leasing broker, or a valuer with relevant transaction experience. That person's name, firm, and date of confirmation should appear in the register. Strategic assumptions set by the client or investment committee should be confirmed in writing from the client, with the email or document reference noted in the register. Project-specific assumptions, such as agreed lease terms, should reference the executed or draft document from which they were drawn.
The review cycle should be tied to project milestones rather than the calendar. Teams handling multiple transactions simultaneously often find that assumptions drift silently as analysts copy inputs across projects or update one model without checking whether the same input appears elsewhere. A centralized register, shared across the transaction team and tied to a named review owner, is the operational control that prevents this.
Handling Contested and Uncertain Assumptions
Some assumptions will not be agreed at any point in the analysis cycle. A seller and buyer may disagree on a going-in cap rate. Two lenders may quote materially different leverage and coverage assumptions. A tenant may push back on operating expense inclusions that the landlord's model treats as standard. The register should not hide these disagreements — it should document them.
For contested assumptions, the register entry should show the range of positions, the source of each position, and the value the team is currently using as its working assumption, with a note explaining why that value was chosen. This is especially relevant in lease-economics comparison work, where the difference between a gross and a net lease structure, or between CPI-indexed and fixed escalations, can shift the NPV of a ten-year obligation by a material amount on a hypothetical basis.
Documenting contested assumptions protects the team from two directions. If the project proceeds and the working assumption proves wrong, the record shows that the team identified the uncertainty and disclosed it. If a client or counterparty disputes the analysis, the register provides a clear account of what was known, what was unknown, and what judgment was applied.
Stress testing contested assumptions is where scenario modeling becomes genuinely useful. By defining the base case assumption and the two or three plausible alternatives, then running each through the model, the team can show how the decision changes — or does not change — across the range. That output is far more useful to a decision-maker than a single-point estimate, because it quantifies the risk of being wrong.
##
Assumptions Specific to Lease Economics and Financial Returns
Lease-economics assumptions deserve their own treatment because the variables that drive net present value calculations are numerous, interrelated, and sensitive to small changes in inputs. How to Build an Assumptions Register for a Real Estate Financial Model is in many ways most urgently relevant to lease analysis, where a team is comparing options with structurally different cost profiles and needs to demonstrate that the comparison is apples-to-apples.
The key variables to register and source for a lease NPV analysis include the base rent and scheduled escalation structure for each option, the tenant improvement allowance and the amortization treatment, the free rent period and its effect on commencement date economics, the operating expense base year and any exclusions, the discount rate and its basis, and the term in years. Each of these should have its own register entry. The discount rate in particular should reference a documented basis — whether it is the organization's weighted average cost of capital, a lender's hurdle rate, or a client-defined benchmark — because it has a larger effect on NPV outcomes than most practitioners initially expect.
For acquisition or development analysis, the return-related assumptions include stabilized NOI, exit cap rate, hold period, debt terms, and equity return targets. Each of these has a different sourcing requirement. Exit cap rates are market-derived and require current comparable transaction evidence. Debt terms should come from a lender's indication letter or term sheet. Equity return targets are client- or fund-defined and should be confirmed in writing.
Maintaining the Register Through Negotiation and Diligence
The assumptions register is most valuable during active negotiation and diligence, when inputs are changing rapidly and the pressure to update the model quickly is highest. This is also when documentation most commonly breaks down, because the team is focused on the transaction rather than the record. Building a maintenance habit during the quieter early stages of a project makes it easier to sustain through the intense later stages.
If a landlord counters on tenant improvement allowance or modifies the free rent structure, the register entry for each affected assumption should be updated with the new value, the date, and a note identifying the round of negotiation that produced it.
This practice is especially important when multiple reports arrive in rapid succession, as the register prevents individual findings from being absorbed into the model without a clear attribution trail.
For teams managing ongoing portfolios, the register also supports post-occupancy or post-acquisition review. When actual operating performance can be compared against the assumptions that underpinned the original decision, the register provides the baseline. Understanding where assumptions held and where they diverged from reality is how teams improve their underwriting calibration over time, and that institutional learning only accumulates if the original assumptions were recorded in sufficient detail to compare against later actuals.
Presenting the Register to Clients and Decision-Makers
A well-constructed assumptions register, when presented alongside a financial model in a client recommendation or investment committee review, demonstrates that the analysis was built on traceable evidence rather than convenient inputs. It gives the audience a clear path to challenge any assumption they disagree with. This transparency is a signal of analytical quality, not a weakness.
The presentation version of the register should be condensed. Not every technical parameter needs to appear in front of a client. The material assumptions — those that drive at least a specified percentage of the output's sensitivity — should be presented with their source, their current value, and a brief note on the basis for choosing that value over alternatives. Where contested assumptions exist, those should be surfaced explicitly rather than buried.
Decision-makers who review a register presented this way are able to engage more precisely with the analysis. Rather than questioning the model's output in general terms, they can target the specific inputs they want to test. That conversation is more productive, more efficient, and more likely to result in a clear decision.
Reviewing and Closing the Register at Project Completion
When a transaction closes or a decision is made, the assumptions register should be reviewed one final time and locked. This final review serves two purposes. The first is to confirm that the model used for the final decision reflected the last agreed set of assumptions and that no undocumented changes were made in the final stages. The second is to create a project archive that is useful for future analysis.
The team can review what assumptions held through the process and which ones required significant revision, and they can carry forward a more calibrated starting point for similar work. This is how firms build institutional knowledge rather than re-learning the same lessons each time.
ADVANTAGE AI LLC, a Delaware limited liability company, operates the platform and publishes its Terms, Privacy and Trust pages at advantaico.com, where the Trust principles include Evidence before reliance and Review before outreach.
Integrating the Register into Team Operating Standards
The register is most effective when it is not a project-specific invention but a standard operating procedure that every transaction or advisory team applies by default. That means defining the template before anyone needs it, training new team members on its use during onboarding, and including register completion as a formal checkpoint in project milestone reviews.
When a lender or equity partner asks "what cap rate are you using and why?", the answer is already documented and defensible. When a client asks "how did you arrive at this rent assumption?", the register provides the answer immediately without requiring the analyst to reconstruct the thinking from memory.
The register also creates accountability within the team. When every assumption has a named owner and a review date, there is no ambiguity about who is responsible for keeping a particular input current. That accountability structure reduces the risk of a material assumption going stale through inattention, particularly on long-cycle transactions where months may pass between model updates.
Applying consistent standards across the team also makes peer review faster and more effective. When a senior adviser reviews a junior analyst's model, the register provides the fastest possible path to identifying weak assumptions — those sourced from a single point, those marked provisional and not yet confirmed, those whose review date has passed. The review can focus on substance rather than reconstruction.
About Advantai
Advantai is a commercial real estate intelligence and operations platform operated by ADVANTAGE AI LLC, a Delaware limited liability company. It connects client relationships, property research, documents and financial decisions in one workspace for commercial real estate teams — advisers and brokerage teams, occupier and facility teams, and portfolio teams. The platform covers CRM and origination, requirements and site selection, Property X-Ray (an interactive 3D building workspace), financial modeling and comparison, document intelligence, transactions and diligence, client collaboration, and portfolio strategy with critical dates. The optional Super Agent upgrade adds specialist, source-backed research and automated scenario analysis.
Get Started with Advantai
Ready to see your next move clearly? Go to advantaico.com, click Request a demo and tell us about your next project. Prefer to start with a single project? Visit advantaico.com/getting-started to plan your first one.