A payment notification tells you three things: how much, when, and a name that may or may not be the tenant's. What it never tells you is what the money was for.
Restoring that, so much settled August rent, so much cleared the water bill, so much came off arrears, is the whole of reconciliation, and it is the difference between books that balance and books that merely add up.
Why it drifts
Names don't match. The account is in a spouse's name, a relative pays, an employer pays directly. Matching on name alone fails constantly and fails silently.
Amounts don't match. Part payments, round-number payments, one payment covering two months, one payment covering two units.
Timing doesn't match. Money arrives on the 29th for a month that starts on the 1st. Whether that clears arrears or prepays next month is a decision, and if nobody makes it deliberately, it gets made differently each time by whoever is entering it.
Decide the allocation rule once
The most valuable thing you can do is fix an order and apply it every time: oldest arrears first, then current rent, then utilities, then deposits, or whatever order suits your business.
The specific order matters far less than the fact that it never changes. A consistent rule makes every balance reproducible; an ad hoc one means the arrears figure depends on who did the entry.
Write it down, and make sure everyone entering payments knows it.
Ask for a reference, and treat it as a bonus
A unit number in the payment reference solves most matching problems. Ask for it, print it on every bill, and then build a process that survives people not using it, because roughly half never will.
Reconcile weekly, not monthly
A payment you cannot identify this week has a cause somebody remembers: a phone call, a message, a tenant who mentioned it. The same payment in March, discovered in December, is a permanent mystery that quietly becomes a suspense entry nobody ever clears.
Weekly, the list of unmatched items is short enough to actually work through.
Keep an unallocated bucket, visibly
Money that has genuinely arrived but cannot yet be matched should sit somewhere named and visible, not applied to the nearest plausible tenant to make a report look tidy. A visible unallocated balance is a task. A guessed allocation is a wrong balance on somebody's statement, and it will be defended later by whoever made it.
What it should produce
Three things, at any moment:
- Every payment traceable to what it settled, in the order your rule says.
- Every tenant balance reproducible from the entries behind it, not from a running memory.
- A receipt each tenant can check without phoning anyone: the same split, on their side.
That last one is the test. If a tenant's copy and your ledger can disagree, they eventually will, and the disagreement will surface at the worst possible moment. See a paper trail that survives a question for what to record while it is still obvious.
Allocation rules, and what each one does to your reports
The three rules portfolios actually use, and the consequences of each:
Oldest charge first. Money clears the earliest outstanding item regardless of type. The default, and the one that keeps arrears ageing honest, because a tenant paying regularly but never quite enough will visibly age rather than appearing current each month.
By charge type. Rent before utilities, or utilities before rent where the supplier has to be paid. Defensible, and it has a side effect worth knowing: the charge type at the bottom of the priority list quietly accumulates. A portfolio that always clears rent first will find its oldest balances are water bills from a year ago.
Tenant's instruction. Where a tenant states what a payment is for, and that is recorded, it generally governs. This is the exception that must be handled deliberately. A stated instruction that the system silently overrides is the one allocation error a tenant will be able to prove.
Whichever you adopt, four things make it work: it is written into the tenancy pack so tenants know it, it is applied identically by everyone entering payments, the receipt shows the result, and changes to the rule apply forwards rather than being used to re-allocate history.
The unallocated account is a control, not a mess
A visible unallocated balance is a sign of a portfolio being run honestly. What matters is that it behaves like a queue rather than a drawer.
Give it the discipline of any other control:
- Every item carries its evidence: transaction code, payer name and number, date, amount, and what has been tried so far.
- It is worked weekly, by a named person, with one message per item.
- It is aged. An unallocated item more than a month old is not awaiting identification; it is being ignored, and it should be escalated rather than left to become furniture.
- Nothing is written off quietly. Money that genuinely cannot be attributed after real effort is still somebody's, and the decision about what happens to it is a decision, recorded, made by a named person, not a rounding.
- It is reported. The unallocated balance belongs on the management report next to arrears, because it is arrears' mirror image: money you hold that you have not credited to anyone.
A portfolio with no unallocated balance at all is not tidier than one with a small worked queue. It is usually a portfolio where somebody has been guessing, and the guesses are sitting in tenants' balances where they will surface at move-out.
Suspense, prepayments and credits are three different things
They get merged, and they should not be:
Unallocated. Money received, tenant unknown. A liability, resolved by identification.
Prepayment. Money received, tenant known, no charge yet raised. It should sit as a credit on that tenancy and be applied automatically when the next billing run raises the charge. The common error is applying it to a charge that does not exist yet by creating one manually, which double-bills the tenant a fortnight later.
Credit from an overpayment or correction. Money the tenant is entitled to have applied or refunded. Shown on the receipt and on their statement, not absorbed into the next month in silence.
Keeping them separate is what lets you answer, at any moment, how much of the cash you hold belongs to identified tenants, how much is spoken for by future charges, and how much you cannot yet attribute to anyone.
What to reconcile, weekly, in what order
- Bank and mobile money to the cash book. Does every movement in the account appear in your records, and every record in the account?
- Receipts to charges. Does every payment recorded have an allocation, and does every allocation point at a charge that exists?
- Tenant balances to the ledger. Can each balance be reproduced from the entries behind it?
- Deposits held to the deposit register. A standing liability that should tie to a figure somebody can name at any time.
- Unallocated to the queue. Opening, plus new, less cleared, equals closing.
The fifth check is the one that catches the others. If the unallocated balance does not close, something was applied without being recorded or recorded without being applied, and it is findable this week and not next quarter.
The mechanical version of all five is what a double-entry ledger gives you automatically, and it is the core of what property management software built for Kenya is doing when it matches payments as they arrive. The habit is available to anyone with a spreadsheet and an hour on a Friday; what the system removes is the hour, and the chance of a tired entry going unnoticed until December.
Common questions
How do I reconcile rent payments to the right tenant?
Match on a unique account or reference number rather than on the payer's name or the amount, apply the matched payment to specific charges by a stated rule, and hold anything unmatched as unallocated until it is confirmed. The mobile money mechanics are in how to reconcile M-Pesa rent payments.
What should I do when a tenant pays the wrong amount?
Apply it by your allocation rule, receipt it showing exactly what it settled, and show the remaining balance or the credit. An overpayment is a credit on the account, not a silent contribution to next month.
What is an unallocated payment?
Money that has genuinely arrived but cannot yet be attributed to a tenancy. It is an honest state and belongs in a visible, aged queue that somebody works weekly, never guessed onto the nearest plausible account.
Should payments be allocated to the oldest charge first?
It is the most common rule and the one that keeps arrears ageing truthful. Any consistent rule can be defended; what cannot be defended is a rule that changes depending on who entered the payment.
How often should reconciliation happen?
Weekly. An unidentified payment from this week has a cause somebody remembers; the same payment found in December is a permanent mystery that ends up as a suspense entry nobody ever clears.
Can a tenant decide what their payment settles?
Where they give a clear instruction and it is recorded, it generally governs, so build the process to capture it rather than to override it. Silently reallocating a payment against the tenant's stated instruction is the one allocation error that is easy for them to prove.