Contact Us

Send us a note any time. We aim to answer every enquiry within 24 hours.

What we do

Technology, real estate & PropTech, digital growth

Find us

2121 Meridian Park Blvd, Concord, CA 94520

Office hours

Mon-Fri: 9:00-18:00 / weekends by appointment

How I Automated Rent Reconciliation

  • By Lily P.
  • August 1, 2026
  • 0 Comment
  • 10 Views

Rent reconciliation is the job nobody schedules and everybody does. It is not difficult. It is fiddly, repetitive, and unforgiving in exactly the way human attention is worst at — and it has to be right, because it is the number that decides whether you chase somebody.

Here is how we stopped doing it by hand, and more usefully, how to tell whether the same thing is worth doing in your own portfolio.

What the manual version actually involves

Open the bank statement. Open the spreadsheet. For each incoming payment, work out which tenant it came from, which month it applies to, and whether it covers the full amount. Mark it off. Repeat.

Most payments take five seconds. The problem is the ones that do not:

  • A payment from a name that is not on the lease — a partner, a parent, a business account.
  • A partial payment, which now needs a running balance rather than a tick.
  • Two payments in one month that together make up one month’s rent, or do not quite.
  • A payment that arrives on the 31st and is genuinely ambiguous about which month it is for.
  • A deposit refund, a utility reimbursement or a maintenance credit sitting in the same account.

Individually trivial. Collectively they are why the job takes a morning instead of ten minutes, and why doing it monthly means finding out about a short payment up to four weeks after it happened.

The insight that makes it automatable

The instinct is to automate the whole thing. That is the wrong target, and chasing it is why a lot of these projects stall.

The correct target is to automate the easy 85% and route the rest to a human with enough context to resolve it in seconds. A matcher that handles the obvious cases and confidently guesses at the ambiguous ones is worse than no matcher at all, because now your ledger is wrong in ways you will not notice until it matters.

So the design goal is not accuracy in the abstract. It is: be right when confident, and be obviously uncertain otherwise.

How the matching works

Three signals, in order of reliability.

  • Amount. An exact match to a tenant’s rent is strong evidence on its own, especially when amounts differ between units.
  • Payer name. Fuzzy-matched against the lease, because bank descriptors mangle names and people use middle names, initials and business accounts.
  • Timing. A payment arriving within the usual window for that tenant, from someone who has paid on the 3rd for eighteen months, is almost certainly the same thing again.

Any two of the three agreeing is enough to post automatically. One signal, or two that disagree, goes to the exception queue with the candidates listed so a human picks rather than investigates.

The exception queue is the feature. It is what makes the automated portion trustworthy.

What changed, and what surprised us

The expected win was time. The more valuable one turned out to be the shortened feedback loop: a short payment is visible the day it lands rather than at month end. That is the difference between a quick message and a formal process, and it changes outcomes more than the recovered hours do.

The genuinely unexpected effect was what became possible afterwards. Once the ledger was reliable in real time, several other things stopped being manual almost for free — owner statements, year-end exports, and a defensible payment history for any tenant. We did not build those; they fell out of having a trustworthy record.

That pattern generalises, and it is the most useful thing in this post. The highest-value automation is usually the one that makes a record trustworthy, because everything downstream of that record stops requiring a person.

Is it worth doing in your portfolio?

Rough test. Multiply the time you spend on reconciliation by twelve. If that number does not make you wince, the answer is probably no, and you should stop reading and go do something else.

Three things push it toward yes:

  • You are growing. The work scales linearly with units and the annoyance scales faster.
  • You have been surprised by an arrears balance. That is the feedback-loop problem, and it is the expensive one.
  • Someone other than you needs the numbers — an accountant, a lender, a co-owner. Manual ledgers are fine until somebody else depends on them.

And one that pushes it firmly toward no: if you have four units and enjoy the ten minutes, automating it is a hobby project, not an investment. That is a legitimate answer and we give it often.

If you want to try it yourself

Start smaller than the full matcher. Get the bank feed into the same place as the rent schedule and put a running balance next to each tenant. Do nothing clever. Most of the value is in having the two facts side by side and current — the automated matching is an optimisation on top of that, not the point.

If it turns out the fix is a platform rather than a script, that is worth knowing before you build anything: see PropTech consulting for how the decision changes with portfolio size.

Or have us look at it

The full write-up of what we built is on the automated rent ledger page, and the general approach is on workflow automation. If you want a second opinion on whether yours is worth automating, tell us what the monthly job looks like — sometimes the honest answer is that it is not.

Lily P.

Head of Operations at Cao Investment Group. Writes about the operating side of the work — property systems, process, and the automation that removes the jobs nobody schedules.