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.
Why every system in a society disagrees about the same 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 — and serving an AGM notice on a former owner is a procedural defect, not a clerical one.
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.
What one unit record holds
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, kept separate
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, with dates
Occupancy 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. 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 they 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.
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, and they can drive billing and reporting: a field marking a flat as exempt from a particular head can be the basis for how it is billed.
What happens to a unit’s data when the flat is sold or let
Billing, the gate, notices and voting all read this record, so a transition is recorded once and everything that depends on it follows — they were never separate facts to begin with.
| 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 |
Bulk import from Excel, and what it usually finds
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 before anything is committed, 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. Once the units are in, owners, tenants and documents are linked to each one with occupancy dates and expiries recorded.