AI for data entry in real estate: keeping the rent roll honest

A renewal completes on a Friday. The executed document says the term starts on the first day of the month and the rent steps partway through. The deal summary circulated a fortnight earlier says something different about the step, because the figure moved in the final round of negotiation and nobody amended the summary. An administrator has both files open and a property management system that wants a single answer. Whichever version gets keyed becomes the truth, and the other document sits in the folder being wrong.

That is the desk this article is about: the people who make three or four systems reflect decisions taken elsewhere, by typing. The property management system, the accounting ledger and the CRM each hold their own version of the same tenant, unit and obligation, and none were designed to tell the others when something changed.

The rent roll is assembled by retyping

Almost everything a property business believes about itself is downstream of manual keying. The rent roll, the arrears report, the service charge budget, the lender report and the valuation pack are all drawn from records somebody typed out of a document.

The defining feature of errors here is their delay. A term commencement keyed a month early, an indexation basis taken from the previous agreement, a unit area never updated after a reconfiguration: none of these complain at the moment of typing. They surface in a review that was missed, a recovery that cannot be supported, or a valuation built on a passing rent that was never correct, by which point the documents are scattered and whoever keyed the record has left the team. Accuracy is the deliverable. Speed on its own is the wrong thing to buy.

When the executed document and the deal summary disagree

New lettings and renewals arrive as more than one source: the executed document, the agreed heads of terms, a deal summary from the agency side, an email chain where the last concession was granted. They will not match.

An agent can extract each field from each source, map them onto the fields your system requires, and report where the sources conflict rather than silently choosing one. That conflict list is the valuable output, not the extraction, and a reviewer clears it in seconds because they are shown two candidate values and where each came from.

Set precedence explicitly before you build anything. Which source wins for the legal tenant name, which for the rent, which for dates, and what happens when a side letter or a deed of variation sits on top of the original. If you cannot write those rules down, an agent cannot follow them, and neither can your new starter.

Rent review and break dates arrive as conditions, not dates

Your system has a date field. The document has a rule: notice must be served a stated number of months before a date defined somewhere else in the document, or the review takes effect on each anniversary of a commencement date defined by reference to practical completion.

Keying that requires arithmetic and interpretation, which is why it goes wrong. Capture both the rule as written and the derived date, with the derivation shown, so the reviewer checks a calculation rather than repeating it. Indexation deserves the same treatment: record which inflation index the lease refers to, the lag, the review frequency and any cap or collar, because a stored date with no stored mechanism cannot be recalculated when somebody questions it later.

"Northfield Ltd 2" and the tenant that is three tenants

This is the part people underestimate. Extraction is largely solved. Deciding that the tenant named on the invoice is the same legal entity as the record in the ledger is not.

A single tenant ends up as several records because each system was populated by a different team at a different time. The ledger has "Northfield Ltd", the property management system has "Northfield Limited", and somebody created "Northfield Ltd 2" after an arrears query because the original record would not accept the posting. The guarantor is keyed as a tenant in its own right. A restructure means the paying entity is a subsidiary nobody recorded.

Build the matching deliberately. The company registration number is the only genuinely reliable key; normalised names, registered addresses and the unit the obligation attaches to are supporting evidence. Produce candidate pairs with that evidence attached and let a person confirm the merge. Automatic merging of entities money is posted against is the fastest way to make a reconciliation unrecoverable, and to lose the team's trust in the project.

Service charge budgets, apportionment and drifting floor areas

Service charge work is retyping with arithmetic bolted on. The budget is rebuilt per property, the apportionment schedule lives in a spreadsheet, and the logic inside that spreadsheet has usually never been written down anywhere else.

Apportionment is where the institutional knowledge lives. Certain units are excluded from certain cost heads. Some schedules weight area rather than using it directly. A capped tenant's shortfall is absorbed by the landlord rather than redistributed. Vacant units behave differently again. An agent reads areas and cost heads out of documents easily enough, and cannot infer any of that. Getting those rules out of one person's head and into something explicit is the hard half of the project.

