Docs
Workflows

Valuation DCF

How EQUIRE builds institutional-grade DCF models — the 10-step analyst pipeline, SOURCE_PRIORITY, scenarios, sensitivity (in-app vs Excel), and API hydration guardrails.

EQUIRE's valuation workflow turns extracted deal data and market context into a transparent property-level DCF: assumption provenance, scenario comparison, sensitivity grids, and formula-based Excel export for institutional underwriting review.

Model overview

The DCF engine supports:

  • Unlevered and levered returns (IRR, equity multiple, MoIC)
  • Hold period 1–10 years
  • Base, upside, and downside scenarios
  • Structured capital stacks: all-cash, senior debt, bridge/construction future funding, senior + mezzanine, senior + preferred equity, and custom multi-layer financing
  • Tenant-level lease schedules for office, retail, industrial, and similar income-property engines (hospitality maps through supported rent-roll paths)
  • Unit-mix schedule for multifamily
  • Other property types route through the platform’s classification rules (including mixed-use)

Capital stack control

Valuation models store a structured capital stack alongside legacy financing assumptions. The structured stack is the source for senior debt, mezzanine debt, preferred equity, future funding draws, common-equity proceeds, DSCR, debt yield, and related covenant metrics.

Deal chat can help navigate and update this layer. For valuation financing questions, the assistant should call getValuation first so it can see the current stack and covenant outputs. For financing mutations, it uses approval-gated updateCapitalStack rather than a generic assumption edit. The tool accepts dollar amounts in millions and rates as decimals, then recalculates the base DCF and syncs the primary senior loan back to legacy financing assumptions.

Use structureType="custom" for combined senior + mezzanine + preferred equity stacks or other multi-layer structures that do not fit a single preset. Use all_cash to clear debt and preferred equity.

Starting the model

Valuation Wizard

If no model exists, the Valuation tab offers Start Valuation Wizard. The wizard runs Property Details, Investment Params, and Build Model, pre-populating from extracted deal data.

Analyst pipeline (10 steps)

During Build Model, runModelBuilder() runs ten sequential AnalystStepId steps. Progress streams in the UI. Step ids and labels (from ANALYST_STEPS in code) are:

Step idLabel
data_inventoryData Inventory
tenant_deep_diveTenant Deep Dive
normalize_t12Normalize Financials
reconcileCross-Document Check
market_contextMarket Assumptions
tenant_cashflowsTenant Cash Flows
stabilized_noiStabilized NOI
construct_dcfFinal DCF
risk_assessmentRisk Assessment
synthesisSynthesis

The DCF recalculates several times during the build (after key milestones) so you can watch the model converge.

Assumption inference and SOURCE_PRIORITY

Pipeline and UI respect a single precedence order (canonical SOURCE_PRIORITY tuple):

userdocanalystresearchfundai

  • User edits always win.
  • Document extraction outranks analyst and AI fills.
  • Fund defaults outrank raw AI when both exist (fund policy should not be clobbered by a model guess).

Pipeline updates typically tag new fields as analyst or research where applicable.

Typical inferred levers

  • Market rent and rent growth — from T-12, rent roll, and market context
  • Exit cap rate — from in-place cap, benchmarks, and asset quality
  • Vacancy and credit loss — from occupancy and comparables
  • Operating expense ratio — from normalized T-12

Scenarios and reads

Three scenarios (base, upside, downside) ship by default. Scenario deltas apply at read time against the stored assumption set. Scenario-sensitive calculations in the product and export routes use calculateScenarioDCF / resolveScenarioAssumptions — do not assume “base-only” snapshots for exports.

Hydration guardrails

Treat hasModel: false or missing/null model slices in API responses as a hard signal to reset local valuation state (tenant schedule, T-12 slices, etc.), not to keep stale UI from a prior model. See docs/valuation/valuation-contract.md for the full contract.

Sensitivity matrix: in-app vs Excel export

  • In-app two-way sensitivity (runSensitivityMatrix in dcf-engine.ts) fills cells with levered IRR (returns.irr) and equity multiple — suited for quick scanning in the dashboard.
  • Formula Excel export uses institutional conventions on the workbook’s sensitivity sheets: Sensitivity Matrix 1 (exit cap × rent growth) drives unlevered IRR via the workbook’s Ret_UnlevIRR output — not the same IRR definition as the default in-app matrix corners.

Always label which surface you are looking at when comparing IRRs.

Pre-configured scenarios

ScenarioDescription
BaseCentral case from inferred and document-backed assumptions
UpsideCompressed exit cap, stronger rent growth and occupancy
DownsideStretched cap, weaker growth, elevated vacancy, and related stresses (including debt pricing where applicable)

Excel export

EQUIRE exports a formula-based Excel workbook (live formulas, not static dumps). Typical sheets include Cover, Assumptions, Rent Roll, Operating Expenses, Cash Flow, Debt Schedule, Returns, Sensitivity, Sources (and uses), plus internal _Schema and _Checks sheets. Named ranges connect assumptions to outputs.

ORI and limits

Export preflight enforces row and structure guardrails (e.g. ORI rent-roll caps for non-multifamily types). Consult valuation-contract.md for current limits.

Edit on GitHub

Last updated on

On this page