Month end, one account at a time
Your accounts team reconciles a separate bank account for every block. For each one they download the statement, import it, and start matching. Most payments are fine. Then comes the one with the reference 'FLAT', the one where a leaseholder paid two quarters at once, the one from a letting agent covering five flats in different blocks, and the direct debit that bounced.
Multiply that by the number of blocks, and month end becomes a week of matching payments while property managers wait for accurate balances to chase arrears.
Why bank rules do not solve it
Bank feed rules match on reference or amount. Leaseholders use inconsistent references, pay odd amounts, combine payments and pay from accounts in other people's names. Letting agents pay for several landlords at once. The rules catch the easy ones and leave the rest.
The information needed to match the hard ones, such as who usually pays for a flat, what they owe and what was demanded, sits in your block management system, not in the bank feed.
What slow reconciliation costs
Arrears lists are wrong until reconciliation is finished, so reminders go to leaseholders who have paid, and those who have not are chased late. Unallocated receipts sit in suspense. Month end reports to directors are delayed. And the accounts team spends its most valuable time on matching rather than on checking and advising.
The reconciliation layer we build
We build a matching layer that uses your own records and history to propose matches, leaving your accounts team to review exceptions. It supports your controls; it does not replace them.
- Statement import: statements for every block's account are collected through bank feeds or file downloads into one place.
- Receipt matching: each receipt is compared with the block's leaseholders, outstanding demands, known payer names and previous payments. The best match is proposed with a confidence level and the reason.
- Split and combined payments: payments covering several flats or several periods are proposed as splits for a person to confirm, based on what is outstanding.
- Payment matching: outgoing payments are matched to approved invoices and payment runs from your block management system.
- Posting: confirmed matches are written back to your block management system through its API or a prepared import.
- Exceptions list: unmatched and low confidence items across all blocks appear in one list, sorted by value and age, with suggestions where there are any.
| Receipt type | How it is matched | Reviewed by a person? |
|---|---|---|
| Correct reference and amount | Direct match | Spot-checked |
| Poor reference, known payer | Payer history and outstanding demand | Only if confidence is low |
| Several flats in one payment | Proposed split from outstanding balances | Always |
| Unknown payer | No match proposed | Always, in the exceptions list |
Month end afterwards
Most receipts are matched before anyone opens the accounts. The team spends its time on a single exceptions list covering every block rather than working through dozens of statements. Arrears are accurate sooner, so chasing starts on time and goes to the right people.
Does this describe your month end?
- You reconcile a separate bank account for each block.
- Leaseholder payments often arrive with unhelpful references.
- Letting agents pay for several flats in one transfer.
- Arrears lists are unreliable until reconciliation is finished.
- Unallocated receipts sit in suspense for too long.