Collection Efficiency and the Quarterly RERA Scramble: The Report Every Developer Redoes by Hand

The short answer

Two problems drain a residential developer's finance function every quarter, and both trace back to the same missing data view. First, overdue demands: money you have already earned against a construction milestone but not yet collected. This is not "future revenue." It is cash sitting in your buyers' accounts instead of yours, financing their float instead of your next slab. Second, the RERA Quarterly Progress Report (QPR), which must be filed within 20 days of the end of every quarter (March, June, September and December) (Bajaj Finserv), and which most promoters still assemble by hand from Tally, the CRM and a stack of Excel files. Both problems dissolve when demand raised versus demand received lives in one reconciled source instead of three disconnected ones. Here is how they connect, and where the leak actually sits.

Overdue demands are uncollected cash, not "pipeline"

In an under construction project, you raise a demand letter at each milestone: on booking, on excavation, on each slab, on possession. The moment you raise it, that amount is contractually due. Collection efficiency (demand received divided by demand raised, for a period) is the single number that tells you how much of what you invoiced actually landed in the bank.

When collection efficiency slips from, say, 95 percent to 88 percent, the missing 7 percent is not a rounding error. It is working capital you have to replace with a construction loan or promoter funding, at an interest cost, to keep pouring concrete on schedule. Because real estate has one of the longest payment cycles of any sector in India (Finsmart Accounting), even a small drop ties up a large rupee amount for a long time. A rising Days Sales Outstanding (DSO) on project receivables is the same leak from another angle: every extra day of DSO is a day you finance your buyers instead of your build.

The mechanics matter here. A demand raised on a slab milestone typically carries a payment window in the buyer agreement, after which interest on delayed payment is contractually chargeable. But charging that interest requires you to know, per unit and to the day, when the demand was raised and when it was received. If that timeline lives only in a spreadsheet that someone updates monthly, you cannot enforce the very clause you wrote to protect your cash position. The leak is not just the principal you are late collecting; it is the delayed payment interest you are entitled to and never invoice because nobody could reconstruct the aging fast enough.

The trouble is that most developers cannot see collection efficiency at the resolution where the decision lives. Group level dashboards show a healthy blended number while one tower quietly runs a growing 90 plus day overdue bucket. The buyers who slipped are invisible until someone manually ages the ledger, usually at quarter end, too late to have chased them softly in week three. By the time the number surfaces, the soft nudge window has closed and you are into formal reminders, interest notices, and in the worst cases cancellation, all of which cost goodwill and legal time that a week three phone call would have avoided.

The QPR is the same data, assembled by hand every quarter

Here is the part that turns a finance annoyance into a strategic one. The QPR you file with your state RERA authority draws on the exact same underlying data as your collections view: money received against each project, deployed against construction, held in the designated project account. Under RERA, 70 percent of the funds collected from buyers must sit in a dedicated project bank account, withdrawable only against verified construction progress (RERA summary). The QPR is where the regulator checks that demand raised, demand received and deployment line up.

So a developer with disconnected systems does the same reconciliation twice: once, informally, to understand collections, and again, formally and under deadline pressure, to file the QPR. Senior finance staff spend days each quarter re-keying figures across Tally, the CRM and spreadsheets. Across finance functions generally, only about 35 percent of professionals' time goes to actual insight work; the rest disappears into data collection and validation (FP&A Trends Survey 2024). Quarter end QPR assembly is a textbook example of that lost time.

Look at what the QPR actually asks for and the overlap becomes obvious. The filing wants project registration details, the number of units booked in the quarter, the amount collected against those bookings, the amount deposited in the designated account, the amount withdrawn, and the physical and financial progress of construction. Every one of those figures already exists somewhere in your stack. Booking counts and demand schedules sit in the CRM. Collections and account balances sit in Tally. Construction progress sits with the project engineer. The QPR is not asking for new information; it is asking you to line up information you already have. The manual scramble exists purely because those three sources have never been joined.

And the stakes are not trivial. Missing the QPR deadline is a compliance event, not a paperwork slip. In one quarter alone, MahaRERA issued notices to the developers of 8,212 projects for late QPR filing (Construction World), with penalties escalating and, beyond 30 days, potential suspension of the project's registration (CA JD Shah Associates). A team buried in manual reconciliation is a team at risk of missing a deadline that can freeze your ability to sell. The failure mode is quiet: the report gets built, but it gets built late, and the person building it is your most expensive finance hire spending a week on data entry instead of on the cash forecast that actually protects the project.

Both the collections leak and the QPR scramble share one root cause

Both problems come from the same place: your actuals live in Tally, your demand schedules and buyer status live in the CRM or booking system, and the glue between them lives in someone's spreadsheet. No single system can answer "demand raised versus received, per tower, aged by bucket," so nobody asks it weekly, and the overdue bucket grows unwatched until quarter end forces a manual reckoning.

