Project registration data developers must keep, and where it lives

Regimes differ between countries. The same families of data keep appearing: units, buyer payments, construction progress and approvals, which together answer what is being built, who bought it and how much was collected.

Nothing here replaces your lawyer. Your regulator’s notice defines the exact list, and this guide only describes the common shape that most property regimes follow, so confirm it before you build anything.

Give each family a named owner. Data without an owner goes stale within a quarter, and the filing is the moment when the staleness finally shows up for the compliance officer.

Each unit gets one row. Booked, sold, held and available must mean the same thing to sales, accounts and the filing, or the inventory count will never reconcile against the price list.

Payments sit on top. Each buyer has a schedule tied to construction stages, and every receipt must map to one instalment, so the ledger shows what each buyer still owes today. Where a regulator expects project funds in a designated account, you must also show every deposit and withdrawal from that account, matched to the buyer receipts behind it.

Mismatches usually start at booking. Sales logs a sale from a chat message, accounts hears about it a week later, and the unit status never changes, so two sheets now disagree. Fix that handoff first. A booking form that forces unit number, buyer name and token amount before it saves removes most of the pain downstream when the filing arrives.

A progress report is a claim. Each stage needs a completion date, a certificate from the project engineer, and photographs or site reports that a reviewer can open without a phone call.

Approvals work the same way. Keep the approval letter, plan version, completion certificate and expiry date together, because expiry dates cause the nasty surprises when a renewal lapses unnoticed.

Folders with strict names help. A system that links each document to its project and warns before expiry helps more, since nobody remembers dates across five projects, and both beat a drawer.

The failure pattern is familiar. Units live in a sales sheet, receipts in the accounting package, progress in site emails and approvals in a steel cabinet, and every filing means days of stitching.

Keep one master record per unit. Sales writes status into it, accounts writes receipts against it, the site team writes progress against the project, and reports read from all three without copying anything.

Naming rules help too. A real estate CRM linked to accounts does it, as does a custom system built around your workflow and your regulator’s report formats, so filing becomes an export. Keep an audit trail on edits. The log must answer who changed a unit’s status, what it said before and which day the change happened, or the trail is useless.

Pick one project first. Trace a single unit from booking to its latest receipt, and check whether the figures match across the sales sheet, the ledger and the buyer file. Mismatches are your first fixes.

Next, list each report your regulator requires, with its due date and the fields it reads from the unit, receipt and stage tables. Gaps show up fast. The usual culprits are progress evidence and the link between receipts and construction stages, which nobody owns until a regulator asks for them.

Hand that gap list to whoever maintains your systems and ask which gaps close with a form change and which need a new tool. Do it before the deadline.