Extract a T12 and Rent Roll Into Your Underwriting Model (Without Retyping) | NextAutomation

To get a T12 and rent roll into your underwriting model without retyping, you run four steps in order: let an extraction pass parse the property, tenancy, and financial fields out of the PDFs into a structured deal record, run that record through a completeness check that flags anything the extraction missed, map the fields into your own model on your own terms, and have a rule for what happens when a document is not there at all. AI compresses the typing hard. It does not remove the human read that decides whether the numbers are right.

This is the task operators hate most and mention first. Analysts at one firm we worked with previously spent 15 or more hours per deal re-keying property and rent-roll data before any real analysis started. A real-estate lending principal described his own week the same way: "80 percent of my time is data entry from loan docs into spreadsheets." This guide is the honest version of how to make that stop, including the one step that is not going anywhere.

A note on scope. This is the extraction workflow: docs in, a checked deal record out, into your model. It is one workflow over from screening the inbound deal, covered in our CRE deal screening playbook, and one step before turning that record into a committee document, covered in our guide to going from OM to IC memo with AI. If you want the whole underwriting pass decomposed, that lives in our breakdown of the CRE underwriting workflow, decomposed.

The Manual Baseline, in Operators' Own Words

The reason this workflow gets built first is that the manual version is the single most-hated task on the deal desk, and operators describe it in almost identical language.

A real-estate lending principal narrated his exact process, the cleanest description of the pain we have: "80 percent of my time is data entry from loan docs into spreadsheets. I read each PDF. I pull out the key data points: principal, interest rate, maturity date, amortization start, borrower covenants, prepayment terms. I type those into a spreadsheet." That is a principal, not a junior, spending the majority of his time transcribing documents by hand. On the acquisitions side the shape is the same: analysts at one firm previously spent 15 or more hours per deal re-keying property and rent-roll figures out of a T12 and a rent roll before they could underwrite anything. That is the prior state at that one firm, described by the people living it, not a measured cross-market average.

What matters in both accounts is what the time is spent on. It is not analysis. It is transcription: reading a number off a PDF and typing the same number into a cell. That is the part a machine should do, and the four steps below take it off a person's plate without pretending the judgment goes with it.

Step 1: Extract the Fields Into a Structured Deal Record

The first step turns the documents into data. You point the extraction at the attachment, a T12, a rent roll, a loan doc, an operating statement, and it parses the fields out into a single structured deal record instead of leaving them locked in a PDF.

Concretely, the extraction reads the attachment and pulls three families of fields. Property fields: address, asset type, unit or suite count, square footage, year built. Tenancy fields off the rent roll: tenant or unit, lease start and end, in-place rent, escalations, occupancy and vacancy. Financial fields off the T12 and operating statement: gross income line items, operating expense line items, net operating income, and the loan terms a lending principal reads by hand today (principal, interest rate, maturity date, amortization start, covenants, prepayment terms). Those land in named fields in a deal record, not in your model yet. This step's only job is to get the numbers out of the document and into a place a computer can reason about.

This is the step that replaces the transcription. The 15-plus hours of re-keying and the principal's "I type those into a spreadsheet" are exactly what the parse removes. What it does not do, and what the next step exists to catch, is guarantee it caught everything. That is why extraction is step one of four, not the whole workflow.

Step 2: Run the Completeness Check (Because AI Can Miss a Field)

This is the step most tool demos skip, and it is the one that makes the workflow safe to actually use. An extraction pass can misread a merged cell, transpose a number, or miss a field entirely, especially on a scanned rent roll or a non-standard T12 layout. If you feed that straight into a model, you have automated a mistake. So you do not.

Instead, the extracted record runs through a completeness checklist before anyone trusts it. The check is a fixed list of the fields a deal of this type must have, and it flags anything the extraction did not populate or populated with something that fails a basic sanity test: a rent roll with no lease-end dates, a T12 missing an expense category, a NOI that does not reconcile to the income and expense lines it was built from. Each flag is a specific thing for a person to look at, not a vague warning.

This is the honest backstop, and it is deliberate. The AI parses; the checklist catches what the parse missed; a human resolves the flags, reviewing them against the source document before the record is considered clean. That review is not overhead to be optimized away, it is the point of the step. Anyone selling you extraction with no review layer is selling you a faster way to be wrong. The realistic model is that the machine does the reading and typing while the person spends their time only on the handful of fields the checklist raised, instead of re-keying all of them.

Step 3: Map the Fields Into Your Underwriting Model

A clean deal record is not yet an underwrite. Step three is where the extracted, checked fields land in your model, the one you already trust, on your own terms.

The mapping is the deliberate part: each field in the deal record points to a specific input cell or line in your underwriting template, whether that is a spreadsheet or one of the dedicated multifamily underwriting software platforms. In-place rent from the rent roll maps to your rent-roll tab. The T12 expense lines map to your operating-expense assumptions. Loan terms map to your debt inputs. Because the record is structured and named, this is a defined wiring job, not another round of copy-paste, and once it is set for a template it holds for every future deal that uses it. The extraction fills your model; it does not replace it. Your assumptions, your growth rates, your underwriting logic all stay yours.

