Most underwriting automations fail for a reason that has almost nothing to do with the AI: the firm points a precise machine at imprecise inputs, tries to automate the entire underwrite at once, and gives the analyst no reason to trust the number that comes out — so the analyst quietly goes back to the spreadsheet. The base rate here is brutal and well documented. The RAND Corporation puts the AI project failure rate above 80 percent, roughly twice the failure rate of comparable non-AI IT projects, and Gartner has estimated that around 60 percent of AI projects will be abandoned through 2026 because the underlying data was never ready for them. S&P Global Market Intelligence found the share of companies scrapping most of their AI initiatives jumped from 17 percent in 2024 to 42 percent in 2025. At a 4-to-20-person commercial real estate firm the failure is sharper, because there is no data team to clean the inputs, no engineer to babysit the model, and no analyst to spare when the automation produces a number nobody believes. This piece breaks down the five failure patterns specific to lean CRE shops, why bolting AI onto a broken intake makes underwriting worse rather than better, and what an automation that actually survives real deal flow looks like.
Why most underwriting automations fail: the data, not the model
The honest answer is that underwriting automations fail because the inputs are a mess and the model faithfully computes on the mess, not because the AI is bad at arithmetic. Modern language models are more than capable of mapping a rent-roll line to a model row or pulling trailing-twelve actuals out of a PDF. What they cannot do is fix the fact that every broker sends a differently-shaped file, that half of them are scanned images, and that the numbers inside them are wrong often enough to matter.
The research points at the same culprit from every angle. Gartner’s finding that most abandoned AI projects die on inadequate data readiness is not an abstraction in commercial real estate; it is the daily reality of an inbox full of non-standard rent rolls. On the input side, manual data entry from CRE documents carries an error rate estimated between 5 and 15 percent depending on document quality and how tired the analyst is, and a single rent-roll mistake can move a property’s net operating income by six figures. Automation does not erase that error. Pointed at a bad input, it produces a bad output faster and with more decimal places.
None of this is unique to real estate; the 80-percent-plus failure rate spans every industry that has tried to automate a judgment-heavy process. What is unique is how the failure plays out at a firm of 4 to 20 people. Generic automation advice quietly assumes a data team to standardize the inputs, an engineer to maintain the pipeline, and enough deal volume that the same workflow repeats thousands of times. A lean CRE shop has none of the three. The instinct to make a small team punch above its headcount, which runs through the small-firm CRE operating thesis, depends on automations your analysts actually trust and keep using — not ones they route around after the second bad number.
The five failure patterns specific to lean CRE firms
Strip away the generic causes and five failure patterns show up again and again at firms under 20 people. Each one compounds the next.
The inputs are never standardized
An underwriting automation is only as good as the documents you feed it, and CRE documents are chaos by default. A brokerage receives rent rolls, T12s, and offering memoranda as PDFs — some system-generated, some scanned, almost none in a consistent format — and every property manager and broker structures theirs differently. A firm buys an extraction tool expecting it to read all of them cleanly, discovers it stumbles on the scanned ones and the oddly-merged cells, and concludes the automation “does not work.” The automation works; the intake was never standardized enough for it to work reliably. Without a deliberate step that normalizes messy files into a consistent structure before the model touches them, accuracy swings deal to deal and trust collapses on the first miss.
Garbage in, laundered out
The more dangerous failure is not that the automation breaks, but that it does not. Feed it a rent roll with a transposed figure or a mislabeled expense and it will not flag the error — it will carry that number into a clean, confident, precisely-formatted model the investment committee then treats as truth. A human analyst reading the same rent roll often catches the outlier because it looks wrong. The automation launders a 5-to-15-percent input error into an authoritative-looking output, and the firm makes a worse decision than it would have on a spreadsheet it distrusted. Speed with no validation layer is not an asset in underwriting; it is a way to be confidently wrong at scale.
The build is over-scoped
The most common commissioning mistake is trying to automate the whole underwrite at once. A firm sets out to build a system that ingests every broker email, extracts every financial, runs the full underwriting model, writes the memo, and updates the pipeline — a project that would tax a funded proptech startup, attempted by a six-person shop as a side effort. It stalls, the vendor invoices climb, and the half-built system gets abandoned. The automations that survive at lean firms are narrow: they take the single most repetitive, most mechanical step and do only that. Deciding which step to automate first is a screening problem in its own right, and the discipline of killing weak candidates fast — covered in our deal screening framework — applies as much to choosing what to build as to choosing which deals to chase.
The analyst does not trust the black box
Underwriting is a judgment job, and an analyst who cannot see how a number was derived will not stake a recommendation on it. When an automation returns a stabilized value or a mapped rent-roll figure with no visible trail back to the source document, the analyst does the rational thing: they re-key it by hand to check it, which erases the time the automation was supposed to save, and then they stop using it. A tool that produces answers nobody can audit is not a time-saver; it is shelfware with a subscription. Traceability — every output linked to the exact line in the source PDF — is not a nice-to-have. It is the thing that decides whether the analyst adopts the automation or abandons it.
Nobody owns it
Every automation that survives has one person responsible for keeping it honest, and every failed one has a diffuse sense that the tool is everybody’s and therefore nobody’s. Models drift, a vendor changes an extraction behavior, a new broker’s format breaks the parser, and with no named owner to catch the regression and correct the mapping, error creeps back in until the team quietly reverts to doing it manually. At a small firm the owner does not need to be a full-time hire; it needs to be a named person — usually a principal or an ops lead — who spot-checks the outputs, maintains the templates, and decides when the automation is trustworthy enough to skip the manual re-check.
Why bolting AI onto a broken intake makes it worse
Adding a language model on top of a broken underwriting intake does not fix the process; it accelerates the failure. This is the uncomfortable part, because the current wave of AI-underwriting marketing sells the model as the cure for a slow, manual process. The problem is that the model reads whatever is in the documents and asserts on it with total confidence. Point ChatGPT, Claude, or a purpose-built extraction tool at a stack of inconsistent, occasionally-wrong rent rolls and it will produce a fast, fluent, entirely plausible model built on the wrong numbers. The messiness that a careful analyst absorbs by hand becomes, under automation, fast and confident client-facing error.
There is one exception, and it is the capability worth caring about. The AI feature that addresses the actual root cause is the one that reduces the input chaos: reading a source document, mapping each figure to a model row, and — critically — showing the analyst exactly where every number came from so they can validate the handful that matter instead of re-keying all of them. That attacks the intake problem that caused the failure, rather than layering fluent output on top of it. The distinction between an automation that removes the mechanical work and one that merely produces a confident memo is the whole question, and it is why the honest framing treats the model as a workflow accelerator sitting beside your judgment rather than a replacement for it — the same distinction we draw in Argus versus AI-assisted underwriting. AI is a multiplier, and a multiplier applied to a broken intake multiplies the errors.
What an underwriting automation that survives looks like
An automation that lasts at a lean CRE firm inverts the usual order: fix the inputs and prove the outputs first, expand scope second. Four moves separate the systems that survive from the ones that get abandoned.
Start narrow. Automate the single most mechanical, most repeated step — usually rent-roll or T12 extraction into your model — and nothing else at first. A narrow tool that reliably does one thing earns trust and pays back quickly; a system that tries to do everything stalls before it does anything. Scope expands only after the first step is trusted.
Standardize the intake before the model touches it. Build a normalization step that turns whatever format a broker sends into a consistent structure the tool can read the same way every time. This is the unglamorous work that decides whether accuracy holds across deals, and it is exactly the step firms skip when they buy a demo instead of a workflow.
Make every output auditable. Require that each extracted figure links back to its exact source line, so the analyst validates rather than re-keys. Traceability is what converts a black box the team distrusts into a tool they actually use, and it is the single feature most worth insisting on when you evaluate anything.
Name one owner and validate on a schedule. Assign a principal or ops lead to spot-check outputs against source documents on a regular cadence, maintain the templates as new formats arrive, and decide when the automation is reliable enough to trust without a manual re-check. This is an afternoon of attention, not a headcount, and it is what keeps quiet error from creeping back in. The broader logic of screening more deals with a lean team — and where automation fits into it — runs through the CRE deal analysis playbook.
What it costs to get right
Cost tracks how much of the work you buy off the shelf versus build, and for most small firms the early answer is buy narrow. Treat these as market ranges and confirm current pricing with each vendor, since proptech pricing and features change quarterly.
| Investment | Typical market range | What it addresses |
|---|---|---|
| Off-the-shelf extraction subscription | Per-seat or per-document, low hundreds per month | Rent-roll and T12 extraction without a custom build |
| Team training to model fluency | roughly $2K–15K | Getting analysts prompting and validating AI outputs well enough to trust them |
| Narrow custom automation | roughly $25K–75K to build | One tuned step (extraction into your model) with traceability, once volume justifies it |
| Full deal-screening automation | roughly $75K–150K to build | An end-to-end pipeline, only when repeated volume pays back the scope |
For most firms the winning combination is a narrow off-the-shelf tool for the mechanical step plus getting the team genuinely fluent at validating its outputs, both of which sit well below a full custom build. A custom automation earns its cost only when the same underwriting workflow repeats at enough volume to pay back, and the model itself is the cheap part — connecting it to your data and existing tools is where most of the budget goes, a breakdown we walk through in what custom underwriting automation actually costs. The automation that survives is rarely the most ambitious one; it is the narrow, auditable one your analysts keep using because it earns their trust on every deal.
FAQ
Why do most underwriting automations fail?
Most underwriting automations fail because the firm points a precise model at imprecise inputs, over-scopes the build, and produces outputs the analyst cannot audit or trust. The base rate is stark: RAND puts the AI project failure rate above 80 percent, and Gartner has estimated that around 60 percent of AI projects will be abandoned through 2026 on inadequate data readiness. At a small CRE firm the cause narrows to non-standard rent rolls and T12s, a model that launders input errors into confident output, and no analyst willing to stake a recommendation on a number they cannot trace.
Is it the AI or the data that causes the failure?
It is overwhelmingly the data and the workflow, not the model. Language models are fully capable of mapping rent-roll lines and pulling trailing-twelve actuals; what they cannot do is fix inconsistent, occasionally-wrong source documents. Gartner attributes most abandoned AI projects to inadequate data readiness, which in CRE means the messy intake of differently-formatted PDFs. Fix the inputs and the traceability first, and treat the model as the last and cheapest piece.
What is the AI project failure rate?
The RAND Corporation puts the failure rate above 80 percent, roughly twice the rate of comparable non-AI IT projects, and reports that around 80 percent of enterprise AI projects fail to deliver their promised business value. Gartner has estimated that about 60 percent of AI projects will be abandoned through 2026 due to inadequate AI-ready data, and S&P Global found the share of companies scrapping most AI initiatives rose from 17 percent in 2024 to 42 percent in 2025. The exact figure matters less than the pattern: failure is the base rate, and data readiness is the near-universal cause.
Will AI make my underwriting more accurate?
Only if your inputs and your validation are sound; otherwise it makes you confidently less accurate. Manual entry from CRE documents carries an estimated 5-to-15-percent error rate, and an automation with no validation layer carries those errors straight into a clean-looking model that hides them. A human often catches an outlier because it looks wrong; a model does not. Accuracy improves only when you standardize the intake and keep a human validating the outputs against the source.
Should I automate the whole underwrite or just part of it?
Just part of it, at least to start. The most common failure is over-scoping — trying to automate ingestion, extraction, modeling, and memo-writing in one project a lean team cannot sustain. Automate the single most mechanical, most repeated step first, usually rent-roll or T12 extraction into your model, prove it earns trust, then expand. Narrow automations that reliably do one thing survive; end-to-end systems attempted all at once stall.
Why do analysts stop using underwriting automations?
Because they cannot see how the number was derived, so they re-key it by hand to check it, which erases the time savings, and then they abandon the tool. Underwriting is a judgment job, and no analyst will stake a recommendation on an unauditable black box. The fix is traceability: every extracted figure linked to its exact source line, so the analyst validates the few that matter instead of re-entering all of them. Adoption follows trust, and trust follows an auditable trail.
Can I just use Excel and ChatGPT instead of a custom build?
For many small firms, yes, as a starting point. A general assistant like ChatGPT or Claude paired with your existing model can accelerate extraction and drafting well enough to prove the value before you commission anything custom. The limits show up at volume and on validation: general tools do not enforce traceability or a standardized intake on their own, so you supply that discipline manually. When the same workflow repeats often enough that manual validation becomes the bottleneck, a narrow custom automation starts to pay back.
How do I know if my firm is ready to automate underwriting?
You are ready when you can name the one repetitive step worth automating, describe the standard format your inputs need to be in, and say who will own validating the outputs. If any of the three is unclear, automating first will just accelerate an unclear process into confident error. Readiness is less about budget than about having a defined workflow and a named owner, which is exactly what a short assessment is designed to surface.
Who should own an underwriting automation at a small firm?
One named person, usually a principal or an operations lead, should own the templates, spot-check outputs against source documents on a regular cadence, and decide when the tool is trustworthy enough to skip the manual re-check. This is not a full-time role; it is a recurring afternoon of attention plus the authority to set standards. The failure mode to avoid is treating the automation as everyone’s shared responsibility, which reliably makes it no one’s and lets quiet error creep back in.
Key takeaways
- Underwriting automations fail because of the data and the workflow, not the AI; RAND puts the AI project failure rate above 80 percent and Gartner ties most abandonments to inadequate data readiness.
- At a lean CRE firm the failure sharpens into five patterns: non-standard inputs, input errors laundered into confident output, an over-scoped build, a black box the analyst cannot trust, and no named owner.
- Bolting a model onto a broken intake makes underwriting worse, turning a messy-but-human-checked process into fast, confident, client-facing error.
- The automation that survives is narrow and auditable: automate one mechanical step, standardize the intake before the model touches it, link every output to its source line, and name one owner to validate on a schedule.
- Cost tracks buy-versus-build; a narrow off-the-shelf tool plus a fluent, validating team sits well below a full custom pipeline, which earns its cost only at repeated volume.
Not sure whether your firm needs a narrow off-the-shelf tool, a workflow fix, or a custom build — and which underwriting step to automate first? A short assessment answers that faster than any vendor demo, because your deal mix, document formats, and team decide the order of the work. Book your free AI-readiness assessment →
Arthur Wandzel