This is a data foundation problem before it is a reporting problem. The reason a KPI as basic as collection efficiency cannot be trusted on demand is that the numbers behind it are never in the same place at the same time, in the same shape. A booking ID in the CRM does not always map cleanly to a ledger entry in Tally. A part payment against one demand can land before the demand for the next milestone is even raised. Names, unit numbers and project codes drift between systems. Until those keys are reconciled once, every report is a fresh act of detective work, and every detective arrives at a slightly different answer.

Fix the data plumbing once and both problems ease together. Reconcile Tally (what was actually received and deployed) against the CRM (what was demanded and when it was due) into one source of truth, and you get:

• A live collection efficiency and aging view, per project and per tower, so overdue demands get chased in week three, not quarter thirteen.
• A QPR largely pre-assembled from the same reconciled figures, turning a multi-day manual exercise into a review and file.
• Enforceable delayed payment interest, because the raised to received timeline is now recorded to the day rather than reconstructed after the fact.
• A designated account reconciliation you can trust, because collections and deployment are joined to the same demand schedule the regulator is checking against.

The same pipeline that plugs the working capital leak also removes the compliance overhead. That is what happens when demand versus received data stops being trapped in three systems and starts living in one place that both finance and compliance read from.

How to find your own number before you fix anything

The figures here are industry context, not a promise about your business. Your real collection efficiency, your real DSO and the hours your team loses to QPR assembly are specific to your projects and systems. The only way to know them is to reconcile your own data (demand raised against demand received, per tower, aged) and to trace how the QPR is built today, step by manual step, so you can see exactly where the hours and the leaked cash go.

We would start by getting the data foundation for AI right: one reconciled model that joins Tally and the CRM on the keys that actually matter (project, tower, unit, buyer, milestone) so every downstream number, from collection efficiency to the QPR, reads from the same trusted source. Without that foundation, any dashboard you build on top just automates the confusion faster.

That reconciliation is the first thing we build. Our AI Stack Audit x-rays your Tally, CRM and spreadsheet stack, quantifies the overdue demand leak in rupees, and shows how much senior finance time the quarterly RERA filing costs, and how much of it a single reconciled data source removes. You leave with a specific number for your own portfolio, not a benchmark borrowed from someone else's.

Key takeaways

• Overdue demands are cash you have already earned against a milestone but not collected, a financing leak rather than future pipeline. Collection efficiency (demand received / demand raised) is the number that exposes it.
• Group level dashboards hide the leak: a healthy blended figure can mask one tower with a growing 90 plus day overdue bucket.
• The RERA QPR draws on the same demand raised versus received data, yet most promoters rebuild it by hand every quarter from Tally, the CRM and Excel. That is expensive senior finance time, and a real compliance risk if the 20 day deadline slips.
• Both problems share one root cause: disconnected systems. Reconcile Tally and CRM into one source and you get live collection aging and a pre-assembled QPR at the same time.
• Getting the data foundation right also lets you enforce delayed payment interest you are entitled to but often never invoice, because the raised to received timeline is finally recorded to the day.

Frequently asked questions

What is a good collection efficiency percentage for a real estate developer?

Collection efficiency is demand received divided by demand raised for a period. Developers generally aim for the mid 90s percent or higher on under construction projects, but the meaningful benchmark is your own trend over time and by tower. A slipping number, not an absolute one, is what signals a working capital leak, so track the direction of travel per project rather than chasing a single headline figure.

How do I build a RERA Quarterly Progress Report without doing it by hand every quarter?

The QPR draws on the same demand raised, demand received and construction deployment data as your collections view. If you reconcile Tally (actuals) and your CRM or booking system (demand schedules) into one source of truth, most of the QPR is pre-assembled from that reconciled data, turning a multi-day manual exercise into a review and file. The manual scramble exists only because those systems are disconnected and someone has to join them by hand every quarter.

How do I track DSO and overdue buckets on project receivables?

Age your demand ledger by bucket (current, 30, 60, 90 plus days) at the tower and unit level, not just the group level, and track Days Sales Outstanding per project. Group level views hide the towers that are drifting. Doing this weekly instead of at quarter end lets you chase overdue demands while a soft nudge still works, and it lets you invoice the delayed payment interest your buyer agreement already entitles you to.

What happens if I miss the RERA QPR deadline?

Missing the 20 day post quarter QPR deadline is a compliance event, not a paperwork slip. Regulators have issued notices to thousands of projects at once for late filing, with escalating penalties and, beyond about 30 days, potential suspension of the project's registration, which can freeze your ability to sell. The safest defence is a reporting process that assembles the QPR from reconciled data so filing on time is a review step rather than a fire drill.

Why does the same data get reconciled twice, once for collections and once for the QPR?

Because collections analysis and the QPR read the same underlying facts (money demanded, money received, money deployed) but live in different owners' hands. Finance builds the collections view informally through the quarter; compliance rebuilds the same figures formally under deadline for the filing. When Tally and the CRM are joined into one reconciled model, both views draw from that single source, so the reconciliation happens once and serves both purposes.