A deposit rarely names its tenant
Once a deposit is read — amount, date, reference — the hard part hasn't started yet. The hard part is figuring out which unit it belongs to, and that turns out to be a matching problem: does this reference point to a tenant you recognize, does the amount fit that tenant's rent, and if none of that resolves cleanly, what then?
This page describes exactly that mechanic — the logic that sits underneath rent roll reconciliation, spelled out on its own because it's the part worth understanding in detail before trusting it with real rent data.
Why one signal alone isn't enough
In the simplest case, a tenant pays with their own name and unit number clearly stated in the reference, every time. That case needs no cleverness at all. What makes matching genuinely hard is everything short of that ideal.
A tenant might pay from a joint account under a spouse's name. A reference might be truncated to fit a narrow banking app field, cutting off exactly the part that would have identified the unit. Two identical floor plans on the same rent roll might have nearly identical rent amounts, where a single mismatched digit changes which unit a real payment lands against. None of these are exotic edge cases; they're what a tenant base that doesn't share your exact reference conventions produces routinely.
What gets read
| Field | Where it's checked |
|---|---|
| Reference text | Read exactly as printed on the bank transaction |
| Deposit amount | Compared against each unit's expected rent on the rent roll |
| Deposit date | Compared against the tenant's typical or due payment date |
| Unit and tenant name | Read from your rent roll, matched as candidates |
How the three signals combine
Rather than trying every possible tenant at once and picking whichever seems most likely, matching checks all three signals together and requires meaningful agreement across them — the same combination, checked the same way, every time.
Reference clearly names the tenant or unit
The strongest signal available. Matched with high confidence when the amount also fits.
Reference is partial but the amount and timing fit one unit
Matched with a flag for a quick human confirm rather than accepted outright.
No reference match, but amount and timing point to exactly one plausible unit
Matched with medium confidence, based on the strength of the remaining two signals alone.
None of the signals resolve to a single unit
Left unmatched, visible as its own group, never guessed from whichever unit is currently unpaid.
A deposit never skips to a weaker signal just because a stronger one wasn't found — each combination is evaluated on its own merits, not as a fallback chain.
Splitting a single deposit across units
A property manager who collects rent through a personal account before forwarding it, or a tenant who pays for both their unit and a storage locker in one transfer, produces a single deposit that actually covers more than one line item on the rent roll. Treating that deposit as belonging to just one unit would overstate that unit's payment and leave the other looking unpaid.
Where the total matches the plausible sum of two or more expected amounts, the deposit is split across the corresponding units rather than forced onto a single one — the deposit total is never the unit of matching; the underlying rent-roll lines are.
Three confidence levels
Not every match is equally certain, and treating them all the same — either all trusted or all reviewed — wastes effort in one direction or risks silent errors in the other. Three levels keep that distinction visible.
| Level | When |
|---|---|
| High | A clean reference and a matching amount, arriving near the expected date |
| Medium | A readable but partial reference, or an amount-and-timing-only match against a unique unit |
| Low / unmatched | No combination of signals resolves to a single unit |
For a batch of dozens of deposits, that distinction is what turns a full manual review into a review of the handful that actually need one — most of a month's rent typically lands at high confidence and needs no attention at all.
When a deposit genuinely doesn't match anything
Some deposits were never going to match a unit — a parking fee, a pet deposit, a one-off maintenance reimbursement, or simply a payment from someone who isn't on the rent roll at all. Forcing a match onto those deposits would be worse than leaving them unmatched, because it would misrepresent income that has nothing to do with rent as if it were a tenant's payment.
Those deposits are kept in their own visible group rather than being pushed onto whichever unit happens to look unpaid at the time. What happens to them next — coded to a different income category, investigated, or simply logged — is a decision made by a person, not by the matching logic.
Why consistent references from tenants help
A tenant who includes their unit number in the same spot every time they pay is, without knowing it, doing a large part of the matching work for you. Small, consistent formatting — even if it's not exactly the format your rent roll uses — is far easier to match reliably than formatting that changes payment to payment from the same tenant.
For a tenant whose payments consistently land at medium confidence or worse, a short note in the welcome packet or lease addendum asking them to include the unit number in a specific, consistent spot is usually more effective than any adjustment on the reading side — the cleanest fix to a matching problem is often at the source, not downstream of it.
How it works
Upload the statement and rent roll
Whatever the bank sent, plus your current unit and tenant list.
Each deposit is read
Amount, date and every candidate reference found on it.
The three-signal check runs
Reference, amount and timing evaluated together, in a fixed order.
Export
Excel, CSV or JSON, with confidence levels and source documents kept per deposit.
A tenant who pays under a different name
A payment from a spouse's account, a roommate's account, or a company account for a corporate lease is common enough that any matching method has to handle it without treating every name mismatch as a red flag. The amount and timing still carry weight even when the name on the transaction doesn't match the lease-holder's name exactly.
A first payment from an unfamiliar name is flagged for confirmation the first time it happens. Once confirmed, that pattern is available as context for future periods — though it's never assumed automatically without the initial human confirmation, since a name mismatch is exactly the kind of ambiguity that shouldn't resolve itself silently.
Reading a portal's settlement report
When rent is collected through a payment portal or processor, what lands on your bank statement is rarely a tenant-by-tenant list — it's a single batch deposit representing everything the processor collected over a settlement window, days after any individual tenant actually paid. On its own, that deposit carries almost no usable matching signal beyond the processor's own name.
The processor's own settlement report is what closes that gap. It lists the individual payments that make up the batch — usually tenant name, unit reference and amount per line — and matching reads that report alongside the bank statement rather than relying on the bank line alone. Each individual line from the settlement report is matched to a unit using the same reference-amount-timing check as any other deposit; the batch total on the bank statement is then reconciled against the sum of those individually matched lines.
Where the settlement report's total doesn't match the bank deposit exactly — a processing fee deducted before settlement is a common cause — that discrepancy is surfaced on its own rather than silently absorbed into one of the matched units, since a fee is a different kind of line item than a missed or partial rent payment.
A month, worked through
A 28-unit building with rent split across bank transfer and one payment portal ran a month's worth of deposits through the matching, mixing both channels in the same batch.
| Result | Units |
|---|---|
| Matched at high confidence | 21 |
| Matched at medium confidence, confirmed on review | 4 |
| Split from the portal's bulk settlement | 6 |
| Unmatched, investigated separately | 1 |
The six portal payments split cleanly once the settlement report was read alongside the bank deposit — none of them needed manual correction. The single unmatched deposit turned out to be a returned-item reversal from a prior month, not a new rent payment at all, and was excluded from the rent roll entirely once identified. Total review time for the four medium-confidence and one unmatched case: under fifteen minutes.
What accuracy actually looks like
A useful way to think about matching accuracy isn't a single percentage — it's the shape of the distribution across the three confidence levels. A portfolio with clean, consistent tenant references sees most deposits land at high confidence, with only a small tail needing review. A portfolio with messier references — several joint accounts, a payment portal with inconsistent settlement formatting — sees a larger medium-confidence tail, which means more review time, not necessarily more errors.
That distinction matters because it's tempting to read a larger review queue as a sign the matching is working poorly, when it's often just an honest reflection of how ambiguous the underlying data actually is. The alternative — a system that resolves every ambiguous case silently and reports 100% matched — isn't more accurate, it's just hiding the uncertainty instead of surfacing it.
In practice, most residential portfolios with a mix of bank transfer and portal payments see somewhere between 85% and 95% of deposits land at high confidence on a given month, with the rest split between a quick medium- confidence confirm and a small number of genuine unmatched cases worth investigating individually.
Improving match rates over time
The match rate on a portfolio's first month is rarely its best month. Two things tend to improve it steadily after that: a rent roll that gets progressively more accurate as move-in and move-out dates are kept current, and tenants who adopt more consistent payment references once asked — the effect described above in the section on consistent references.
A third factor is specific to portfolios with a payment portal: once a portal's settlement report format is understood and confirmed to parse cleanly, that channel's deposits tend to match at consistently high confidence every month afterward, since the underlying format rarely changes once established.
None of these improvements require a change to the matching logic itself — they're improvements to the underlying data the matching runs against, which is usually the more effective place to invest effort when a match rate feels lower than expected.
What you get back
One row per deposit
Unit, tenant, amount and confidence level, each in its own column.
Unmatched deposits kept separate
Visible as their own group, not folded into whichever unit was unpaid.
Traceable to source
Every row linked back to the bank statement it came from.
Who this is for
Mostly useful for anyone with more than a handful of units at once, where matching deposits to tenants by hand has stopped being a quick task.
Independent landlords with a growing portfolio
Matching that scales past the point where a mental map of who pays what, when, still works reliably.
Small property management companies
One consistent matching process across every owner's rent roll, rather than a different informal method per staff member.
Bookkeepers serving multiple property clients
The same reference-amount-timing check applied regardless of how each client's rent roll happens to be formatted.
Operations with a mix of payment channels
Bank transfer, checks and portal settlements all matched against the same rent roll in one pass.
Getting started without changing anything
Nothing about trying this requires changing how tenants pay rent, switching payment portals, or renumbering units. The lowest-friction start is a single month's bank statement against your current rent roll, run alongside whatever matching process already exists, and compared against what that process produced on its own.
That side-by-side comparison is usually what actually settles the question for a skeptical manager — not a claim about accuracy, but seeing real deposits from a real month land against the right units, with the genuinely ambiguous ones already sorted out from everything that matched cleanly on the first pass.
Privacy
Uploads go over TLS, encrypted end to end.
Processing runs on EU-hosted infrastructure.
Original statements are deleted immediately after extraction.
Tenant and rent-roll data are never used to train AI models.
Full details are on the security page.
Where this stops
Tenant payment matching finds the unit and tenant behind a deposit — it doesn't decide delinquency, calculate late fees, or replace the property-management system you already use for leases and maintenance. Those decisions, and the full picture of how matched deposits become a reconciled rent roll, are covered in rent roll reconciliation.