Flat and unit management software
The record every other module reads from: who owns each flat, who lives in it, what is attached to it, and what has changed since. Get this right and everything downstream is right.
Flat and unit management software keeps one registry of every unit with its owner, tenant, occupancy status, area, parking entitlement and documents. Ownership history is retained, custom fields capture society-specific rules, and existing data imports in bulk from Excel.
Your single source of truth for every flat
Almost every operational failure in a society traces back to disagreement about a flat. The gate believes a tenant lives there; billing still has the previous owner; the complaint goes to a phone number that stopped working two years ago; the AGM notice is served on somebody who sold in 2023. Each system holds its own copy of the same fact, and the copies drift.
The drift is not caused by carelessness. It is caused by there being four places to update and no single act of updating. When a flat is sold, somebody has to remember to change it in the billing sheet, the gate app, the member register and the WhatsApp group. In practice two of the four get done.
A unit registry is the fix, and it is unglamorous: one record per flat that everything else reads. It is the least visible module in the platform and the one whose quality determines whether any of the others work.
- Four copies means four truths. Every additional place a flat is recorded is another place it goes stale.
- Transitions are where data rots. Sales and tenancy changes are the events that break the record.
- Bad registers break notices. Serving an AGM notice on a former owner is a procedural defect, not a clerical one.
Key capabilities
A record per flat, the people attached to it, and the history of both.
Unit master with ownership history
Each unit carries its identifiers and physical facts — tower, wing, floor, flat number, carpet and built-up area, unit type — and its current owner of record with share certificate details and nomination.
Ownership history is retained rather than overwritten. When a dispute concerns a period three owners ago, or when arrears predate a sale, the register can say who held the flat and when. Overwriting the owner on a sale destroys exactly the information a dispute later needs.
Owner and tenant records
Owners and tenants are separate records against the unit, both with contact details, identification and their own app access. A flat can be owner-occupied, tenanted, or vacant, and the record says which.
That distinction drives real behaviour. Non-occupancy charges apply to tenanted flats; AGM notices and votes go to the owner; a complaint about a leaking tap goes to whoever lives there. Systems that model only "the resident" get all three wrong.
Occupancy and rental status
Occupancy status is maintained with dates — owner-occupied from, tenanted from, vacant since — and the tenancy carries its agreement period, rent, deposit and police verification status.
Expiring tenancies surface in advance, which matters both for the owner and for the society: an expired leave-and-licence agreement whose occupant is still in place is a compliance gap that most societies discover only during an inspection.
Documents attached per unit
Sale deed, share certificate, leave-and-licence agreement, police verification, NOCs, handover documents and inspection reports attach to the unit, with the ones that expire carrying their dates.
Because documents live on the unit rather than in a folder tree, they transfer with it. A new owner’s file starts with the property’s own history rather than with whatever the previous owner happened to hand over.
Custom fields for your rules
Societies differ in ways no fixed schema anticipates — a corpus contribution status, a wing-specific levy category, a heritage or PMAY classification, membership of a sub-association. Custom fields hold those without a code change.
Custom fields can drive billing and reporting, which is what makes them worth having rather than being a notes box. A field marking a flat as exempt from a particular head can be the basis for how it is billed.
Bulk import from Excel
Existing data — almost always a spreadsheet — imports through a guided mapping with validation. Duplicates, flats with no recorded owner and area figures that do not reconcile are surfaced during import rather than discovered later.
That validation pass is usually the most valuable hour of an implementation. Most societies find their register has real problems in it, and finding them during import is considerably better than finding them during an AGM notice run.
How it works
The import validation is where the existing register’s real condition becomes visible.
Who it helps
Nobody asks for a unit registry. Everybody suffers when it is wrong.
What a change to the unit record sets off
This is the point of a single registry: one update, and everything that depends on it follows.
| Event | What changes on the unit | What follows automatically |
|---|---|---|
| Flat sold | New owner of record; previous owner moved to history | Billing, notices and voting move to the new owner; old passes lapse |
| Tenant moves in | Tenancy record opened with dates and agreement | Non-occupancy charge applies; tenant gets app access and passes |
| Tenant moves out | Tenancy closed; occupancy set to vacant | Access and passes revoked; deposit settlement raised |
| Parking reallotted | Slot allotment updated with date and basis | Parking head on the bill follows the new allotment |
| Nomination filed | Nomination recorded against the member | Statutory register updated for inspection |
Works with the rest of KeyMatrix
Every other module resolves against this record. Billing knows the area and the occupancy that decide the charge. The gate knows who lives there and whose passes are valid. Governance knows who is entitled to notice and to vote. Helpdesk knows which flat a complaint came from and its history.
That is why transitions are handled here rather than in each module. A sale updates ownership once, and billing, notices, voting rights, gate passes and parking entitlement all follow — because they were never separate facts to begin with.
- Billing. Area, occupancy and entitlements decide what each flat is charged.
- Visitor management. Passes and approvals follow the current occupant.
- AGM and governance. The member register served with notices is this register.
- Move-in and move-out. Transitions are recorded here and propagate outward.