A bank account, not a rent roll
Open a property's bank account on the first of the month and it looks nothing like a spreadsheet. Instead of a tidy list of units and tenants, there's a scroll of deposits — many for the same or nearly the same amount, arriving days apart, each with a reference that only half-identifies who sent it and which unit it belongs to.
A property manager's actual job isn't adding those numbers up — that part is trivial. It's answering a much harder question: of every unit on the rent roll, which have paid this period, and which haven't? Answering that means matching every one of those deposits back to a specific unit and tenant, and the statement alone rarely makes that easy.
Why rent is harder to reconcile than it looks
A single invoice has one clear amount and one clear payer. A rent roll breaks that pattern in several ways at once, and each one compounds the others.
The reference is barely useful
A bank transfer reference is often a tenant surname alone, a unit number in a format that doesn't match your rent roll, or a code generated by a payment app — none of which map cleanly onto your records without a person doing the guessing.
Many units pay the same amount
When a dozen identical one-bedroom units all pay the same rent in the same week, amount alone can't distinguish one unit from another — reference and timing have to do the work instead.
Bulk settlements hide the detail
A payment portal often settles many tenants' rent as one lump sum on the statement, with the unit-level breakdown sitting in a separate report that has to be read alongside it.
Move-ins and move-outs don't line up with the calendar
A tenant who moves in mid-month pays a prorated amount that doesn't match the rent roll's standard figure, and a departing tenant's final payment often covers a partial period too.
None of these problems are unusual or a sign of a badly run property — they're the normal shape of rental income, and they're exactly why matching by eye, from a rent roll and a bank statement side by side, takes hours every single month.
What this doesn't do, stated up front
Doesn't decide delinquency or collections action
It reports what the bank record shows. Whether a late or partial payment triggers a late fee, a notice, or an eviction filing is your policy to apply, not a decision made by a payment reader.
Doesn't collect rent
It reads records that already exist. Collecting rent remains the job of your payment portal, standing order or direct deposit setup.
Doesn't send rent reminders
Following up with tenants who haven't paid is a communication task for your existing property management tools, not something this does on its own.
Doesn't guess an ambiguous match
A reference that could belong to two units, or an amount that doesn't match anyone, gets flagged for a person to resolve — never silently assigned to a best guess.
What's left is narrow and is exactly the part that eats an evening every month: turning a bank statement and a rent roll into a clear list of who has paid.
What gets read
| Field | Source |
|---|---|
| Deposit amount and date | Bank statement |
| Reference text on the transaction | Bank statement |
| Unit number and tenant name | Your rent roll |
| Expected rent amount per unit | Your rent roll |
| Per-unit breakdown of a bulk settlement | Payment portal report, when applicable |
Five sources of truth, read as they actually exist — not summarized from memory, and not assumed to agree with each other until the matching step actually checks.
How a deposit finds its unit
Matching runs on three signals together, not any single one alone, because any one signal in isolation is too weak to trust on its own.
| Signal | Why it isn't enough alone |
|---|---|
| Reference text | Often a partial name, a unit number in a different format, or a portal code — one of several possible matches on its own |
| Amount | Shared by every unit on the same floor plan and rent tier |
| Timing | Clusters around the first of the month, so many units pay in the same short window |
A deposit that lines up on all three — a reference that resembles the unit or tenant name, an amount that matches the rent-roll figure, arriving near the due date — is a confident match. A deposit that lines up on only one is exactly the case flagged for a person to confirm rather than resolved silently.
A month's rent roll, worked
A 42-unit apartment building, one month, 39 rent deposits on the statement.
| Result | Count |
|---|---|
| Matched with high confidence | 34 |
| Matched, flagged for a quick confirm | 3 |
| Unmatched — no unit found | 2 |
| Units with no payment on record | 5 |
The 3 flagged for confirmation were mostly tenants who pay from a joint account under a spouse's name — an amount and timing match, but a reference that didn't say the tenant's own name. Confirming each took seconds once the mismatch was visible. The 2 unmatched turned out to be a parking fee payment and a one-off maintenance reimbursement, neither of which was rent at all.
How it works
Upload the bank statement and rent roll
PDF, scan, or CSV/Excel — the statement covering the period, and your current rent roll.
Each deposit is read
Amount, date and reference, per transaction, kept linked to the source document.
Matched against the rent roll
By reference, amount and timing together, with a confidence level per match.
Export
Excel, CSV or JSON — matched, flagged and unmatched rows kept as separate, clearly labeled groups.
Partial payments and payment plans
A tenant who pays half this month and promises the rest next week is common enough that any reconciliation method has to handle it gracefully. Treating a partial payment as if it were the full rent — or worse, ignoring it because it doesn't match the expected amount — both produce a rent roll that misrepresents reality.
A deposit for less than the expected amount is matched to the unit for what actually arrived, with the shortfall kept visible rather than hidden inside a total that looks settled. A tenant on a formal payment plan, with several smaller deposits arriving across the month, has each one matched individually and summed against what the plan actually calls for.
When rent arrives through a payment portal
Many tenants now pay through an online portal — a service that collects individual payments throughout the month and settles them to the landlord's account as one batch, often days after the tenant's own payment date.
That settlement shows up on the bank statement as a single deposit that doesn't match any one unit's rent. The portal's own report — usually a CSV or PDF listing each tenant's payment within the batch — gets read alongside the statement, so the lump sum splits back into the individual unit-level payments it actually represents.
Move-ins, move-outs and mid-month prorations
A tenant moving in on the 15th doesn't pay a full month's rent for that first period — they pay a prorated amount that won't match the rent roll's standard figure for that unit. The same happens in reverse for a tenant moving out mid-month, where the final payment covers only part of the period.
These aren't treated as errors. A prorated amount that's roughly proportional to the days occupied, arriving near the expected date, is still matched with reasonable confidence — the system doesn't require an exact match to the standard rent-roll figure, only a plausible relationship to it. Where the proration is genuinely unclear, the deposit is flagged rather than forced into a match that might be wrong.
What happens to what doesn't match
An unmatched deposit isn't discarded or hidden — it's kept as its own visible group, with the amount, date and whatever reference text exists, so someone can look at it directly instead of it disappearing into a reconciled total that quietly absorbed a mistake.
In practice, unmatched deposits turn out to be one of a small number of things: a fee payment unrelated to rent — parking, pet rent, a maintenance reimbursement — a tenant whose rent-roll entry is out of date after a name change, or occasionally a genuine payment from someone who isn't on the rent roll yet, like an application deposit that arrived before the lease was finalized. Each of those has a different fix, and none of them get fixed by guessing.
If you manage more than one property
A landlord or management company with several properties faces a version of this problem multiplied: each property often has its own bank account, and headquarters needs one consolidated picture across all of them without losing the ability to drill into any single building.
Each property's statement and rent roll can be read the same way individually, and the matched results rolled up into one portfolio-wide report — a total occupancy and collections picture alongside the detail for any specific building or unit when it's needed.
Who this is for
Independent landlords
A month's worth of matching done in an evening instead of spread across several weekends.
Small property management companies
A repeatable process that doesn't depend on one person's memory of who usually pays what.
Owners reviewing a manager's reporting
A clear, current answer to who has and hasn't paid, backed by the bank record rather than a manager's summary.
Bookkeepers serving multiple property owners
The same matching process applied consistently across every client's rent roll.
This isn't property management software
Worth being precise about the boundary. Platforms like Yardi, AppFolio or Buildium handle the tenant relationship end to end — leases, maintenance requests, online payments, sometimes accounting itself. This does one specific thing underneath all of that: reading the bank record and matching it to who actually paid.
For owners who already run one of those platforms, the output here is something to cross-check against it or hand to whoever reconciles the books — not a replacement for the platform, and not a second system to maintain tenant records in.
Moving from a spreadsheet or a manual check
Most landlords and small managers who reach for this have been reconciling rent by hand for years — opening the bank statement in one window and the rent roll in another, checking off units as deposits appear. It works, in the sense that it eventually produces an answer, but it doesn't scale gracefully past a handful of units and it leaves no record of how each match was decided.
The transition doesn't require abandoning that process wholesale on day one. A reasonable first step is running the automatic matching alongside the manual check for one month, comparing the two results, and building confidence in where they agree and where they don't before relying on the automatic result alone.
What tends to convince a skeptical landlord isn't a claim about speed — it's seeing their own statement and rent roll produce a result that matches what they would have concluded by hand, in a fraction of the time, with the ambiguous cases already sorted out from the confident ones.
How often to reconcile
Rent is a monthly cycle, and reconciling it any less often than monthly guarantees the reconciliation is always behind the reality it's meant to reflect. A quarterly attempt means matching three months of deposits against memories that have faded, turning what should be routine into a multi-day reconstruction — especially risky for rent, where a missed nonpayment compounds every additional week it goes unnoticed.
Some larger operations with a dedicated bookkeeper reconcile weekly instead, catching a missing payment within days rather than waiting for the whole month to close. That's more frequency than most portfolios strictly need, but it's worth considering for a property with a known history of delinquency, where early detection matters more than usual.
Whatever the interval, the deciding factor isn't precision for its own sake — it's whether the interval stays short enough that a manager can still remember the context behind an unusual deposit when reviewing it, rather than reconstructing a months-old memory from a bank line alone.
Starting with one property, not the whole portfolio
A manager overseeing a dozen properties can find the idea of reconciling all of them at once daunting enough to never start. A more realistic path is beginning with a single property — ideally one with a clean, current rent roll and a straightforward mix of payment channels — and using that as a proof of concept before extending to the rest.
That first property answers the practical questions that matter before scaling up: how cleanly do the deposits actually match, how much manual review do the flagged cases need, and how does the resulting paid/unpaid list compare to whatever partial picture existed before. Answers from one property transfer reasonably well to the rest, whereas trying to onboard the entire portfolio simultaneously multiplies every early surprise across every building at once.
A property with few payment portals and consistent tenant references is a natural first candidate, not because messier properties don't matter, but because starting with the straightforward case builds a working routine before it has to handle a building with several bulk settlements and a history of ambiguous references.
Privacy
Uploads go over TLS, encrypted end to end.
Processing runs on EU-hosted infrastructure.
Original documents are deleted immediately after extraction.
Tenant and financial data are never used to train AI models.
For a landlord or manager handling tenant financial data, that's not a footnote — the details are on the security page.