Databus Logo
Blog Login →
Property Unit Database Software for Indian Societies

Three towers. Eleven Excel sheets. One question nobody can answer.
Who actually lives in Flat 1204?

EstateDeck Unit Management is the canonical master database for every flat in your society — owner, current tenant, parking slot, occupancy state, family members, vehicles. One source of truth that every other EstateDeck module reads from and writes back to.

Aligned with state Apartment Ownership Acts · Multi-phase societies · Ownership history forever · IT Act §65B-admissible.

See the data model →
In plain English

EstateDeck Unit Management is the canonical master database for an Indian housing society or apartment owners' association. It holds, for every flat, the structural location (Phase → Tower → Floor), the unit attributes (carpet area, type, share certificate number per state AOA), the current legal owner and the complete ownership history, the tenant overlay where applicable, the parking slot deeded to the unit, the registered vehicles, and the family roster. The unit master is the single source of truth that every other EstateDeck module reads from — billing, accounting, documents, move-in/out, ANPR, smart meters. Database records are admissible as electronic evidence under IT Act 2000 §65B.

1
Source of truth across
every EstateDeck module
8+
State Apartment Ownership
Acts schema-aligned
5-level
Hierarchy supported
Phase → Block → Tower → Floor → Unit
§65B
IT Act 2000 admissibility
for every database edit
A real canonical unit record

This is what one flat looks like in the database.

Mr. Pradeep Banerjee runs a 3-phase, 720-flat AOA in Kolkata's Rajarhat. Here's the canonical master record for Flat B-704 (Phase 2) — every field linked to every other module that touches it.

/units/greenview-p2-b-704 Canonical record
Structural
PhasePhase 2 (handover 2019)
Tower / Floor / UnitB / 7 / 04
Type3BHK · East-facing
Carpet area (RERA)1,180 sq ft
Built-up area1,420 sq ft
Share certificate#0247 (WB AOA 1972)
Ownership history
Current ownerBhattacharya, Rajesh
Co-ownerBhattacharya, Anita
Acquired12-Jun-2019 (sale)
Previous ownerSengupta, S. · 2015-2019
Original allotmentBuilder · 02-Aug-2014
Occupancy + tenant
StateRented
TenantMukherjee, Rohan + 3
Lease window01-Jan-24 → 31-Dec-26
Parking + vehicles
Slot B1-204Covered (deeded)
↳ VehicleMaruti Brezza · WB-12-MK-2241
Slot B1-S07Scooter bay (deeded)
↳ VehicleHonda Activa · WB-12-AB-7732
Cross-module references
Billing ledger→ /billing/ (₹8,420 due)
Lease PDF→ /document-repository/
Move-in event→ /move-in-out/ (28-Dec-23)
Smart meter→ /iot-utility/
ANPR allow-list→ /anpr/ (2 vehicles)
One record. Every module references it. Update the owner here, and billing, accounting, ANPR, and the lease vault all see the change in the same transaction. Audit log preserved forever, §65B-admissible.
What happens without a real master database

Four things every Hon. Secretary has lived through.

The "which is the latest" Excel

Members_2023.xlsx · Members_2024_final.xlsx · Members_2024_final_v2_REAL.xlsx · Members_Phase2.xlsx. Three towers, eleven sheets, last reliably updated by a Hon. Secretary who left in 2022.

The phantom owner

Flat 1204 has a tenant in the gate register, a different name in the billing list, and a third name on the AGM voting list. All three are wrong. The actual owner moved to Singapore in 2021.

Disputed parking slot

Slot B1-204 belongs to Flat 402, per the sale deed. The current resident parks there, but they moved into Flat 904 — and 402's owner is in Dubai. The dispute lands on the AGM agenda every year.

The 2019 vehicle still on the allow-list

The previous tenant's car drove out of the gate three years ago and never came back. The RFID tag still works because nobody updated the registered-vehicle list. The new tenant's car is parked outside the gate.

What this module owns · what it deliberately doesn't

