A bank feed full of guesses
The accounts team opens the client account feed on rent day. Some payments have perfect references. Others say rent, or the tenant's first name, or a flat number without the street. Joint tenants pay their shares separately. A council pays housing support for several tenants in one lump. A guarantor pays from a different surname.
Each unclear payment is a small investigation, and until it is solved, the tenant shows as in arrears and the landlord's statement cannot be finished.
Why matching is so manual
Lettings software matches payments that carry the exact reference it expects. Anything else falls out. Yet most unclear payments follow patterns: the same tenant uses the same odd reference every month, the same guarantor pays from the same account, the council's remittance lists the tenants. That knowledge sits with the accounts person, not in the software.
| Payment type | Why it does not auto-match |
|---|---|
| Wrong or missing reference | Software needs an exact reference |
| Joint tenants paying separately | Amounts do not equal the rent |
| Guarantor or parent paying | Payer name differs from tenant |
| Council bulk payments | One payment covers many tenancies |
| Part payments | Amount does not match any tenancy |
What slow matching costs
Unmatched rent makes the arrears list wrong, so tenants who paid get chased, which is embarrassing and irritating for them. Landlord payments and statements wait until the matching is done. Client money reconciliation, which your business needs to keep in order under the rules that apply to it, becomes harder when money sits unallocated.
And the accounts person's first days of every month disappear into detective work.
The knowledge problem is real too. When the one person who knows that the payment marked DAD FLAT always belongs to a particular tenancy goes on holiday, the matching stalls or goes wrong. That knowledge should belong to the business, not live in one person's head, and it should survive staff changes.
How we build payment matching
- Bank data: payments are read from your client account through open banking, your bank's export, or your lettings software's bank feed.
- History-based matching: each tenancy's past payments teach the system its usual payers, references and amounts, so a payment that looks like last month's is matched with confidence.
- Remittance reading: council and third-party remittance advices, often PDFs by email, are read and used to split bulk payments across tenancies.
- Proposed matches: payments that are likely but not certain are proposed to a person with the reason shown, such as same payer as last three months.
- Allocation: confirmed matches are posted to the tenancy in your lettings software through its API or an import file.
- Unknowns queue: payments with no plausible match are listed for investigation, oldest first.
Every allocation records whether it was automatic or confirmed by a person, so your reconciliation has a clear trail.
What the accounts team gets back
Most payments allocate themselves. The accounts person reviews a short list of proposals and a shorter list of true unknowns. The arrears list is accurate on the morning after rent day, landlord statements go out on time, and client money reconciliation starts from correctly allocated money.
Tenants stop receiving reminders for rent they have already paid, which removes one of the more irritating conversations in lettings. Landlords receive their money and statements on the day they expect. And when a payment genuinely cannot be identified, it is investigated promptly while the payer still remembers sending it, rather than weeks later.
Does this sound like rent day?
- Rent payments with odd references are matched by hand.
- Tenants who have paid show as in arrears.
- Council remittances are split across tenancies manually.
- Landlord statements wait until matching is finished.