AI to extract commercial real estate documents to Excel

AI extraction of flyers and landlord proposals into Excel works best when the destination is the survey workbook your team already sends to clients. A model reads each flyer and landlord proposal into a fixed list of fields, code writes those fields into the workbook, and the same facts are queued for the CRM where a person approves them before anything is saved.

The design starts from the assumption that your Excel survey is the thing the client recognizes, and that the job is to fill it. Nothing about the team's process has to move onto a new product for that to work.

The same facts typed twice

A tenant rep assignment produces a pile of documents early on. There are flyers for every building on the long list, then landlord proposals for the short list. Someone on the team, often the coordinator, reads each one and types the address, suite, square footage, rate, term, and concessions into the survey workbook. Then the same person, or a broker late in the day, types many of the same facts into the CRM as availabilities, contacts, and deal notes.

The facts are read once by a person and typed twice. Each retyping is a chance for a suite number or a rate to drift, and the two destinations slowly stop agreeing with each other. The design below reads each document once and sends the result to both places.

Start with the workbook you already send clients

Your survey has columns in a particular order, a particular way of showing rates, and formulas that calculate things like annual rent or effective rate. Clients have seen it before and brokers know where to look. All of that is worth keeping.

So the first working session is spent with the workbook open. We mark which cells are inputs that come from documents, which are formulas, and which are judgment calls a broker writes by hand, such as a comment on the building. Only the first group belongs to the workflow.

Write the schema once

The schema is the list of fields the model must return for every space, and it mirrors the workbook's input columns one for one. It is written once with the team and then held fixed. The table below is an example of what a tenant rep team's schema might contain. Yours will follow your own columns.

Field	What is recorded	Note
Address and suite	As printed on the document	One row per suite
Square footage	The number and whether it is stated as rentable or usable	Flag if the document does not say
Rate	The number, the period (per year or per month), and the basis	Flag if the basis is not stated
Escalations	Percent or fixed step, and how often
Tenant improvement allowance	Amount and unit	Proposals usually have it, flyers usually do not
Free rent	Months, and whether inside or outside the term
Term	Length and commencement date if given
Operating expenses	Amount, year, and what is included
Parking	Ratio and cost
Availability date	As stated
Landlord contact	Name, firm, phone, email	Also feeds the CRM

Every field also carries two companions: where in the document the value was found (file and page), and a status that can read "not stated" or "conflict". Those two companions are what make the output reviewable.

What flyers and proposals get inconsistent

The fields that cause trouble are the ones where the number is easy to read and its meaning is not.

• Rate basis. One flyer quotes a full service rate, the next quotes triple net, and a third prints a number with no basis at all. Two rates on different bases cannot be compared until someone adds or removes expenses.
• Square footage. Rentable and usable area are different measurements. BOMA's guidance on its floor measurement standards describes occupant area as leased on its rentable area, which includes an allocation of service and amenity areas by application of a load factor. A flyer that prints one number without a label leaves the reader guessing which one it is.
• Dates and periods. Availability may be a date, "immediate", or "30 days notice". Rates may be annual or monthly.
• Two documents, two answers. The flyer and the later proposal for the same suite can disagree, because the proposal reflects terms offered to this tenant and the flyer is the general asking position.

The rule we build in is that the workflow records the basis as the document states it, flags the field when the document is silent, and never converts silently. If the team wants every rate shown on a common basis, that conversion lives in the workbook as a visible formula with assumptions a broker entered.

How does every value keep its source?

The model's job is narrow. It reads one document and returns the schema, with a page reference for each value and "not stated" where the document does not say. It does not guess a rate basis from the submarket or fill in a parking ratio from another building.

When a flyer and a proposal disagree, both values are kept with their sources and the field is marked as a conflict for a person to resolve. This is the same discipline we describe for lease abstraction: a value the reviewer can trace to a page is a value the reviewer can trust or correct quickly.

How do you fill the workbook so formatting and formulas survive?

The workbook should be written by code that places each value in a named cell or a table row. The model should not retype the spreadsheet. A model asked to reproduce a workbook can rebuild it differently from one run to the next, and formulas, column widths, and conditional formatting are the things most at risk.

Anthropic's guidance for writing skills makes the same point in general terms. It lists the benefits of pre-made scripts as being more reliable than generated code and ensuring consistency across uses, and it recommends having the model produce a structured plan file that a script validates before the changes are applied, a pattern it suggests for batch operations. Applied here, the extracted schema is the plan file. A script checks it (required fields present, numbers that are numbers, every flag surfaced) and only then writes.

Because the script writes only to input cells, the formula columns and the layout are untouched. The broker opens a workbook that looks like the last one, with flagged cells highlighted for attention.