Unit Management is the spine.
Every other module is a vertebra hanging off it.

EstateDeck is built as a set of focused modules. Unit Management holds the canonical master data — but it deliberately does not generate invoices, store PDFs, or run physical move events. Each of those lives in its own neighbouring module so the boundaries stay clean.

This module owns

  • Canonical unit master record — Phase, tower, floor, unit number, carpet / built-up area, type, share certificate.
  • Legal owner registry — current owner, co-owner, mobile, email, KYC status.
  • Ownership history timeline — every previous owner with sale dates and source-of-title.
  • Tenant overlay — current tenant, lease window, family roster, when applicable.
  • Occupancy state flag — self-occupied / rented / vacant / litigated.
  • Canonical parking ownership DB — slot deeded to unit, not to person.
  • Registered vehicle list per unit — make, model, registration number, slot allocation.
  • Family / sub-member registry — spouse, children, dependants under the primary unit.

This module defers to

  • The physical move event itself — condition photos, inventory, meter snapshot, deposit refund — lives in EstateDeck Move-In/Out. We write the post-event state change here; the workflow lives there.
  • Sale deed PDF, lease agreement PDF, share certificate PDF, police verification PDF — live in Property Document Repository, per-unit folder. We link by unit ID; we don't duplicate storage.
  • The gate auto-open vehicle allow-list mechanism, RFID dispatch, ANPR camera read — lives in EstateDeck ANPR. We hold the registered vehicle list; ANPR builds the gate allow-list from it.
  • Maintenance invoice generation, late fees, DLT SMS reminders — lives in Maintenance Billing. Billing reads owner and carpet area from us; it doesn't keep its own copy.

The structure: hierarchy + attributes

Hierarchy

5-level structural hierarchy

Model your society exactly as it exists — not a simplified version.

  • Phase → Block → Tower → Floor → Unit: Multi-phase complexes get distinct registration dates, bye-laws, and share certificate series per phase.
  • Commercial + mixed-use: Ground-floor shops, basement office, café — all addressable as units with their own billing rules.
  • Custom sub-types: Penthouse, duplex, studio, service apartment, EWS — flag each unit's sub-type for differentiated billing.
  • Future-proof slots: Reserve unit numbers for Phase 4 even before it breaks ground.
Unit attributes

Unit attributes that drive billing

Carpet area, built-up area, share certificate — the data that downstream modules need.

  • RERA-anchored carpet area: Per the unit's RERA-registered carpet area (where applicable). Drives sq-ft-based billing in Billing.
  • Share certificate per state AOA: Number format follows the registered Apartment Ownership Act of your state.
  • Built-up vs super built-up: Track both for clarity at sale and for tax reporting.
  • Possession date: When the unit was handed over by the builder — drives the start of maintenance obligations.

The people: owners, tenants, families

Owner registry

Owner registry + ownership history

Every legal owner. Every previous owner. Every sale date. Forever.

  • Current owner record: Name, mobile, email, masked Aadhaar (XXXX-XXXX-1234) per UIDAI, PAN, KYC status.
  • Co-owner support: Joint ownership per Transfer of Property Act 1882 — both get logins, both bound by obligations, voting rights per bye-laws.
  • Ownership history timeline: Previous owner, sale date, source of title (sale deed, gift, inheritance). Never overwritten — archived forever.
  • Ownership transfer workflow: Sale, gift, inheritance — each preserves the historical record while activating the new owner.
Tenant overlay

Tenant overlay + family roster

When the unit is rented, the tenant sits on top — the owner record stays.

  • Tenant as overlay, not replacement: Owner record unchanged. Tenant added with lease start, lease end, family roster.
  • Scoped access: Tenant can use amenities, raise tickets, pay rent — but cannot vote at AGM or edit unit core data.
  • Family roster: Spouse, children, dependants — under the primary unit profile, each with their own app access if needed.
  • Auto-archive on lease end: When the lease window closes, the tenant overlay archives and owner reclaims full control.

