Claude can read a borrower's full loan file — rent rolls, T12s, offering memorandums, appraisals — in a single pass and summarize it well, but loan underwriting document review doesn't fail because a single file was misread. It fails when the investor guidelines a file was reviewed against change mid-quarter, and nobody can say with confidence which files were checked against the old version and which against the new one.
That's a different problem than reading comprehension, and it's the one loan underwriting workflows built directly on a general assistant tend to run into once volume climbs past a pilot.
What Claude Does Well for Loan Underwriting Document Review
Claude brings real, verifiable capability to underwriting document review, and it's worth naming plainly.
- A 1M-token context window, standard on current frontier Claude models per Anthropic's documentation, can hold a rent roll, a T12, an offering memorandum, and an appraisal for a single deal in one pass, without fragmenting the file and losing a cross-reference between documents.
- Claude Skills can encode a set of investor guidelines — DSCR thresholds, LTV limits, non-standard clause flags — as reusable instructions an underwriter doesn't have to restate for every file.
- Connectors, including Anthropic's Microsoft 365 connector, can pull borrower documents directly from SharePoint or a shared mailbox under the underwriter's existing permissions.
- Claude Cowork can run a multi-step review task across a folder of loan files, producing a first-pass summary for each one while an underwriter works on something else.
Where a Volume of Files, Not One File, Breaks the Process
The failure pattern in self-built underwriting review shows up predictably as volume grows, and none of the points below are about Claude misreading a document.
- Around file 20, an investor updates its DSCR floor mid-quarter. The change reaches the underwriting team by email and gets folded into the next conversation's instructions, but the twenty files already reviewed under the old guideline aren't automatically flagged for re-check.
- Around file 60, a reviewer notices a rent roll figure that doesn't match the T12 for a file processed three weeks earlier. Determining how many other files in that window carry the same undetected mismatch means reopening each one — there's no record of which guideline version, or which instruction wording, was in force when that batch ran.
- Around file 120, the analyst who maintained the underwriting instructions moves to a different desk. The next person inherits the saved prompt but not the accumulated judgment calls — how to treat a below-market renewal option, which appraisal caveats matter — that shaped the last quarter's reviews.
- At file 300, a credit committee asks which guideline version a specific loan was underwritten against, and whether the reviewed figures were independently checked before the file moved forward. The summary exists. The guideline version and verification record behind it do not.
A better model doesn't fix any of this. The problem is that investor guidelines change on their own schedule, and nothing in a general assistant's document review ties a specific output to the specific guideline version that was supposed to govern it.
Why Guideline Versioning Is the Real Cost, Not Extraction Accuracy
The hard part of underwriting document review at volume isn't reading a rent roll correctly — Claude generally does that well. It's proving, months later, which set of investor guidelines a given file was checked against, and whether every field an underwriter relies on was verified rather than just generated.
Without a citation binding each extracted figure to its source page, and without a version record binding each review to the guideline set active that week, confirming a single file's underwriting means reconstructing both from memory or email threads. Across hundreds of files a quarter, that reconstruction cost is often larger than the review time the workflow was meant to save.
Who Owns the Guideline Logic, the Version History, and the Re-Validation
The investor guidelines encoded into your underwriting instructions are effectively your credit policy in software form, and in a self-built deployment they typically live in a prompt or Skill with no version history connecting a given review to the exact guideline wording active when it ran.
Two obligations follow from that. First, when guidelines change — which happens on the investor's schedule, not yours — someone has to update the instructions and decide whether previously reviewed files need re-checking; in practice, that decision is frequently made informally or not at all. Second, when the underlying model version changes, re-confirming that underwriting output is still accurate against current guidelines is scheduled work your team owns, not something the assistant verifies on its own.
Claude-Based Underwriting Review Compared With a Purpose-Built Platform
Both approaches can read a loan file accurately; the table below shows who owns guideline versioning, citations, and re-validation once review moves from one file to a quarter's volume.
| Requirement | Self-Built on Claude | Purpose-Built Platform |
|---|---|---|
| Reads a complete loan file accurately | Yes | Yes |
| Investor guideline version tied to each review | You build it | Built in |
| Flags non-standard lease or loan clauses | Instructed, not enforced | Built in, consistently applied |
| Field-level citation to source document | Instructed, not enforced | Enforced on every field |
| Re-check triggered by a guideline change | Manual, easy to miss | Trackable against versioned logic |
| Consistency across hundreds of files a quarter | Usually unmeasured | Validated independently |
| Re-validation when the model version changes | Your team | Vendor benchmarks and validates |
| Underwriter-ready output delivered to existing systems | Manual export | Structured push into existing systems |
| Audit record for a specific past file | You build it | Built in |
| Who owns the accuracy of the outcome | Your team | Shared with the vendor |
When Using Claude Directly for Underwriting Review Is the Right Choice
Claude, used directly, fits underwriting document review that stays occasional, single-deal, or fully reviewed by the person running it.
- One-off review of a complex deal. Reading a single borrower's full file in depth before a credit committee meeting is exactly what a large context window is built for.
- An individual underwriter's personal workflow. One person reviewing their own small pipeline, checking every output themselves, doesn't need cross-file guideline-version tracking.
- Testing a new guideline before rollout. Trying a revised DSCR or LTV rule against a handful of recent files before committing it to the full team is a reasonable, low-cost use of a Claude Skill.
- Low volume. Below a few dozen files a month, the infrastructure a purpose-built platform adds for guideline versioning and audit tracking often costs more than it saves.
The dividing line isn't how complex any single loan file is. It's whether a credit committee, a regulator, or an investor will eventually ask which guideline version governed a specific review — and whether the answer is a record or a reconstruction.
How Kolena Works
Kolena is an AI document automation platform built for lending and real estate finance teams running loan underwriting document review at volume. Kolena's agents read rent rolls, leases, offering memorandums, borrower financials, and appraisal and environmental reports for every file in your pipeline, extracting rent, escalations, expirations, and TI/LC terms, flagging non-standard clauses, and returning underwriter-ready summaries with every field cited to its exact source location.
Kolena pushes structured output into the systems teams already use, and every run produces a full audit trail — which investor guideline version was active, which figures were flagged, and what justified each value. Kolena also benchmarks leading models against real document tasks and routes each step to the best performer, so a model version change is validated before it reaches your underwriting workflow. Kolena is SOC 2 Type II certified, processes onshore, and does not train on customer data.
One private lending customer cut UCC filing review labor by 96% using Kolena this way, taking loan-file turnaround from roughly five days to hours — with every file checked against the guideline version that was actually current when it ran.
