Every landlord who has grown past a handful of units hits the same wall in the same order. The money is arriving. The tenants say they have paid. And nobody can say, without a conversation, what any particular payment was for.
This is not a failure of effort. It is a failure of one field.
An M-Pesa statement is not a ledger
Your statement records a transaction: an amount, a time, a sender's registered name, a code. All true, all useful, and none of it says which charges the money settled.
That gap matters the moment a payment is not a clean full month's rent. A tenant who owes rent, last month's water and a carried balance sends one amount. Which of the three did it pay? The statement has no opinion. Somebody has to decide, and if that decision is not recorded, the balance becomes whatever the last person to look at it remembers.
Two accounts of the same tenancy then diverge, both kept honestly.
Fix the reference before you fix anything else
If you are collecting on a till number, the payer cannot give you a reference at all, because there is no field for one. That single limitation is why most landlords move to a paybill once they have more than a few tenants. We have set out the full difference in paybill vs till number for rent.
Assuming a paybill, the account number is the whole game. Three rules:
Make it unique across the entire portfolio. "3B" exists in four of your blocks. KLN-3B
exists in one. A reference that is only unique within a building is not a reference; it is a
riddle you will solve manually every month.
Make it short and typeable. It is being entered on a phone keypad, often by someone standing in a shop. Every extra character is another chance of a transposition you will have to chase.
Put it everywhere. On the lease, on every bill, in the reminder, on a sticker by the door if that is what it takes. A reference tenants do not know is a reference nobody uses.
Write down the allocation rule once
Even with a perfect reference, a part-payment still has to be applied to something. That needs a rule set in advance, not a judgement made per receipt.
Most portfolios use oldest-charge-first: the money clears the earliest outstanding item, then the next, until it runs out. Others prioritise by type, putting rent before utilities, say. Which you pick matters far less than that it is written down, applied the same way every time, and visible to whoever asks.
The reason it has to be a rule rather than a habit: a balance produced by consistent allocation is reproducible. Anyone can recalculate it and get the same answer. A balance produced by case-by-case judgement can only be defended by the person who made the judgements, and only for as long as they remember them. See payment allocation for the mechanics.
Then the receipt has to show the split
This is the step people skip, and it is the one that ends disputes.
A receipt that says "Received 12,000" records the money. A receipt that says:
- 8,000 to September rent
- 2,400 to August water
- 1,600 to arrears brought forward
answers the tenant's next three questions before they ask them. It also makes the allocation rule visible, which is what stops it quietly drifting.
What to do with money you cannot identify
Some payments arrive with no reference, a wrong reference, or from a number you do not recognise. A tenant paying from a relative's phone is extremely common and entirely innocent.
The correct treatment is to hold it as unallocated. Not to guess, not to apply it to the account it most likely belongs to, and above all not to leave it out of the books because it is awkward.
Unallocated is an honest state. It says: this money is ours to account for, and we do not yet know whose it is. The balance should be visible, reviewed weekly, and cleared by confirming with the tenant. A portfolio with a small, actively-worked unallocated balance is being run properly. One with no unallocated balance at all is usually one where somebody has been guessing.
Why this compounds
Reconciliation is not administrative tidiness for its own sake. Everything downstream depends on it.
You cannot age arrears if you do not know which month a payment settled, and arrears ageing is the report that tells you which tenants are a solvable problem and which are already gone. You cannot produce a landlord statement you would be happy to be audited on. You cannot answer a tenant's dispute in one message.
All of those rest on the same foundation: every shilling that arrives is applied to something specific, by a rule, and the record says what.
The weekly reconciliation, step by step
Reconciliation is a routine, not a project. Done weekly it takes under an hour on a portfolio of a few hundred units; done at year end it cannot be done at all, because the people who could have explained the odd entries have moved on.
- Pull the statement for the period. The paybill statement, and the bank statement for the settlement account, covering the same dates.
- Match the settlement. The total paid out of the paybill into the bank, less charges, should agree with what landed. Differences here are transaction costs or timing, and they should be identified rather than absorbed.
- Match each receipt to a tenancy by account number. Most will match automatically; the ones that do not are the work.
- Apply each matched payment to specific charges by your stated payment allocation rule.
- Park what cannot be identified as unallocated, with the transaction code, name, phone number and date attached. Never onto the account it probably belongs to.
- Work the unallocated list. One message per item, usually clearing most of it within a day.
- Check the totals close. Opening balance, plus receipts, less allocations, equals the unallocated balance. If it does not, the error is in this week, where it can still be found.
Two figures are worth watching over time: the share of payments that match automatically, and the age of the oldest unallocated item. A rising first number means your reference scheme is working. A rising second means nobody is working the queue.
The awkward cases, and the right treatment for each
A tenant pays from someone else's number. Extremely common and almost always innocent: a spouse, an employer, a relative in another town. The registered name on the statement will not match your tenant, and that is not a reason to refuse the payment or to leave it unallocated indefinitely. Match on the account number, record the payer's name and number against the receipt, and confirm with the tenant once. Expect it to recur and note it on the tenancy.
One payment covering several units. A tenant with two units, or an employer paying for three staff. Split it in the ledger across the tenancies, with each allocation referencing the same transaction code, so the single receipt can be traced to every charge it settled.
An overpayment. A credit on the tenant's account, shown on the receipt. Not a silent offset against next month, which is how credits vanish by the time somebody moves out.
A payment from a former tenant, or to a closed account. Hold as unallocated and contact them. Refunds go back by a traceable route, never in cash, with the reason recorded.
A wrong account number that matches a real tenant. The dangerous one: the payment matches automatically to the wrong tenancy and two accounts are now wrong, one flattered and one short. This is why a weekly review of automatic matches against unexpected credits is worth the ten minutes it takes.
A reversal. M-Pesa reversals happen after you may already have receipted. Post the reversal as its own entry referencing the original, never by deleting the receipt.
What the charges and the paperwork do to your books
Two practical points that catch out portfolios moving to a paybill.
Transaction costs are real and they are yours, not the tenant's, unless the tenancy says otherwise, and a tenancy that pushes the cost onto tenants should say so plainly rather than leaving them to discover it. Either way, book the charge as an expense rather than netting it off the rent received, because a rent receipt for less than the tenant paid produces exactly the confusion this whole article is about.
And record the mobile money channel properly in the tenancy pack: the paybill number, the account number format, and what to do when a payment fails. Most "the tenant did not pay" incidents are a tenant who paid to the wrong paybill, or to the previous agent's, and the sooner that is identified the more recoverable it is.
Why the reference beats every workaround
Portfolios that skip the reference scheme end up building substitutes for it: matching by phone number, by registered name, by amount, or by asking. Each fails in an ordinary case. Phone numbers change and get shared. Registered names are frequently not the tenant's. Amounts collide the moment two units carry the same rent. Asking does not scale past about twenty tenants and does not survive a staff change at all.
A unique, short, portfolio-wide account number costs nothing and removes all four failure modes. If you are on a till number today and cannot issue references at all, that limitation is the constraint to fix first. Paybill vs till number for collecting rent sets out the trade-off in full.
Everything above is what an M-Pesa rent collection system automates: payments matched on the account number as they arrive, allocated by your rule, receipted with the split visible to the tenant, and an unallocated queue somebody has to clear rather than a mystery nobody owns. The discipline is identical on paper. It just costs an afternoon a week instead of an hour.
Common questions
How do I reconcile M-Pesa rent payments automatically?
Give every tenancy a unique paybill account number, match incoming receipts on it, and apply each matched payment to specific charges by a stated allocation rule. Anything that does not match goes to an unallocated queue that is worked weekly rather than guessed at.
Why does an M-Pesa statement not say who paid?
It records the registered name on the paying SIM, which is frequently not your tenant: a spouse, an employer, a shop's phone. The account number is the only field that identifies the tenancy, which is why it has to be unique across the portfolio and printed everywhere.
Should I use a paybill or a till number for rent?
Paybill, for any portfolio past a handful of units, because a till number has no field for a reference and every payment then has to be identified by hand. The full comparison is in paybill vs till number for collecting rent.
What do I do with a payment I cannot identify?
Hold it as unallocated, with the transaction code, payer name, number and date recorded, and work the queue weekly. Unallocated is an honest state; guessing is how two accounts become wrong at once.
What if a tenant pays rent from another person's number?
Accept it, match on the account number, record the payer against the receipt, and note on the tenancy that payments arrive from that number. It is normal, and refusing it creates a problem where there was not one.
Who pays the M-Pesa transaction charges?
Whoever the tenancy says, and it should say. Book the charge as an expense rather than netting it against rent received, so the receipt shows the tenant the amount they actually paid.
How often should reconciliation be done?
Weekly. The cost of reconciling is roughly constant per payment, but the cost of investigating an unexplained one rises sharply with age. After a few weeks, nobody remembers, and after a few months, nobody is still there to ask.