The parking + vehicles

Parking ownership

Canonical parking ownership DB

The slot is deeded to the unit. Not to the person. End-of-story.

  • Slot ↔ unit mapping: Slot B1-204 is permanently linked to Unit B-704. Owner changes; slot stays with the unit.
  • Deeded vs assigned: Deeded slots are part of the sale deed. Assigned slots are committee-allocated and revocable.
  • Slot types: Covered, open, scooter bay, EV-charging-ready, visitor zone, disabled-priority — each tagged and counted.
  • Slot-to-tenant access: When the unit is rented, tenant uses the slot but doesn't own it. Lease end → access ends.
Vehicle registry

Registered vehicle list per unit

The master list of cars and bikes — read by ANPR for the gate allow-list.

  • Per-unit vehicle limit: Configure per bye-laws — 2BHK = max 1 car, 3BHK = max 2 cars, plus 1 scooter each. Enforced at registration.
  • Make, model, registration: Stored against the unit; tagged with the deeded slot.
  • Read by ANPR: The EstateDeck ANPR module builds its gate allow-list from this registered list. Add a car here, gate opens for it.
  • Auto-deactivate on tenant exit: When the tenant overlay archives, their personal vehicles unlink from the gate allow-list automatically.

Operations: import, search, audit

Bulk import

Bulk import + universal search

Move from eleven Excel sheets to one database in one afternoon.

  • Standardised import template: One Excel template, one row per unit, columns matching the unit master schema.
  • Pre-commit validation: Duplicate owners flagged, parking-slot collisions flagged, lease-window overlaps flagged — fixed before commit.
  • Universal search: Search by name, mobile, vehicle registration, parking slot, share certificate, or unit number — all in one box.
  • 1,000-unit migration: Typical onboarding for a 1,000-unit society takes one afternoon plus a validation pass the next morning.
Audit log

Self-service edit + database audit log

Less committee work. More accuracy. Full audit trail.

  • Resident self-edit (non-critical fields): Mobile, email, family names, vehicle list — resident updates directly. Saves committee time.
  • Committee-only fields: Owner name, ownership date, share certificate, parking slot — only Hon. Secretary or Property Manager can edit.
  • Per-edit audit: Who changed what field, when, from which device. Immutable. Retained for lifetime of subscription.
  • §65B-admissible: Audit log qualifies as electronic record under IT Act 2000 §65B — usable at Co-op Society Registrar audit, consumer court, civil suit.
Three society profiles, one canonical record

Whatever your scale, the database schema fits.

EstateDeck Unit Management is in production with three distinct society structures. Pick the closest to yours.

Single building CHS

60–150 flat cooperative society

One tower, simple hierarchy, single registered bye-law. Owners are members of one cooperative; tenants come and go. Used by the Hon. Secretary as the central source of truth that the rest of the committee references daily.

Multi-phase complex

3-phase, 500–1,200 flat AOA

Phase 1 built in 2017, Phase 2 in 2019, Phase 3 in 2022 — each phase has its own registered AOA, its own bye-laws, its own share certificate series. Unit Management holds the spine; phase-level configurations layer on top.

Portfolio property manager

Multi-property PM, 200–2,000 units

Property Manager runs 8–15 different societies under one EstateDeck account. Each society has its own unit master with its own statutory framework; PM gets a portfolio-level dashboard showing occupancy, owner-change trends, and tenant churn.

The Indian legal frame this is built on

State Apartment Ownership Acts define what a unit legally is. We respect those definitions.

Maharashtra AOA 1970 + MOFA 1963

The Maharashtra Apartment Ownership Act 1970 defines the "deed of apartment" framework. The earlier Maharashtra Ownership of Flats Act 1963 (MOFA) still governs builder-to-buyer sale obligations. EstateDeck's unit schema captures both the apartment-deed structure and the share certificate per MCS Act 1960.

West Bengal AOA 1972

