Some payments arrive with no reference, a wrong reference, or from a number nobody recognises. A tenant paying from a relative's phone is extremely common and entirely innocent. Somebody transposing two digits of a unit code is common and innocent. A payment for a different property entirely, sent to the wrong paybill, happens too.
The money is real. It has arrived. It belongs to somebody. Until you know who, it is unallocated.
It is a liability, not income
This is the part that gets handled wrongly. Unallocated money is not yours. It is a sum you are holding on behalf of a person you have not yet identified, and it sits on the books as a liability until it is resolved.
Two consequences follow:
It must not be guessed onto an account. Crediting it to the tenant it "probably" belongs to produces a receipt that is wrong on the day it is issued, and the tenant who received an unearned credit has no reason to tell you.
It must not be left out of the books because it is awkward. Money received and not recorded is the single worst state, because the person who paid it has a transaction code and you have nothing.
It inflates arrears, which is how it gets noticed
A portfolio holding KES 340,000 of unallocated receipts is reporting KES 340,000 of arrears that has, in fact, been paid. The arrears report is wrong, the tenants concerned are being chased for money they sent, and the first person to discover the error is a tenant with a receipt.
That is why the unallocated balance belongs on the management report next to arrears rather than buried. It is arrears' mirror image: money you hold that you have not credited to anyone.
Running the queue properly
- 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 what happens to it is a decision, recorded, made by a named person, not a rounding.
Three states that get confused
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 creating a charge manually to absorb it, 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.
Reducing the volume at source
Most unallocated payments are a reference problem rather than a reconciliation problem. A unique, short account number per tenancy, unique across the whole portfolio rather than per block, printed on every bill and repeated in every reminder, removes most of the queue before it forms.
Where collection is on a till number rather than a paybill, the payer cannot give a reference at all, because there is no field for one. That is a constraint to fix rather than a queue to work.