The CRM as a second destination, with an approval queue

The same schema holds most of what the CRM wants: the building, the suite, the asking terms, the landlord's contact. The difference is in how errors show up. A wrong cell in a survey sits in front of a broker who is about to send it to a client. A wrong field in the CRM, or a duplicate contact, has no such reader, and it can mislead whoever pulls that record later.

So the CRM gets a queue. The workflow proposes new records and changes to existing ones, each shown beside the current value and the source page, and a person approves, edits, or rejects them. Matching to existing records (is this the same building, the same landlord rep) is proposed by the workflow and confirmed by the person. We cover the general design of this step in how to design the human review step in an AI workflow.

How the connections work

There are two connections, and both use accounts your firm already controls.

The workbook, through Microsoft 365. Microsoft's Graph API lets an application read and modify Excel workbooks stored in OneDrive for Business, a SharePoint site, or a group drive, including adding a row to a table and updating a specific range. The same page states the limits that matter for planning: older .xls files are not supported, workbooks in consumer OneDrive are not supported, and writing requires the Files.ReadWrite permission granted through Microsoft's identity platform. It also notes that when a null is sent for a cell in an update, no change is made to that cell, which is how a script can update some cells in a range and leave the rest as they were.

The CRM, through a connector. The Model Context Protocol is an open-source standard for connecting AI applications to external systems. In Claude, a custom connector links the workspace to a remote MCP server, which can be one your CRM vendor provides or one built against the CRM's API. Anthropic's help article says Claude can only access resources you have given the server permission to access, and it advises connecting only to trusted servers, reviewing requested permissions carefully, and reviewing tool approval requests before allowing them.

One detail from that article deserves a decision early. When a connector on a Team or Enterprise plan uses a fixed credential such as an API key instead of each person signing in, everyone who uses the connector reaches the service with that same credential. For a CRM, that affects whose name appears on a change and what each person can see, so settle it with whoever administers the CRM. Our article on AI agent permissions and governance goes further into read, write, and send permissions. If your firm has client confidentiality terms that cover deal documents, confirm the setup with your compliance lead or counsel.

Comparing proposals side by side

Once every proposal sits in the same schema, the comparison tab is mostly a matter of layout. Each proposal becomes a column, each term a row, and the cells where a landlord was silent are visibly empty instead of quietly blank. Rounds of counterproposals can be added as new columns with the changed terms marked.

The analysis on top of that (effective rate, total occupancy cost, which concession is worth more to this client) remains the broker's work, done with the formulas the team already trusts.

What it takes to build, and when it is worth it

This is integration work, and the first build takes real setup. The schema has to be argued over with the people who use the survey. The extraction has to be tested against a stack of your actual flyers and proposals, including the ugly scanned ones, and corrected until the flags fire where they should. The workbook may need named ranges or a table added so the script has stable places to write. The CRM connection needs someone with admin rights and a view on permissions.

It pays back only for work the team repeats. A team that builds a survey for most new assignments and updates the CRM after every one will use this weekly. A team that does two surveys a year will not recover the setup effort, and a simpler aid, such as a skill that drafts the rows for a person to paste, may be the better fit. If you want to walk through your own workbook and see which case you are in, get in touch.

Common questions

Can AI fill in an Excel template from a PDF?

Yes, if the work is split in two. A model reads the PDF into a fixed list of fields, and code writes those fields into named cells or table rows in your template. Asking a model to retype the whole spreadsheet puts the formatting at risk and can give a different result from one run to the next.

Will AI keep my spreadsheet formatting and formulas?

They are kept when the write is done by code that touches only the input cells. Microsoft's Graph API for Excel updates specific ranges and adds table rows in a workbook stored in OneDrive for Business or SharePoint, and its documentation says a null sent for a cell leaves that cell unchanged. Formula columns, column widths, and branding are left alone because nothing writes to them.

Can AI update my CRM from deal documents?

It can, through a connector to the CRM, and we recommend that it proposes changes to a queue instead of writing directly. A person sees each new record and each changed field next to the document it came from and approves or rejects it. A wrong CRM field is much harder to spot later than a wrong cell in a survey.

How do I compare lease proposals with different rate structures?

Record each rate with its basis exactly as the proposal states it (full service, modified gross, or triple net) and flag any proposal that does not say. Any conversion to a common basis should be a visible formula in your workbook using assumptions a broker entered, so the client can see what was stated and what was calculated.

Do I need new software to automate survey workbooks?

Usually you do not. The workbook can stay in Excel in your firm's Microsoft 365, and the CRM stays the CRM you already run. What gets built is the schema, the extraction step, the script that fills the workbook, and the approval queue.