Two runs disagree when they run on different inputs, not because the model is unstable. On a 416-unit Tampa underwriting, an early pass priced the deal off a county tax assessment instead of income and returned a 53% IRR. The corrected pass derives price from Year-1 income, passes four automated checks, and was recalculated twice to the cent.
The question behind the question
When someone asks why two Titleman runs on the same address came back different, they are really asking one of two things: is the model unreliable, or did something specific change between the runs. Those have different answers, and conflating them is what makes a discrepancy feel scarier than it is. We're going to walk one real case all the way through, because a worked example is more useful than a list of hypothetical causes.
The property and the first number
The case is Legend Oaks, a 416-unit multifamily property at 4714 N Habana Ave, Tampa, FL, run through Titleman's multifamily underwriting workbook. The first draft of that workbook returned a levered IRR of 53%, an equity multiple of 6.36x, and a debt service coverage ratio of 2.98x. Those numbers were not a bug in the arithmetic. The formulas connecting price, debt, income, and exit value were all correct. What was wrong was one input feeding all of them.
The input that was wrong
The purchase price cell had been set to Legend Oaks' county-assessed value: $35.21M. That figure was already sitting in Titleman's Tampa research, already sourced, and already in the spreadsheet — which is exactly why it was easy to reach for. But a county assessment is an administrative number local government uses to calculate property tax. It has no necessary relationship to what a building's income can actually support a buyer paying for it. Underwriting works by comparing two things that are supposed to describe the same deal from two directions — what the income justifies, and what the price costs. Put an income figure on one side and a tax-administration figure on the other, and the model doesn't fail. It reports the gap between the two unrelated numbers as if that gap were investment return. That is what the 53% IRR actually was: not a projection, but the size of the mismatch between a market income and a tax basis.
This is worth sitting with, because it is the general shape of most cases where two runs disagree: not a model that is unstable from one run to the next, but an input that quietly changed roles — a number that was sourced and correct for one purpose (calculating a tax bill) getting reused for a different purpose (pricing an acquisition) it was never built to serve.
What actually changed in the fix
Three concrete changes, all visible in the file itself rather than described after the fact:
The price stopped being a static lookup and became a derived figure. It is now calculated from the building's own Year-1 income at a stated going-in capitalization rate, with the county-assessed value demoted to a reference line the workbook's own Sources tab marks as never to be used as a price. We are not going to restate the resulting price here — the underlying report documents the formula (Year-1 income divided by the stated cap rate), not a resulting dollar figure carried as a verified line item, and we don't want to imply a precision the source itself doesn't claim.
A peer-comparison step was removed from the exit calculation. The peer figures it had been drawing from are themselves assessed values, not market prices. Comparing an exit market price against a peer set of assessed values would have reintroduced the identical basis mismatch in a different tab.
Four automated checks were added, and every one of them would have caught the original error before it shipped: a going-in yield outside a plausible band, an exit cap rate priced tighter than the going-in cap (which should make an underwriter suspicious on its face), a debt coverage ratio above a sane ceiling, and an operating expense ratio implausibly low for the property's location once insurance is priced in. The report that documents this puts it plainly: a model that's wrong in a flattering direction doesn't look wrong. It looks like a good deal. That's the reason the checks run inside the workbook itself, every time, rather than depending on a reviewer's memory.
Why the second number earns more trust than the first
"Different" is not the same as "more trustworthy," and the reason the corrected run is the one to rely on isn't just that it looks more reasonable. It's that it was checked differently. The corrected outputs — Year-1 income of $3,681,558, an operating expense ratio of 48.09%, a loan sized by testing both a loan-to-value limit and a debt-coverage limit and taking the more conservative of the two, a resulting equity multiple of 1.47x and a levered IRR of 8.66% — were recalculated independently twice: once directly against the file with a separate formula engine, once from a second implementation of the same model built separately. The two landed a hundredth of a percentage point apart on IRR, which is a rounding difference, not a disagreement. The first draft's 53% never went through that process at all — it was caught before anyone tried to independently confirm it, precisely because the reality checks flagged it as implausible on sight.
That is the actual differentiator: not that the model never errs, but that every number in the corrected version carries a visible tag — sourced, assumed, or computed — and every assumption is stated on the tab that uses it rather than buried in a note. An error like the assessed-value mix-up is exactly the kind of thing that tagging discipline is built to surface.
What to do when you see two numbers from us
First, don't average them or split the difference — one of the two inputs is usually just wrong for the role it's being used in, the way a tax assessment was wrong standing in for a price. Second, ask which basis each number ran on: what was the price assumption, and was it observed or derived. Third, ask whether the run passed its own internal reality checks, or whether a check fired and was overridden. And treat everything we hand back as an opinion of value built from stated inputs, not a valuation or an appraisal — we don't hold that license, and the workbook's job is to make its own inputs checkable, not to be treated as a certified number. If you can't tell which of two runs to trust, the fastest path is to ask us for the Sources tab of each one and compare the price line specifically. That single cell was the entire difference between 53% and 8.66% here.