Compliance in Indian real estate is usually discussed as a legal problem and solved as a clerical one: somebody assembles the quarterly return from four spreadsheets in the last week before it is due. That works until an authority, an auditor or a buyer's lawyer asks the question compliance actually turns on — not what is the number, but show me the sequence of documents behind it. That is a systems problem, and it is not solvable in the last week.
This is an operational article, not legal advice. RERA is administered by state authorities and tax rules change; confirm the current position for your state and project type with your counsel and tax advisor.
What RERA is actually built around
Strip the Act down and the obligations that shape your systems are these:
- Registration before you sell. A project must be registered before it is advertised, marketed or booked, and the registration number has to appear on advertising material along with the authority's website.
- A designated account. Seventy per cent of amounts realised from allottees must be deposited into a separate account, to be used for construction and land cost, with withdrawals proportionate to completion and certified by the professionals the Act names.
- Sale on carpet area. The unit is sold on carpet area, which has a statutory definition. Your cost sheet has to be built on it.
- Periodic disclosure. Updates to the authority on a defined cycle covering booking status, approvals and physical progress.
- Defect liability. A five-year obligation from the date of possession for structural defects and specified workmanship issues.
- Registered agents. Anyone facilitating a sale must be registered, and that registration is your problem to verify, not theirs to remember.
Notice what all of these have in common: each one is a claim you will later have to substantiate with dated documents in sequence. None of them is a number you can compute at the end.
The designated account is an operational constraint, not an accounting one
The proportionate-withdrawal mechanism is where most developers feel RERA in their working capital. To draw from the designated account you need collections attributed correctly, cost incurred recorded against the right project, and completion certified. If collections sit in one system, costs in another and progress in a third, every withdrawal becomes a reconciliation exercise, and the certification is only as good as the spreadsheet somebody assembled that week.
The systems requirement is unglamorous: receipts posted to a project the moment they clear, purchase orders and bills carrying the project and cost head from the point of creation, and progress recorded against a work breakdown that matches how cost is captured. Get those three right and the withdrawal file is a report. Get them wrong and it is a fortnight.
GST: the trap is place of supply and timing, not the rate
Rates for real estate have been revised more than once and vary by project type, so the number is something to confirm rather than memorise. What consistently causes problems is structural:
- Registration per state. A group operating in three states has three registrations, and the correct one has to be applied at the point of invoicing, not corrected in the return.
- The completion boundary. Whether a booking falls before or after the relevant completion event changes its treatment entirely. That date has to be a fact in the system, not a recollection.
- Input tax credit eligibility. Whether credit is available depends on the scheme the project falls under, and it cascades into how procurement is priced. Procurement and sales have to be reading the same project attribute.
- Reverse charge on procurement. Certain supplies shift the liability to you. Recognising that at the purchase order stage is far cheaper than discovering it at filing.
Groups with Gulf operations carry the parallel problem: VAT per jurisdiction and, for Saudi entities, e-invoicing that must be generated and reported in a prescribed technical format. The pattern is the same — compliance is decided by how the transaction is captured, not by how the return is assembled.
What an audit trail has to contain to be worth anything
Every document that carries a consequence needs five things attached to it, permanently:
- A sequential, non-reusable number from a series that is defined per branch or entity. A number that can be reissued is not evidence.
- A creator and a timestamp that the creator cannot edit.
- The approval chain that applied, including who approved, when, and what the value band was at the time.
- The prior version, where a document was revised. A discount changed from twelve per cent to eighteen is a fact; a document that only shows eighteen is not a record.
- The link to what it caused. An allotment letter to a booking, a booking to a demand, a demand to a receipt, a receipt to a ledger entry.
The test is simple and worth applying to your current setup: pick a booking from eighteen months ago and try to reconstruct, without asking anybody, who approved the discount and on what basis. If that takes more than a few minutes, your trail is not a trail.
The documents everyone forgets
Cancellations, transfers and refunds. They are a small share of transactions and a large share of disputes, because they are usually handled as exceptions outside the normal flow — an email, a manual adjustment, a cheque. Each one needs the same discipline as a booking: a numbered document, an approval, a reason recorded, and a ledger consequence. The same applies to any change to a payment plan.
Being ready before you are asked
Compliance readiness is not a module you switch on. It is a property of how transactions are captured, and it comes from four habits:
- Numbering series defined per entity and per branch before the first document is raised.
- Approval matrices configured by value band, so authority is a setting rather than a convention.
- Every advertisement, cost sheet and agreement generated from a versioned template, so what went out is reproducible.
- A single ledger, so the collection, the cost and the progress that justify a withdrawal are three views of the same data rather than three files.
Done this way, the quarterly update stops being a project. It becomes a report you run, look at, and submit — which is what it was always supposed to be.
Written by the Teczen team. If you want to talk through how any of this applies to your projects, book a working session — no slides.