The West Bengal Apartment Ownership Act 1972 governs unit ownership in Kolkata and across the state, alongside the WB Co-operative Societies Act 2006 for CHS-registered societies. Share certificate format follows the WB registration requirements.

Karnataka AOA 1972 + KAOA

The Karnataka Apartment Ownership Act 1972 — for KAOA-registered Bengaluru apartment complexes (also registrable under Section 8 of the Companies Act 2013 for non-profit AOAs). EstateDeck supports both registration paths.

Tamil Nadu AOA 1994

The Tamil Nadu Apartment Ownership Act 1994, applicable across Chennai, Coimbatore, Madurai, and the rest of the state. Defines unit boundaries and common-area share — both captured in the EstateDeck unit master.

Delhi AOA 1986 + Haryana AOA 1983 + UP Apartment Act 2010

North India's three primary AOAs — covering Delhi NCR, Gurugram, Faridabad, Noida, Greater Noida, and Lucknow. Each defines apartment unit + undivided share in common area + AOA-level governance. EstateDeck applies the configured framework per society.

Transfer of Property Act 1882 + Stamp Act 1899

Sections 54-58 of the Transfer of Property Act define sale and sale deed requirements. The Indian Stamp Act 1899 (state-specific rates) governs stamp duty on the deed. Both are referenced when EstateDeck runs the Ownership Transfer workflow.

From the field

Rajarhat, Kolkata · 720 flats · 3 phases · 16 months in.

"Before EstateDeck, I had a Google Drive folder with eleven Excel sheets — one per tower, plus a master that nobody trusted. When the Phase 2 AGM came up in 2024, three different members produced three different voter lists. We had to postpone by a week. After we migrated to Unit Management, the AGM voter list comes off the same database that the billing list comes off, that the parking allocation comes off, that the gate allow-list comes off. Owner moved? One edit. Tenant changed? One overlay. Sale completed? One transfer workflow, full history preserved. Sixteen months in, I haven't opened a single Excel sheet for a member record."
Mr. Pradeep Banerjee Hon. Vice-President · Greenview Riverside AOA · 720 flats · 3 phases · 10 towers
New Town, Rajarhat, Kolkata-700156, West Bengal · WB Apartment Ownership Act 1972
Migrated to EstateDeck Unit Management · 16 months production · 720 unit master records · 11 Excel sheets retired
Side by side

Excel sheets vs basic ERP vs EstateDeck Unit DB

What you need Excel sheets Basic ERP "members" table EstateDeck Unit Database
Single source of truth 11 versions exist Only owner record Owner + tenant + parking + vehicles
Ownership history Overwritten on sale Lost on transfer Preserved forever
Parking ownership Separate sheet, unlinked Not modelled Deeded to unit, follows ownership
Tenant overlay Overwrites owner Overwrites or no tenant model Overlay — owner record preserved
Multi-phase support Separate folders Usually flat 5-level hierarchy native
Other modules read it Manual copy-paste Limited integration Every module reads live
Edit audit trail None Basic §65B-admissible full log
State AOA-aligned schema Ad-hoc Generic Per state AOA framework
Quick answers

Unit database software, asked and answered.

The questions every Hon. Secretary, Hon. Vice-President, and Property Manager asks before consolidating eleven Excel sheets into a real database.