Floor areas and unit records drift in parallel. The rent roll shows "Unit 3B" where the plan shows "Unit 03B", two small units were combined for a letting and never combined in the record, and the measured area has not matched the leased area since the last refit. A system that compares the two sources and reports the gaps is useful before anything is automated.

Supplier invoices coded to the wrong unit

Coding an invoice means choosing a cost category, a property, often a unit, and a recoverability treatment. The invoice helps with almost none of this. It is addressed to the managing agent, references a site name that is not the property name in your system, and describes the work in the engineer's terms.

Your own history is the best available signal. You hold years of invoices from the same suppliers coded to the same heads, and a model that proposes a coding with the comparable previous postings attached is immediately checkable. Recoverability needs the most care, since getting it wrong quietly moves cost between the landlord and the occupiers and surfaces only at reconciliation.

Meter readings, consumption and valuation inputs

Readings keyed from supplier statements carry their own traps: estimated readings presented like actual ones, a change in the unit of measure between statements, a rollover that reads as an implausible drop, a supply serving a unit that was reassigned. Plausibility checks against the previous period catch more of this than careful typing ever will.

Valuation and appraisal inputs are the same problem one layer up. Passing rent, void assumptions, review dates and areas get copied into a model by hand every cycle. The answer there is usually a direct feed rather than cleverer extraction.

Onboarding an acquired portfolio from someone else's spreadsheets

Acquisitions are where this work concentrates. The seller's data arrives as spreadsheets built to their own conventions, with scanned documents attached and gaps where their keying failed.

Treat it as a mapping and provenance exercise, not a load. Each field should land with a record of where it came from, whether it was read from a document or taken from the seller's sheet, and whether a person confirmed it. The fields that matter most are the ones that trigger something: review dates, break rights, obligations with notice periods. Load in tranches and reconcile each against the documents before the next, because one large load with no provenance leaves you unable to tell a keying error from an inherited problem.

Field by field, not document by document

Treat this field by field rather than document by document. A supplier reference or a meter reading inside the expected range can post straight through. Anything that moves money, changes a tenant's identity, or sets a date that triggers a notice belongs in a review queue however confident the model is, because the cost of being wrong is not symmetrical with the cost of a glance.

Whatever posts automatically needs a trail: the source document, the page, the extracted value, the rule applied, the person who approved it. Nobody asks until a tenant disputes a recovery or an auditor asks why a figure changed, and then it is the only thing that matters.

Where AI fails here

Scanned floor plans and marked-up drawings remain unreliable. Measurements written by hand onto a plan, or shown only graphically, will not come out as dependable figures, and a confident wrong area in an apportionment schedule is worse than a gap.

Side letters, licences and deeds of variation stacked over an original lease defeat naive extraction. The current position comes from reading several documents together and knowing which supersedes which, and models tend to report the clearest statement they find rather than the operative one.

Undocumented apportionment logic cannot be inferred. If the rule exists only as a habit, the agent will reproduce last year's figures without reproducing the reasoning, and the first year the property changes shape it will be wrong without saying so.

Entity resolution has a floor set by information that is in no system. Only a person knows that the group reorganised, that two similarly named companies are unrelated, or that the payer is a managing agent rather than the tenant.

Your own history limits what is achievable. If existing records hold duplicates, abandoned units and dates keyed from documents later varied, an agent evaluated against them learns the errors. Cleaning a defined slice first is the precondition, not the follow-up.

Proving it against corrections you have already made

The honest test uses records your team has already fixed. Replay the documents from a period where corrections were made and compare what the system would have produced against what the humans eventually settled on. That gives you a field level accuracy figure on contested cases rather than easy ones.

Then watch three things in production: the share of fields right first time with no human edit, the share sent to the queue, and the errors that still escape downstream. The last is the only one the business feels, and the one most projects never instrument.

Start with a single artefact and a single property type, run everything into a review queue, and widen only where your own evidence supports it. For a plain assessment of which part of your keying is automatable now and which is not, describe it to Adopt AI Partners at hello@adoptaipartners.com.