Property and Tenancy Management Platform
A property manager or landlord holding residential or commercial units across several buildings, tracking tenancies and rent in spreadsheets, handling maintenance by phone, and chasing arrears by memory.
The problem
A property portfolio is a set of dated obligations — rent due, tenancy expiring, notice periods, service charge, statutory documents — and every one of them is a date somebody has to remember.
In scope
- Property and unit register
- Tenancy lifecycle
- Rent invoicing and collection
- Arrears
- Maintenance
- Vendors
- Documents and expiry
- Service charge
- Owner reporting
- Tenant communication
Out of scope
- Sales and brokerage
- Property valuation
- Full accounting
- Construction project management
- Also out: tenant screening and credit checking, which depends on data sources that do not reliably exist here.
What this would cover
Grouped by module — open the ones you want to read.
Portfolio
- Properties, units within them, unit attributes, ownership where the manager acts for multiple owners
Tenancy
- Applicant to offer to agreement to occupancy to renewal or exit; term dates, rent, deposit, notice period, break clauses, escalation
Key dates
- Rent due, tenancy expiry, renewal window, notice deadlines, surfaced as a forward calendar rather than remembered
Rent invoicing
- Generated ahead of the due date, itemised where service charge or utilities are separate, with the annual-payment convention common in this market handled as a first-class case rather than an exception
Collection
- Cash, transfer with reference, POS; bank statement import and matching against outstanding invoices; unmatched payments held in a queue
Arrears
- Ageing by tenant, property and owner; escalation stages recorded; every reminder logged against the tenancy
Deposits
- Held, tracked separately from rent, with deductions itemised and evidenced at exit
Maintenance
- Request intake, assignment to internal staff or vendor, quote, approval against a threshold, cost recorded against the unit, resolution and tenant confirmation
Vendors
- Contractors with trades, rates, job history and payment status
Documents
- Tenancy agreements, receipts, certificates, insurance, with expiry alerting for anything dated
Service charge
- Budget, apportionment across units by a stated basis, billing, and reconciliation against actual spend at year end
Owner reporting
- Income, expenditure, arrears and occupancy per owner, per property, on a schedule
Tenant communication
- Notices, reminders and announcements, with delivery status and a log against the tenancy
Access control
- Owner, portfolio manager, property officer, accounts, maintenance coordinator
What it would look like
Concept mockup — an illustrative interface, not a built system.
96%
Occupancy
₦3.6m
Arrears total
4 units
Under maintenance
| Tenant | Unit | Overdue | Status |
|---|---|---|---|
| O. Bassey | Flat 2A | ₦0 | |
| N. Ibe | Shop 3 | ₦480,000 | |
| K. Danladi | Flat 9C | ₦120,000 |
Data model
- Property → Unit
- Owner
- Tenant → Tenancy → TenancyTerm
- Invoice → InvoiceLine → Payment → Allocation
- Deposit → Deduction
- MaintenanceRequest → Job → Vendor → Cost
- Document → ExpiryAlert
- ServiceChargeBudget → Apportionment
- Message → DeliveryStatus
Invariants
- A unit cannot hold two overlapping active tenancies — enforced at the data level, because the double-let is this domain's equivalent of the double-booking.
- Deposit funds are tracked separately from rent and are never allocated to arrears without a recorded authorisation.
- A payment is recorded before it is allocated; unmatched money sits in a queue rather than being guessed at.
- Tenancy terms are versioned — a renewal creates a new term rather than editing the old one, so history survives a dispute.
- Service charge apportionment basis is stored with the budget, because the basis is what gets challenged.
Offline behavior
Maintenance inspection and job updates should work offline on a phone at a property. Financial recording requires connectivity.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
Annual rent payment, which is the norm for much of this market, breaks the monthly-cycle assumption that almost all property software is built on.
A tenant paying a year ahead is not in arrears for eleven months and then suddenly due; the system must model the obligation, the payment and the coverage period as distinct things. Getting this wrong produces arrears reports that are nonsense, and it is the specific reason imported property software fits badly here.
Tenancy law varies by state and affects notice periods, deposit handling and recovery procedure.
The system stores the terms and the dates; it does not advise on what is lawful. [FILL: confirm the applicable state tenancy law for the client's portfolio — Lagos, Rivers and others differ materially — and whether Afivox will encode notice-period defaults at all, or leave them entirely configurable.]
End state
What would be true about their day once this is running.
- Every unit's tenancy status, term dates and rent position are current and visible.
- Renewals and notice deadlines arrive as a forward calendar rather than a surprise.
- Payments are matched and receipted, and money that cannot be identified sits visibly in a queue.
- Deposits are held separately with evidenced deductions.
- A maintenance request has an owner, an approved cost and a resolution.
- Owners receive scheduled statements generated rather than assembled.
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