RERA quarterly updates: one obligation, twenty-eight different portals

Registration, escrow discipline and defect liability tend to get the most attention in RERA compliance programmes, because they are large, consequential, and reviewed carefully at the point a project launches. Quarterly progress updates get comparatively little attention, because they are routine, recurring, and — precisely because they are routine — the obligation most likely to be delegated to whoever last handled the portal, with no institutional backup when that person moves on.

For a developer with active projects across several states, this is a genuine structural risk, because "the RERA quarterly update" is not one recurring task. It is a separate recurring task per state, on a separate portal, in a format that state's authority has defined, and the definition of what counts as an acceptable, complete update is not uniform.

What actually varies between state RERA portals

The portal itself and its technical requirements. Each state authority operates its own portal, with different file formats accepted, different mandatory fields, and different session and upload behaviour. A process built around one state's portal quirks — file size limits, accepted document types, session timeout handling — does not transfer cleanly to another.

What counts as a complete update. Some state authorities expect granular, unit-level sale and construction progress data; others accept more aggregated project-level reporting. A submission that satisfied one state's authority as complete can be rejected or flagged as deficient by another for insufficient granularity.

Photographic and progress evidence requirements. Several states expect dated site photographs or geo-tagged progress evidence as part of the quarterly submission; the specificity of this requirement — how many images, what angles, what metadata — is not standardised.

Escalation on missed or deficient submissions. Consequences and grace periods for a late or incomplete quarterly update differ by state authority, from an administrative reminder in some states to more immediate enforcement action in others.

Why this obligation specifically tends to lapse

Three structural reasons, distinct from the substance of RERA itself.

It is recurring and unglamorous. Registration and escrow compliance get scrutiny because they are large, one-time-per-project events with visible stakes. A quarterly update is the fourth or fifth time doing the same task, and institutional attention naturally drifts toward whatever feels newly urgent.

It sits with project-level teams, not group compliance. Because the update requires current construction and sales data, it is usually prepared by the individual project team, not a central compliance function — which means group-level visibility into whether every project's update was actually submitted, on time, in a state-acceptable format, is often thin or absent.

Portal access and institutional knowledge are person-dependent. The specific quirks of a given state's portal — what it silently rejects, what format actually uploads without error — live in the head of whoever has done it before for that state. When that person changes roles, the next person often relearns the portal's requirements through a failed or delayed submission.

What a resilient multi-state process looks like

A central register of every active project, its state, its portal, and its next submission due date — maintained at group level, independent of individual project teams, so a missed submission is visible before the authority flags it, not after.

Documented, state-specific submission checklists, capturing each portal's actual accepted formats and field requirements as institutional knowledge, not person-dependent knowledge. This is the single highest-leverage document a group compliance function can build for this obligation, because it converts tribal knowledge into something that survives staff turnover.

A confirmation loop, not just a submission log. Submitting a quarterly update is not the same as having it accepted as complete. A resilient process confirms acceptance status per project per quarter, catching deficiency flags early rather than discovering at the next project milestone that a prior quarter's update was rejected and never resubmitted.

Escrow and quarterly update tracking linked, not separate. Because quarterly progress data and escrow utilisation are substantively connected — progress claims should be consistent with fund utilisation — tracking them in the same system, rather than as separate compliance tasks owned by separate teams, catches inconsistencies before an authority does.

The honest scale of the problem

For a developer with twenty active projects across seven states, this is effectively twenty separate recurring obligations, each with its own portal behaviour and acceptance standard, recurring every quarter. Treated as "one RERA reporting obligation" managed informally by project teams, it degrades quietly. Treated as twenty explicitly tracked recurring items with a central register and state-specific checklists, it becomes exactly as routine as it should be.