This is also where the boundary between transcription and judgment shows up cleanly. The extraction supplies the in-place, historical facts off the documents. What you do with them, the market rent you underwrite to, the exit cap you assume, the renovation you model, is analysis, and it stays with you. The workflow is not trying to do your underwriting. It makes sure that when you sit down to underwrite, the facts are already in the model and correct, so your time goes to the decision instead of the data entry.

Step 4: Handle Missing Documents (the Real Question)

One question comes up more than any other when operators think this through, and it is worth quoting directly, typos and all, because it is the real one: "ok when dokuments are missing for eg.. from a client. where does it show for me then? in my crm tool? i dont get it." Extraction assumes the documents exist. Half the time, on a real deal, one of them does not yet.

The answer is that a missing document is just a special case of the completeness check from step two. If a deal needs a T12 and a rent roll and only the rent roll came in, the check does not silently proceed on half the data. It flags the whole document as missing, in the same place every other flag shows up, the deal record itself, so the gap is visible on the deal rather than discovered three days later when a number will not compute. You see "T12: not provided" next to the fields it would have populated.

From there it is your call, and the workflow makes the call obvious rather than making it for you. You can hold the record as incomplete and go back to the broker or client for the missing file, or proceed on partial data with the gap explicitly marked so no one downstream mistakes an empty field for a zero. The missing document surfaces as an early, named flag on the deal, not a silent hole in your model. That is the honest answer to "where does it show for me then": on the deal record, at intake, before it costs you anything.

The Same Pipeline Works Across Asset Types

A fair question at this point is whether this is a multifamily trick or a general one. The extraction-plus-check architecture ports across multifamily, retail, and office. What changes between them is the completeness checklist and the field weights, not the pipeline.

A multifamily rent roll is unit-level with short residential leases; a retail rent roll is tenant-level with recoveries, CAM, and percentage rent; an office rent roll carries longer leases, tenant-improvement and free-rent terms, and different escalations. The extraction reads whichever it is given, and the completeness checklist for that asset type defines which fields must be present. Retail's check demands recovery and CAM fields a multifamily check would never ask for; office's check demands lease-term and TI detail. The pipeline, extract into a structured record, run the completeness check, resolve the flags, map into the model, is identical in all three. You reconfigure the checklist per asset type, not the workflow.

One honesty note so this is not oversold. The architecture ports; a specific time saving does not transfer with it. How much a given firm saves depends on their document quality, their template, and how much cleanup their inputs need, so treat any single before-and-after number as that one firm's result, not a benchmark you will hit. What ports is the method: the same four steps, retuned for the asset class in front of you.

Frequently Asked Questions

How do I extract a T12 and rent roll into my underwriting model?

Run four steps. First, an extraction pass parses the property, tenancy, and financial fields out of the PDFs into a structured deal record. Second, a completeness checklist flags anything the extraction missed, and a person reviews the flagged fields against the source document, because AI can miss a field. Third, the checked fields map into the input cells of your own underwriting template, which you keep. Fourth, if a document is missing, it surfaces as a flag on the deal record at intake rather than a silent gap. The extraction removes the retyping; your model and your assumptions stay yours.

Is the extraction accurate enough to trust without checking it?

No, and no honest version of this claims otherwise. An extraction can misread a merged cell, transpose a figure, or miss a field, especially on a scanned or non-standard document. That is exactly why the workflow includes a completeness check that flags gaps and a human review of those flags before the record is trusted. The benefit is not that the machine is never wrong, it is that a person only checks the handful of fields the checklist raises instead of re-keying every field by hand.

What happens when a document is missing from the deal?

A missing document is handled as a completeness flag. If a deal needs a T12 and a rent roll and only one arrives, the deal record shows the missing document explicitly, in the same place all other flags appear, at intake. You then decide whether to hold the record as incomplete and request the missing file, or proceed on partial data with the gap clearly marked so an empty field is never mistaken for a zero. The gap shows up on the deal itself, early, not as a silent hole discovered later in your model.

Does this only work for multifamily, or also retail and office?

The pipeline works across multifamily, retail, and office. What changes per asset type is the completeness checklist and the field weights, not the workflow. A retail rent roll carries recoveries, CAM, and percentage rent; an office rent roll carries longer leases and tenant-improvement terms; a multifamily rent roll is unit-level with short leases. The extract, check, resolve, map sequence is the same in all three. You reconfigure the checklist for the asset class, not the pipeline. Note that a specific time saving does not port with the architecture, since it depends on each firm's document quality and template.

Does the AI do my underwriting for me?

No. The workflow supplies the in-place, historical facts off the documents, correctly, into your model. It does not set your assumptions. Market rent, exit cap, growth rates, renovation scope, and the underwriting logic stay with you. The goal is that when you sit down to underwrite, the data entry is already done and checked, so your time goes to the decision rather than the transcription. It fills your model; it does not replace your judgment.