RERA Compliance for Real Estate CRMs in India: What Developers Need to Know

The Real Estate (Regulation and Development) Act, 2016 — RERA — was designed to protect homebuyers, but its obligations land squarely on developers and their agents. Most compliance conversations focus on project registration and possession timelines. Fewer focus on what RERA means for your sales and lead management operations — specifically, what your CRM and sales process are required to do, and what they're prohibited from doing, once a project is RERA-registered.

What RERA actually requires from your sales operations

1. Only sell what's registered

A RERA-registered project must display its registration number prominently in all advertisements, marketing materials, and on the project website. Your CRM and any outreach templates should automatically pull the correct registration number for each project — and your sales team must not market unregistered inventory. In practice, this means the project-level data in your CRM (registration number, registered unit types, registered FSI) must be accurate and must match what's on the state RERA portal before any outreach begins.

State RERA portals (MahaRERA, TNRERA, UP-RERA, Karnataka RERA, etc.) each have their own registration format and renewal timelines. Keeping your CRM's project master data current with registration status is an operational compliance requirement, not just a data hygiene issue.

2. Agents must be registered

Under Section 9 of RERA, no real estate agent may facilitate transactions in a registered project without their own RERA agent registration. For developers who manage a large channel partner network, this creates a practical compliance obligation: your CP portal or broker management system should record RERA registration numbers for every agent who transacts on your projects, and you should not process commissions for agents whose registration has lapsed or who are operating in states where they aren't registered.

This is an area where most CP management tools — even the better ones — are weak. Agent RERA numbers are typically collected at onboarding and then never re-verified. Registration renewals lapse. An unregistered agent facilitating a transaction creates liability for the developer as well as the agent.

3. Disclosure obligations in pre-launch marketing

RERA prohibits advertising or booking inventory in a project before the project receives RERA registration. Pre-launch "expressions of interest" and booking amounts collected before registration are a RERA violation in most states. Your CRM workflow for lead conversion — specifically the step that moves a prospect from "interested" to "booking amount collected" — must be gated on project registration status.

In practice, many developers run informal pre-launch interest lists ("register your interest, we'll call you when we launch"). These are generally acceptable as long as no booking amount changes hands before registration. But any CRM field that captures an "advance" or "token" amount should be reviewed against your state's RERA interpretation — some states are stricter than others on what constitutes an unlawful pre-registration booking.

4. Standard agreements and no unilateral changes

Once a buyer signs an Agreement for Sale (AFS), the developer cannot alter the agreed specifications, carpet area, or price without the buyer's written consent. Your CRM should treat AFS data as immutable post-signing — no field updates to agreed price, carpet area, or possession date without a documented change request and buyer acknowledgement. Any CRM that allows sales managers to retroactively update "agreed price" on a closed deal without an audit trail is creating a RERA liability.

5. Complaint handling and response timelines

RERA authorities expect developers to respond to registered complaints within defined timelines. Your CRM's customer success or post-sale module — if you have one — should be able to surface open buyer complaints with timestamps. The complaint itself may originate outside your CRM (via the state RERA portal), but your internal tracking should be able to show when a complaint was logged, who owns the response, and what its current status is.

What this means for how you evaluate sales and CRM software

When assessing a CRM or sales platform for a RERA-registered developer, the compliance-relevant questions are:

• Can the system store project RERA registration numbers and surface them in all outbound templates?
• Does it gate the booking/token payment workflow on project registration status?
• Does the CP/agent module capture and store agent RERA registration numbers, with an expiry date that can be flagged?
• Is the Agreement for Sale data treated as immutable, with a change-request workflow and audit trail?
• Can the system generate a complaint register or link to state RERA portal complaint data?

Most generic sales CRMs score poorly on all five. Real estate-specific CRMs are better — but the gap between "has a RERA number field" and "has a RERA-compliant workflow" is significant.

The data layer underneath compliance

RERA compliance in your sales operations is ultimately a data integrity problem. The regulation assumes that the information given to buyers — project specs, carpet area, possession date, agent identity — is accurate, verifiable, and not altered after it's been committed. Your CRM's data model and access controls determine whether that assumption holds.

Developers with fragmented data — leads in one system, booking data in another, agent records in a spreadsheet — have a harder time demonstrating compliance because the data linkage is manual and opaque. A unified system where project registration, agent registration, lead source, and booking data are in the same place (or reliably connected) is not just operationally useful; it makes compliance audits significantly less painful.

Frequently asked questions

What is RERA compliance in real estate sales?

RERA (Real Estate Regulation and Development Act, 2016) compliance in sales operations covers four main areas: selling only from a registered project with a valid RERA number, using only registered agents for buyer-facing work, not accepting bookings before state approval for pre-launched projects, and maintaining the immutability of Agreement for Sale terms after signing. CRM systems that allow post-signing edits to agreed price, carpet area, or possession date without audit trails create RERA liability.

Can a real estate developer legally sell a project before RERA registration?

No. Under RERA, developers cannot advertise, market, or accept bookings for a project until it has received RERA registration from the relevant state authority. Collecting expressions of interest or "soft bookings" with refundable payments is a grey area — but any transaction that resembles a booking before registration is a compliance risk. Your CRM should enforce this by preventing booking-stage workflows from opening on unregistered projects.

What real estate agent registration requirements exist under RERA?

Any person or entity acting as a real estate agent — facilitating the purchase, sale, or rental of a registered property — must register with the relevant state RERA authority. Registration is renewable and state-specific. Developers who use unregistered agents for sales activities face penalties. Your CRM's agent management module should store each agent's RERA registration number and flag expired registrations before allowing new deal assignment.

How should a developer handle buyer complaints to stay RERA-compliant?

RERA authorities expect timely responses to registered buyer complaints. While the complaint is typically filed on the state RERA portal, developers should maintain internal tracking of all open complaints with timestamps, assigned owners, and status updates. A CRM or customer success tool that can surface this view — separate from the sales pipeline — helps demonstrate that complaints are being managed, not ignored, which matters significantly in any regulatory enquiry.