What is an AI deal database? An AI deal database is a structured, searchable archive of every deal your firm has underwritten, whether you closed it or passed, organized so an AI assistant can answer questions about your own transaction history in seconds. Building an AI deal database CRE investors will actually use is less a software purchase than a data decision: you pick the fields that matter, extract them consistently from work you have already done, and put the result somewhere a model can search. For the wider tooling landscape, see our guide to AI tools for real estate investors.
Most firms already own the raw material. A sponsor buying for a decade has typically underwritten several hundred deals and closed a few dozen. The ones you passed on are the most honest dataset your firm owns, because they record what the market was asking and what you were willing to pay. They are also, at most firms, completely unqueryable.
Key Takeaways
- An AI deal database indexes deals you already underwrote, including the ones you passed on, which is the dataset most CRE firms own and never use again.
- It is not a CRM and not a pipeline tracker. Those manage deals in motion; a deal database answers questions about deals that are already over.
- Value comes from a consistent field schema of roughly 20 to 30 fields per deal, not from the volume of documents you dump into a shared folder.
- Use AI twice: once to extract fields from old models and offering memorandums, and again to answer plain-English questions across the finished archive.
- The single most valuable field is the one nobody records: a controlled reason code explaining why you passed.
What an AI Deal Database Is (and What It Is Not)
An AI deal database is a retrospective system. It stores the finished record of every deal your firm evaluated so a model can search that record later. A CRM stores people; a pipeline tracker stores deals in motion. Both are forward-looking tools for work that has not happened yet. A deal database is institutional memory.
The distinction matters because most firms try to make the CRM do this job and quietly fail. A CRM record for a dead deal is usually a status field set to "Lost" and a one-line note, which tells you nothing six months later when the broker calls back with the same asset at a new price. What you need is the number you bid, the going-in cap rate it implied, the exit cap you assumed, and the reason you stopped. None of that survives in a status field. If your problem is deals in motion instead, our guide to the end-to-end AI deal pipeline for CRE covers the sourcing-to-asset-management handoffs; the two systems are complements.
CBRE makes this argument at institutional scale, describing decades of proprietary transaction data as an asset that becomes far more powerful once AI can surface it on demand (CBRE, The Intelligence Advantage). A ten-person sponsor will not match that volume and does not need to. It needs its own history in the three submarkets it actually buys in.
The Fields That Make Past Deals Queryable
A deal becomes queryable when it is reduced to a consistent row of about 20 to 30 fields. Fewer and you cannot ask useful questions; many more and nobody maintains it. The schema below is a working starting point.
Identity, timing, and source: property name, address, submarket, property type, year built, unit count or rentable square feet, date the deal arrived, broker or source, and outcome. Submarket and year built do most of the filtering work. Outcome should be a controlled list rather than free text: closed, passed pre-LOI, LOI submitted and lost, retraded and dead, seller withdrew.
Pricing: asking price, your bid, the winning price if you ever learned it, price per unit or per square foot, the seller's stated cap rate, and the going-in cap rate on your own numbers. Keep those last two separate. Cap rate is NOI divided by purchase price and excludes debt service entirely, so a broker's cap rate computed on pro forma NOI and yours computed on trailing performance are different numbers describing the same asset.
Underwriting assumptions: in-place NOI, your year-one NOI, T12 operating expense ratio, rent growth assumption, exit cap rate, projected IRR, projected equity multiple, and DSCR at the debt terms you quoted. DSCR is NOI divided by annual debt service and is expressed as a multiple such as 1.25x, so store it as a number, not a percentage.
Reason code: one field, controlled vocabulary, why you stopped. Price, physical condition, submarket, insurance cost, debt terms, sponsor capacity, seller unrealistic, lost to a higher bid. This field turns an archive into an argument. After 200 rows you can see whether you are a disciplined buyer or whether you have been losing on price for two years while telling yourself the assets were tired.
Extracting the Schema From Deals You Already Underwrote
Do not backfill ten years. Start with the last 24 months, which for most firms is 60 to 150 deals. That window is where your assumptions are still relevant and the source files are most likely intact; if it proves useful, extending backward is a weekend of work.
The extraction is well suited to AI. For each deal, give the model the underwriting model and the offering memorandum, hand it your field list including the controlled vocabularies, and ask for a single row of CSV or JSON with one value per field and the literal string UNKNOWN wherever the source does not say. That last instruction matters more than it sounds: without it, models fill gaps with plausible numbers, and a fabricated exit cap rate is worse than a blank one.
Two guardrails make the batch trustworthy. Require the model to name the worksheet tab and cell label behind each number, because multi-tab Excel models and Argus exports use merged cells and stacked headers that trip up extraction, and a citation lets you spot-check in seconds. Then hand-verify roughly one row in ten. The error you are hunting is not random noise but a systematic misread, such as the model consistently grabbing stabilized year-three NOI when you asked for year one.
Claude, ChatGPT, and Gemini all handle this extraction workload competently. If your deal team already works in a shared workspace, the step fits alongside the setup in our walkthrough on building Claude Projects for CRE deal teams.
Where the Database Should Live
Use two layers. A structured table holds one row per deal and answers filtering and math questions; a document layer holds the underlying files so you can drill into any row. Trying to make one tool do both is the most common reason these projects stall.
- Spreadsheet plus AI: Google Sheets or Excel with a connected assistant. Free, immediate, and genuinely sufficient below a few thousand rows. Start here unless you have a reason not to.
- Airtable or a light database: worth the step up once multiple people write to the table, because you get enforced field types and controlled dropdowns. Dropdowns are what keep the reason code field from degrading into free text within a quarter.
- Claude Projects for the document layer: Anthropic's documentation states that retrieval augmented generation activates automatically when a project approaches or exceeds its context window limit, letting a project hold up to 10 times more content with no setup required, across all Claude plans (Claude Help Center). That is what makes a multi-year archive searchable rather than truncated.
- NotebookLM: caps sources per notebook by plan tier, making it excellent for interrogating one deal folder and the wrong choice for a 400-deal archive. Our guide to NotebookLM for CRE due diligence covers that single-deal case.
- Purpose-built deal platforms: Dealpath and Buildout maintain structured deal records, but they capture deals you enter going forward. They do not reach backward into the archive you already have.
Debt shops can adapt the same two-layer pattern to lender and quote history, which we cover in our guide to building a Claude Project for CRE debt broker deal flow. The schema changes; the structure does not.
The Questions a Good Deal Database Answers
The test of a finished archive is speed. If you cannot answer the following in under a minute, the database is not done. Each maps directly to fields in the schema above.
- What is the highest going-in cap rate we have bid on 1980s vintage garden apartments in this submarket, and when?
- How many deals did we pass on for insurance cost in the last eight quarters, and where were they?
- Which broker has sent us the most deals, and what is our LOI rate on their listings versus everyone else's?
- What exit cap rate were we assuming eighteen months ago on assets like this one, and how far has that drifted?
- What is our median projected IRR on closed deals versus deals we passed, and does the spread justify our screening bar?
That last question is the one that changes behavior. Firms routinely discover their pass decisions cluster in a narrower price band than they believed, which is useful when a partner insists the team is being too conservative. If you want the schema designed against your own deal history rather than a generic template, The AI Consulting Network works with CRE operators on exactly this kind of internal data project.
Frequently Asked Questions
Q: How many past deals do I need before this is worth building?
A: Roughly 50 rows is where pattern questions start returning useful answers, and 150 to 200 rows is where reason-code analysis becomes genuinely informative. Below about 30 deals you can still just remember them, and the build is not worth the effort.
Q: Can AI extract fields accurately from old Excel underwriting models?
A: Usually yes for clean single-tab models, less reliably for multi-tab models with merged cells or Argus exports. Require a tab and cell citation for each value, instruct the model to output UNKNOWN rather than guess, and hand-check one row in ten. The failure mode is systematic misreads, not random errors, so a small sample catches most problems.
Q: Should the database include deals we never formally underwrote?
A: Yes, with a thin record: property, submarket, source, asking price, date, and a reason code. Flag them so they do not pollute the assumption-level analysis. For hands-on help standing this up, CRE investors can reach out to Avi Hacker, J.D. at The AI Consulting Network.