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.
This is what we'd build. Yours will look a little different.
Every concept on this page changes once we sit with how your operation actually runs. Tell us what's different about yours.
Start the operations review