Can AI Work With Your Excel Underwriting Model? Agents Reason, Excel Calculates

The most useful question a model owner asks me is not whether AI can fill a spreadsheet. It is whether the spreadsheet still means the same thing after automation. An input can land in a valid cell and still be wrong: monthly rent entered as annual rent, a percentage entered as 5 instead of 0.05, or a stabilized expense treated as a historical actual.

That is why I separate the work into three responsibilities. The agent interprets evidence and proposes assumptions. The integration maps those values to the model’s declared inputs. The Excel calculation engine evaluates the formulas and returns the outputs that the product has agreed to read.

Automated real estate financial modeling using AI starts with a clear division of work. The Cactus platform uses agents to interpret financial data and explain assumptions, while the configured Excel model calculates the results. For property investors comparing commercial real estate cash flow analysis software, the question is whether that connection preserves the meaning of the model they already use.

What does “agents reason, Excel calculates” mean?

The distinction is practical. If the agent decides a property-tax estimate needs changing, that decision belongs in an input with an explanation. It should not become an independent valuation number written into a paragraph while the workbook still contains the old expense.

What must an existing model expose?

Cactus compiles model metadata that describes input fields, their cell references, and output fields. Tables need their own mappings because a rent roll or T-12 is a collection of rows, not a single value. The model contract gives the workflow names and meanings it can use consistently across deals.

The multifamily broker workflow checks for required input and output mappings, valid cell references, a workbook fingerprint, calculation readiness, and required report/export sheets. Inputs include items such as purchase price, cap rate, rent-roll and T-12 tables. Outputs include the valuation range and NOI measures required by the report.

Compatibility is specific to the workflow. A model can be useful for one analysis and lack the fields needed for another. For example, the compatibility checks distinguish core broker outputs from optional debt-service coverage outputs. Passing the core checks should not be read as a promise that every financing structure or debt-sizing feature is supported.

How should your PM and model owner approach setup?

Treat your own-model setup as a joint model integration project. The PM or model owner supplies the business meaning; Cactus product and engineering turn that meaning into mappings and checks. The work starts with a representative model and a deal whose expected results your team can explain.

• Agree on scope. Identify the asset class, strategy, financial outputs, and report the model needs to support.
• Define inputs. Separate user decisions, extracted facts, defaults, and formulas. Specify units, dates, percentage formats, and which inputs must remain protected.
• Map tables and outputs. Identify where unit rows, financial periods, and comparables belong, and which calculated values the workflow should return.
• Review compatibility. Check required fields, sheet names, calculation stages, and model features before automating deal intake.
• Compare an agreed example. Review populated inputs and calculated results against the model owner’s expected case, including at least one changed assumption.
• Keep version changes deliberate. When the workbook changes, revisit the mapping and financial examples before relying on the new version.

The code enforces technical compatibility; it cannot decide your firm’s investment policy. Your PM remains involved in definitions and acceptance. The automated underwriting pipeline does not insert a mandatory human approval gate into every run, so the team also needs to decide who reviews an analysis before using or sharing it.

What happens when an expense assumption changes?

The workbook calculates $750,000 of NOI and, under direct capitalization, $15 million of value. The analyst then determines that an additional $25,000 of recurring expense belongs in the underwriting. The agent records the reason and changes the mapped expense input. It does not type a new valuation into the report.

The calculation service receives the intended inputs, validates the destination worksheets, evaluates the workbook, and reads the requested output cells. The revised NOI is $725,000, and the illustrative value is $14.5 million. The reviewer can now ask whether the expense adjustment is justified and whether it has already been counted elsewhere.

The same discipline matters for tables. If the next property has fewer rent-roll rows, old values must not remain in unused cells. The calculation service resets previously written cells that are absent from the current input set back to workbook defaults. That detail helps keep one calculation from carrying over data from a previous use of the workbook slot.

How do the report and Excel output stay aligned?

A successful calculation is associated with a workbook revision and an input hash. The publication boundary checks the identity of the result being selected. The application then builds a delivery snapshot from the published underwriting source and persisted workbook data.

That snapshot supports the report and Excel export. Financial checks reconcile the displayed income bridge, reported and normalized NOI, unit counts, and valuation basis. If the wrong revision or inconsistent totals reach this stage, a polished narrative should not hide the problem.

There are two separate reviews here: whether the workbook calculated what you asked, and whether you asked the right underwriting question. Formula execution helps with the first. Evidence, model-owner judgment, and sensitivity review remain essential for the second.

What should you bring to an integration discussion?

Bring the actual workbook, a representative deal package, and an expected result you trust. Include the exceptions that usually cause manual work: incomplete unit data, unusual expense treatment, or a model revision. Ask the team to demonstrate one input change all the way through recalculation, returned outputs, and export.

Hugo’s pipeline guide explains how the source facts reach that mapping, including what happens when a document, calculation, or delivery check fails.