The commercial real estate industry has access to more data, better models, and faster computers than at any point in history. Yet underwriting a typical acquisition still takes two to three weeks. Development deals take longer. Complex portfolios can stretch into months.
This timeline has barely changed in two decades. The natural question is why. The answer reveals a fundamental misunderstanding about where time actually goes in underwriting, and points toward a solution that most firms have not yet implemented.
Where the Time Actually Goes
Ask a principal why underwriting takes three weeks and you will hear about complexity, judgment, and the need for thoroughness. These explanations are partially true but mostly misleading. The actual time allocation tells a different story.
Activity | Time Allocation | Value Created |
|---|---|---|
Waiting for documents | 20-30% | None |
Finding and organizing documents | 10-15% | None |
Extracting data from documents | 25-35% | Low (mechanical task) |
Entering data into models | 10-15% | None |
Reconciling conflicting information | 10-15% | Medium (identifies issues) |
Actual analysis and judgment | 10-20% | High |
The numbers vary by deal and firm, but the pattern is consistent: the majority of elapsed time goes to activities that create little or no value. Document wrangling, data extraction, and manual entry consume more hours than actual thinking.
This is not a people problem. Analysts and associates are not slow or inefficient. They are doing mechanical work that should not require human attention but has no alternative path. The constraint is not talent. It is workflow architecture.
The Document Problem
The root cause is that CRE due diligence operates on documents, not data. A typical acquisition data room contains 200 to 500 documents. A complex deal can exceed 1,000. These documents arrive as PDFs, scanned images, Excel files, and Word documents in no standard format.
Each document contains information the underwriter needs, but that information is trapped in prose, tables, and exhibits that must be read, interpreted, and manually transferred into usable form.
Document Type | Typical Count | Information Required | Extraction Challenge |
|---|---|---|---|
Rent rolls | 1-4 | Tenant details, rents, terms, occupancy | Table formatting varies; footnotes critical |
Leases | 10-100+ | Base rent, escalations, options, restrictions | 40-80 pages each; terms scattered throughout |
Amendments | 10-50+ | Modified terms, effective dates | Must reconcile with original lease |
Operating statements | 3-5 | Revenue, expenses by category, NOI | Non-standard chart of accounts |
Estoppels | 10-100+ | Tenant confirmations of lease terms | May conflict with lease documents |
Third-party reports | 5-15 | Environmental findings, building condition, appraisal | Technical content; materiality assessment needed |
Loan documents | 5-20 | Terms, covenants, prepayment provisions | Complex provisions; amendment tracking |
Miscellaneous | 50-200+ | Varies | Often unclassified; relevance unclear |
An analyst facing this document set must first figure out what they have, then read the relevant documents, then extract the specific data points needed, then enter those data points into a model, then go back to the documents when something does not reconcile.
This process is repeated for every deal. The institutional knowledge gained from processing one rent roll does not help with the next one from a different seller using a different format.
The Reconciliation Problem
Even after data is extracted, underwriting cannot proceed until conflicting information is resolved. Every experienced CRE professional knows that documents within a single deal regularly contradict each other.
Common Conflict | Documents Involved | Frequency | Impact |
|---|---|---|---|
Square footage discrepancy | OM vs. rent roll vs. lease | Nearly universal | Affects rent PSF calculations, valuation |
Occupancy rate discrepancy | OM vs. current rent roll | Very common | Affects revenue assumptions |
Lease term remaining | OM vs. lease vs. estoppel | Common | Affects rollover risk, valuation |
Base rent amount | Rent roll vs. lease vs. estoppel | Common | Direct revenue impact |
Expense responsibility | OM summary vs. lease detail | Common | Affects NOI calculation |
Option terms | Lease vs. amendment summary | Common | Affects lease-up assumptions |
In a traditional workflow, these conflicts are discovered when the analyst finds a number that does not match their earlier note, then spends time hunting through documents to find the source of the discrepancy, then makes a judgment about which source to trust (or flags for senior review).
This reconciliation work is essential, but the discovery process is inefficient. The analyst might not find a conflict until deep into the underwriting when a number fails to tie, at which point they must backtrack. Some conflicts are never found at all, flowing into the model as undetected errors.
The Model Population Problem
Once data is extracted and (partially) reconciled, it must be entered into the firm's underwriting model. This step introduces additional friction and error.
Friction Source | Description | Consequence |
|---|---|---|
Format mismatch | Extracted data format differs from model input format | Manual transformation required |
Unit inconsistency | Some sources show monthly rent, others annual; some show PSF, others absolute | Conversion errors possible |
Timing mismatch | Documents show point-in-time data; model requires assumptions about future | Judgment embedded in data entry |
Schema differences | Firm's expense categories differ from seller's chart of accounts | Line-item mapping required |
Model version management | Multiple model iterations as assumptions change | Risk of using wrong data in wrong version |
The analyst serves as a human translation layer between documents and models. They read the document, interpret the relevant field, convert it to the appropriate format, and enter it into the correct cell. Each step is an opportunity for error.
The Actual Solution
The solution is not faster analysts, better training, or more hours. The solution is removing humans from the mechanical path entirely. This requires a document intelligence infrastructure with four capabilities operating in sequence.
1. Large-Scale Document Ingestion
The system must ingest entire data rooms automatically. This means connecting to data room platforms, downloading documents as they appear, and processing documents without manual initiation.
Ingestion includes classification: identifying what type of document each file is, which property or entity it relates to, and how it fits into the deal structure. A rent roll for Building A must be distinguished from a rent roll for Building B. An amendment must be linked to its parent lease.
Ingestion Capability | What It Enables |
|---|---|
Data room connection | Documents flow in automatically; no manual download |
Document classification | Each document typed and categorized without human triage |
Entity resolution | Documents linked to correct property, tenant, or deal entity |
Version tracking | Superseded documents identified; current versions prioritized |
Completeness monitoring | Missing documents identified against expected document set |
The result: instead of an analyst spending hours downloading, organizing, and categorizing documents, the system presents an organized, classified document set ready for processing.
2. Standardized Value Extraction
The system must extract structured data from each document according to document-type-specific schemas. A rent roll schema extracts tenant name, suite, square footage, lease dates, rent, and escalations. A lease schema extracts those same fields plus options, restrictions, and dozens of additional provisions.
Standardization is critical. The extracted data must conform to a consistent format regardless of how the source document was structured. Monthly rents become annual rents (or vice versa, per firm preference). Square footage becomes a number, not "approximately 5,000 SF" or "5,000 +/- SF." Dates become dates, not "five years from commencement."
Standardization Type | Raw Input Example | Standardized Output |
|---|---|---|
Rent normalization | "$4,500/month" vs. "$54,000/year" vs. "$18.00 PSF" | All converted to firm's standard (e.g., $/SF/year) |
Date normalization | "5 years from commencement" vs. "through December 2029" | Explicit date calculated from context |
SF normalization | "Approximately 10,000 SF" vs. "10,000 RSF" vs. "9,850 USF" | Numeric value with SF type notation |
Entity normalization | "ABC Corp" vs. "ABC Corporation" vs. "ABC Corp, Inc." | Standardized entity name with aliases tracked |
Percentage normalization | "3% annual increases" vs. "CPI" vs. "Fair market" | Categorized escalation type with specific values where applicable |
The result: instead of an analyst reading documents and typing values into spreadsheets, the system produces structured data tables ready for analysis.
3. Cross-Document Reconciliation
The system must compare extracted data across documents and surface conflicts automatically. When the rent roll shows $25.00 PSF and the lease shows $24.50 PSF, that conflict must be detected and surfaced before it flows into the model.
Reconciliation operates at multiple levels:
Reconciliation Level | What Is Compared | Conflict Example |
|---|---|---|
Internal consistency | Values within a single document | Rent roll total does not equal sum of rows |
Cross-document consistency | Same field across multiple documents | Lease term differs between rent roll and lease |
Temporal consistency | Same field across time periods | Current rent roll shows different tenant than prior month |
Benchmark consistency | Extracted values vs. market norms | Expense ratio significantly below market average |
Each conflict is captured in a variance register with full context: which documents conflict, what values each shows, and a materiality assessment based on the magnitude of the discrepancy and the field's importance.
The result: instead of an analyst discovering conflicts mid-analysis and backtracking to investigate, the system presents all material conflicts upfront for resolution before modeling begins.
4. Model Transformation
The final step transforms standardized, reconciled data into the firm's proprietary underwriting models. This is not a simple copy-paste. It requires mapping extracted data to model inputs according to the firm's specific conventions.
Transformation Requirement | Description |
|---|---|
Schema mapping | Firm's expense categories may differ from seller's; system maps line items |
Calculation application | Some model inputs require calculation from extracted data (e.g., weighted average lease term) |
Assumption integration | Extracted actuals must be distinguished from forward assumptions |
Format compliance | Data formatted to match model cell specifications |
Audit trail preservation | Model inputs linked back to source documents for verification |
The result: instead of an analyst manually populating a model cell by cell, the system produces a populated model with inputs traced to sources, ready for assumption refinement and analysis.
What Changes
When this infrastructure operates, the underwriting timeline compresses dramatically, but more importantly, the nature of the work changes.
Phase | Traditional Process | With Document Intelligence |
|---|---|---|
Document receipt | Manual download and organization | Automatic ingestion and classification |
Data extraction | Analyst reads and transcribes | Automated extraction with human verification of exceptions |
Reconciliation | Ad hoc discovery during modeling | Systematic comparison with variance register |
Model population | Manual data entry | Automated population with audit trail |
Analysis and judgment | Squeezed into remaining time | Becomes the primary focus |
The two-to-three week timeline becomes days. More importantly, the composition of that time shifts. Analysts spend their hours on judgment calls (which assumptions to use, how to interpret conflicting information, what risks matter) rather than mechanical transcription.
Why Most Firms Have Not Done This
If the solution is clear, why does underwriting still take weeks at most firms?
Barrier | Description |
|---|---|
Implementation complexity | Building this infrastructure requires integration with data rooms, document processing capability, firm-specific configuration, and model connectivity |
Data room fragmentation | Every deal uses a different data room platform with different access methods |
Document variability | No two sellers format documents identically; the system must handle variation |
Firm-specific requirements | Every firm has different models, different terminology, different workflows |
Change management | Moving from manual to automated workflows requires process redesign, not just software purchase |
Initial data migration | Benefiting from historical patterns requires ingesting past deals, not just future ones |
These are real barriers. They explain why adoption remains concentrated at firms with sufficient scale, capital, and technical capacity to make the investment. But they are implementation challenges, not fundamental obstacles. The technology exists. The question is organizational commitment to deploying it.
Conclusion
CRE underwriting takes weeks not because deals are complex but because document processing is manual. Analysts spend the majority of their time on mechanical work that creates little value: downloading, organizing, extracting, entering, and reconciling data from hundreds of documents. The fix is infrastructure that automates this mechanical path: ingesting documents at scale, extracting standardized values, reconciling conflicts across sources, and transforming the result into firm-specific models. The technology to do this exists today. Firms that deploy it will underwrite faster, with fewer errors, while focusing human attention on the judgment that actually determines investment outcomes. Firms that do not will continue losing weeks to work that machines should do.