What is a property unit database for a housing society?
A property unit database is the canonical master record of every flat in a housing society — its structural location (Phase / Tower / Floor), its attributes (carpet area, unit type, share certificate number), its current legal owner, the tenant overlay where applicable, the parking slot deeded to it, and the registered vehicles. EstateDeck Unit Management is the single source of truth that every other module — billing, accounting, document repository, move-in/out, ANPR, smart metering — reads from instead of holding its own duplicate copy.
How is this different from the EstateDeck billing or accounting modules?
Unit Management holds the master data — who owns Flat 1204, who rents it now, which parking slot belongs to it. EstateDeck Billing reads that data to generate the monthly maintenance invoice (₹X based on carpet area, addressed to the current owner). EstateDeck Accounting reads the same data to post the invoice to the ledger. The two financial modules do not duplicate the unit master; they reference it. When you update the owner here, billing and accounting see the change immediately.
How does parking ownership work — who owns the slot?
In Indian apartment law, the parking slot is typically deeded to the unit, not to the owner personally. EstateDeck records the slot as belonging to Unit B-704; when the unit changes ownership, the slot follows. If the unit is rented, the tenant inherits use of the slot but not ownership. If a neighbour wants to rent a vacant slot short-term, that listing is created in EstateDeck Delivery & Classifieds; the underlying ownership record stays here. The gate's auto-open allow-list for vehicles lives in EstateDeck ANPR — we maintain the registered-vehicle list; ANPR maintains the gate mechanism.
Can we manage multi-phase societies with different bye-laws per phase?
Yes. A common pattern in Indian gated communities is one builder shipping Phase 1 in 2017, Phase 2 in 2019, Phase 3 in 2022 — each with a separate Apartment Owners' Association, separate share certificate series, separate registered bye-laws. EstateDeck supports phase-level configuration. You can manage all three under a single admin login while each phase keeps its distinct rules, distinct billing structure, and distinct office bearers.
What happens when a flat changes ownership?
Run the Ownership Transfer workflow. Enter the sale date, the new owner's details, and the source of title (sale deed, gift deed, inheritance). EstateDeck preserves the outgoing owner in the ownership history (now read-only) and activates the new owner. The new owner's share certificate number is updated per the state Apartment Ownership Act. The new owner gets app access; the outgoing owner's access ends. Cross-references in billing, documents, and the lease (if rented) all switch over in one transaction.
Where are the sale deeds and lease agreements actually stored?
In the EstateDeck Document Repository, per-unit folder, version-controlled, with role-based access. The Unit Management record links to those PDFs by unit ID — so when you open Flat B-704 here, the lease agreement is one click away — but the actual file is in the document vault. This separation is deliberate: Unit Management is the structured data; Document Repository is the unstructured file storage. Each module owns its own slice.
Is joint ownership supported?
Yes. Add a Co-Owner profile under the primary owner. Both owners get separate logins, both see the unit in their app, both are bound by the obligations of the unit, and — depending on what your registered society bye-laws specify — both may carry voting rights at the AGM or just the first-named owner does. Joint ownership is supported under the Transfer of Property Act 1882 and all state Apartment Ownership Acts; EstateDeck simply models the configuration your bye-laws set.
How do you handle the tenant when the unit is rented?
The tenant sits as an overlay on top of the unit, not as a replacement. The owner record stays; the tenant record is added with lease start, lease end, family roster, and contact details. Tenant access is scoped — they can use amenities, raise tickets, and pay rent through the app, but they cannot vote at the AGM, cannot transfer parking ownership, and cannot edit the unit's core record. When the lease ends or move-out completes, the tenant overlay archives and the owner reclaims full control. The actual physical move event is handled by EstateDeck Move-In/Out.
Can residents update their own details, or only the committee?
Configurable per society. The default is that residents can self-update non-critical fields — mobile number, email, family member names, registered vehicle list — and any change is logged in the audit trail. Critical fields like owner name, ownership date, share certificate number, and parking slot can only be edited by the Hon. Secretary or designated Property Manager. This split reduces committee admin work without giving residents the ability to mis-edit master legal data.
Is the database admissible as evidence if there is a dispute?
Yes. Every edit — who changed what field, when, from which device — is preserved in the database audit log. The combined record qualifies as electronic record under IT Act 2000 §65B and is admissible at the Co-operative Society Registrar's audit, in consumer court, or in civil suit. EstateDeck retains the full edit history for the lifetime of the subscription, and bulk export is available on subscription end so the society retains its own data permanently.

Retire the eleven Excel sheets.
Build the spine of your society first.

We'll walk you through the unit master schema, the bulk import flow, and the cross-module references — in a 20-minute demo built for your society's structure, phase count, and statutory framework.

Book the Unit DB Demo →