Rent by bank transfer: matching money to the right invoice

Cheques are still the rail this region runs on, but the share arriving as bank transfers rises every year — faster in Saudi Arabia than anywhere else, and fastest among corporate tenants and residents who bank on their phones. Operators tend to welcome it, because a transfer cannot bounce, cannot be lost in a drawer and does not have to be physically carried to a branch.

Then the first month arrives and the actual problem shows up. The money is in the account. Nobody knows whose it is.

The payment arrives without a name attached

A bank statement line is a much thinner record than people assume. What reaches the landlord is an amount, a date, a counterparty name as the sending bank chose to render it, and a narration field that has usually been truncated somewhere along the way.

In a residential portfolio the sender is frequently not the tenant at all. It is their employer settling rent as a benefit, their spouse, a relative, a company they own, or an exchange house whose own name is on the transfer. Corporate tenants pay from a treasury account bearing a group name that appears nowhere on the lease.

• The name on the transfer is the account holder, not the person who owes the rent.
• Narration is truncated, often to well under the length the sender typed.
• Arabic in a narration field may arrive transliterated, reordered, or as question marks.
• A single transfer may cover two units, or two tenancies, or a unit and a service charge.
• The amount rarely matches an invoice exactly once bank charges have been taken.

None of this is exotic. It is the ordinary case, and any process built on "the finance team will recognise the name" fails in the first month at any portfolio above a few dozen units.

A reference only works if it survives the journey

The fix everyone reaches for is a payment reference, and it is the right fix — but only if it is designed for the channel it has to travel through. A reference that gets cut off, that a tenant mistypes, or that cannot be told apart from a similar one is worse than none, because it produces confident wrong matches instead of an obvious unknown.

What works is short, unambiguous, and printed everywhere the tenant will look for it: on the invoice, in the reminder, in the portal, and on the contract itself.

• Keep it under about twelve characters. Assume the field is shorter than the bank claims.
• Latin letters and digits only, upper case. No spaces, no dashes, no Arabic.
• Drop the characters that get confused when read off a screen and typed into a phone — the letter O against zero, I and l against one.
• Add a check character. It turns a mistyped reference into a rejected one instead of a match against somebody else’s tenancy.
• Key it to the tenancy, not to the invoice. A tenant paying two months at once should not have to send two transfers.

Matching, and the queue that matters

With a reference in place, most transfers match themselves. The interesting design question is what happens to the rest, and the honest answer is that a portion will never match automatically, so the exception queue is not an edge case — it is a permanent part of the workflow and deserves to be built like one.

A workable matcher runs in order: exact reference, then exact amount against an open invoice for a tenancy whose expected payer name resembles the sender, then nothing. "Then nothing" is important. A near-match posted automatically to the wrong tenancy creates two problems where there was one, and it is discovered a month later when someone chases a tenant who paid.

• Match on the reference first, and only on an exact reference.
• Fall back to amount plus payer name, and present it as a suggestion for a human to accept.
• Record the payer name the bank actually sent, against the tenancy, the first time a human resolves it — the second transfer from that employer then matches itself.
• Leave everything else unallocated and visible. Money sitting in a suspense account with an owner is fine; money silently attached to the wrong lease is not.

Part payments, overpayments, and where they go

A tenant who owes 30,000 and sends 12,000 has not paid an invoice. They have made a payment on account, and the difference matters to the books, to the arrears report and to any late-fee policy running against the balance.

The allocation rule has to be stated once and applied everywhere, because an operator who allocates by instinct produces a ledger nobody can reconcile. Oldest invoice first is the usual convention and the one most systems should default to, with an explicit override when the tenant has said what the payment is for. What must not happen is a payment spread proportionally across everything open, which is tidy on screen and impossible to explain in a statement.

• Record the payment at the amount received, not the amount invoiced.
• Allocate oldest first by default; allow an explicit allocation when the tenant names an invoice.
• Leave any remainder as a credit on the tenancy rather than forcing it onto an invoice.
• Keep the allocation reversible, with the reversal recorded — corrections are entries, not edits.

Bank charges are the quiet version of this. A transfer sent for the exact invoice amount arrives short because an intermediary took a fee, and the invoice is left with a few hundred outstanding. Whether the tenant or the landlord bears that has to be a contract term, not a monthly argument, and the shortfall has to be visible rather than written off by whoever noticed it.

Cross-border, currency, and the amount that changes in flight

A portfolio in this region has tenants paying from outside it — an owner in London, a family member in Cairo, a company settling from a dollar account. Two things then move: the amount, because of the rate applied on the day, and the timing, because a cross-border transfer takes days rather than minutes.

The rule that keeps this sane is to invoice in the currency of the lease and record the payment in the currency it arrived in, with the rate and the difference stored on the transaction. Converting at read time produces a statement whose totals change depending on when it is printed, which is the single fastest way to lose a tenant’s confidence in an account.

What the tenant should see

Everything above is invisible to the person paying, and it should be. What they need is small: the account details, the reference, the amount, and confirmation that their money arrived and what it was applied to.

That last part is worth more than it looks. Most chasing calls in a well-run portfolio are not about unwillingness to pay — they are about a payment that was made and cannot be seen. A portal that shows a transfer landing, and the invoice it settled, removes an entire category of phone call and an entire category of dispute.

Running both rails at once

For the foreseeable future most portfolios here will hold cheques and receive transfers for the same tenancy, sometimes in the same year — four cheques at signing and a transfer when one of them is replaced.

That is manageable as long as both settle into one receivables position per tenancy rather than two parallel records. A cheque cleared and a transfer received are the same event to the ledger: money in, allocated to an invoice. The instrument is an attribute of the payment, not a separate accounting universe — and a system that models it as two worlds will produce two different answers to "what does this tenant owe".