Rent Collection and Reconciliation
A landlord or manager with a few dozen units, where rent arrives by transfer to a personal or company account, identification is by memory, and arrears are established by argument.
The problem
The money arrives. Matching it to a unit and a period is manual, receipts are issued inconsistently, and by the time arrears are noticed they are months old.
In scope
- Tenancy and rent schedule
- Invoicing
- Payment recording
- Statement import and matching
- Receipting
- Arrears and escalation
- Renewal reminders
Out of scope
- Maintenance
- Vendors
- Service charge
- Owner reporting
- Document management
- This is the money half of the Property and Tenancy Management Platform, standalone.
What this would cover
Grouped by module — open the ones you want to read.
Tenancy register
- Unit, tenant, term dates, rent amount, payment frequency, escalation
Rent schedule
- Obligations generated forward from the tenancy, handling annual, biannual and monthly conventions as first-class cases
Invoicing
- Issued ahead of the due date, itemised, delivered by message
Payment recording
- Cash, POS, transfer with reference as typed
Statement import
- Upload the bank statement, match on exact reference, then on amount against outstanding obligations, then on sender name against tenant names; unmatched to a holding queue
Holding queue
- Money received and unidentified, never discarded, cleared manually
Receipting
- Automatic on allocation, delivered to the tenant, which removes most payment disputes
Arrears
- Ageing by tenant and property, escalation stages with recorded reminders, so a recovery position is evidenced rather than asserted
Renewal reminders
- The expiry calendar, because an unrenewed tenancy quietly continuing is the most common avoidable loss in this business
Data model
- Unit
- Tenancy → RentSchedule → Obligation
- Invoice → Payment → Allocation
- BankImport → ImportLine
- ArrearsStage → Reminder
- Receipt
Invariants
- An obligation, a payment and the period it covers are three distinct records — collapsing them is what breaks annual-payment handling.
- Payment precedes allocation; unmatched money is held, never deleted.
- A unit cannot have overlapping active tenancies.
- Reminders are logged against the tenancy with their date and channel, because that log is the evidence in a recovery.
Offline behavior
Not required.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
Transfer matching cannot be fully automated here either, and the volume is lower but the amounts are larger.
A tenant paying a year's rent from a relative's account with no reference is unidentifiable by algorithm. The system narrows it to a short queue. The difference from the school case is that a single unmatched rent payment is a large sum and a serious dispute, so the holding queue must be worked promptly — which is a process commitment, not a feature.
Landlords frequently collect to personal accounts mixed with personal money.
Statement import over a mixed account produces noise and a privacy problem. The honest recommendation is a dedicated account before the system, and some clients will refuse.
End state
What would be true about their day once this is running.
- Every unit has a rent schedule generated forward, invoiced before the due date.
- Payments are matched, allocated to the period they cover and receipted automatically.
- Unidentified money is visible in a queue.
- Arrears are aged with an evidenced reminder history.
- Renewals appear on a calendar before the term ends.
This is a deliberate first step toward Property and Tenancy Management Platform — its data model is designed as a genuine subset, so growing into it later doesn't mean starting over.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review