The question a developer cannot answer on Monday morning

Most real-estate developers we meet can tell you their group revenue and their group profit. What they cannot tell you, quickly, is which project pushed cash negative last month, what was due versus collected versus slipped this week, or which tower is carrying the largest overdue bucket above 90 days. Those are the questions that decide whether you can fund the next slab or make payroll, and the answers are trapped across three systems that were never designed to talk to each other.

The gap is not a lack of software. A mid-sized developer running four or five projects usually has more systems than a company twice its size. The gap is that none of those systems agrees with the others, and the person who reconciles them does it by hand, once a month, long after the money has already moved.

Why the stack hides the leak inside the joins

A typical Indian developer runs on three sources of truth, and that is exactly the problem:

  • Tally holds the actuals: what was actually received and paid. It is the financial record, but it does not know your booking schedules or your construction milestones. A payment lands in Tally as a receipt against a ledger, not against a specific unit in a specific tower on a specific demand.
  • The CRM (Sell.do, Leadrat, or similar) holds bookings, demand schedules and the sales pipeline. It knows what should be collected and when, but not what actually hit the bank. The CRM raises a demand on the 5th; whether the customer paid on the 6th or the 26th lives somewhere else.
  • Excel holds everything the other two miss: covenant tracking, per-project cash flows, the weekly MIS that someone rebuilds by hand every Friday, the construction cost sheet the site engineer maintains separately.

Each system is individually correct. The leak is in the joins. Because no single view reconciles demand raised (CRM) against cash received (Tally) against cost incurred (Excel and Tally), a project can drain working capital for weeks before it shows up in the group P&L. By then the cash is already gone.

The manual reconciliation makes it worse. When a person keys receipts from Tally against demands from the CRM into a spreadsheet, three things happen. The match is approximate, because Tally ledgers and CRM unit IDs rarely share a key. It is slow, because it is a weekly or monthly batch job. And it is fragile, because the logic lives in one head and one workbook. That is a data problem before it is a finance problem, and it is the reason a clean data foundation matters more here than another reporting tool: you cannot report your way out of numbers that do not reconcile at the source.

The three leaks this disconnected stack hides

1. The project that is quietly losing money

Group profit is an average, and averages conceal. One project can be cash-negative and dragging on the whole business while two strong ones mask it in the consolidated numbers. Consider a developer with three towers: Tower A is selling ahead of construction and throwing off cash, Tower B is roughly breakeven, and Tower C launched slow, is behind on collections, and is being funded by the surplus from A. The group P&L shows a healthy profit. The reality is that Tower A is quietly financing Tower C's shortfall, and if Tower A's sales slow for a quarter, the whole structure is exposed.

Until you see cash flow per project, and not per company, you are flying on a number that hides the one thing you need to know. The fix is a per-project cash-flow view that treats each project as its own book: opening balance, collections in, construction and land payments out, closing balance, projected forward. When that exists, Tower C stops being a surprise and becomes a decision.

2. Collection slippage you notice too late

Collections move in days. Reporting moves in weeks. When your view of demand raised versus received is a manual monthly exercise, a demand that slipped on the 5th is invisible until month-end, by which point the working-capital hole is real. Collection efficiency, defined as cash received as a percentage of demands raised in a period, is the single most important operating number for a developer, and it is the one most often computed too slowly to act on.

The tool that surfaces it is a collection waterfall. For a given period and a given project, it lays out demand raised at the top, then received, then the balance, then that balance aged into buckets: 0 to 30 days, 31 to 60, 61 to 90, and above 90. Read weekly and by tower, it turns a vague sense that collections are soft into a specific list: these seven units in Tower B slipped their milestone demand, and Rs 2.1 crore that the cash-flow model assumed would arrive this month has not. That is a call the collections team can make on Tuesday instead of a variance the CFO explains at month-end.

3. Cost creep before it hits the P&L

Site costs move faster than the books close. A project can breach its cost-to-complete assumptions weeks before that variance surfaces in a financial statement. Techniques like earned-value tracking can surface the drift early (Advaiya), but only if construction progress and committed cost are connected to the financials, which in most stacks they are not. The site engineer knows the slab is a floor behind; the accounts team knows the contractor bill came in high; nobody has joined the two into a single cost-to-complete number that moves in real time.

For context on how large this drift can get at scale, India's Ministry of Statistics and Programme Implementation reported that 458 monitored infrastructure projects carried cumulative cost overruns of about Rs 5.71 lakh crore as of mid-2025, roughly 18 to 19 percent above their original sanctioned cost, according to a review of MoSPI data. Those are large public projects rather than private developers, so the figure is illustrative rather than a benchmark, but it points to the same underlying pattern: cost drift is the norm, not the exception, and it is expensive precisely because it is caught late.

What "seeing the leak" actually looks like in practice

The fix is not another dashboard vendor. It is reconciling the three systems you already run into one trustworthy source, so that a single view answers three questions on Monday morning rather than at month-end.

Cash flow per project, actual and projected. Every project gets its own cash book, built by joining Tally receipts and payments to the CRM's project and unit dimension. Actuals come from Tally; the forward projection comes from the CRM's demand schedule plus the construction payment plan. The output is one line per project showing where cash stands this week and where it is heading over the next quarter.

A collection waterfall by project and tower. Demand raised, received, and slipped, with the overdue balance aged into buckets and refreshed daily. The waterfall is keyed by unit so a slipped demand traces back to a specific customer and a specific salesperson, which is what makes it actionable rather than merely informative.

Cost-to-complete against budget, updated on commitment. As a purchase order is raised or a contractor bill is approved, committed cost updates against the budget line, so the cost-to-complete number reflects reality the day a commitment is made, not when the books close weeks later.

The mechanics underneath are unglamorous and that is the point. Tally exports (or a Tally connector) feed the actuals. The CRM's API or export feeds the demand schedule and unit dimension. A small reconciliation model keys the two together on project and unit, handles the fuzzy matches that a human used to do in Excel, and lands the result in one place that both finance and sales read from. The construction cost sheet becomes an input to the model rather than a parallel universe. Once those three views exist in one reconciled source, the leak stops being a surprise at month-end and becomes a number you manage on Monday.

You can put a rupee figure on this leak.

Our AI Stack Audit x-rays your existing data and quantifies the gap in a fixed two-week engagement. No new tools to buy first.

See how the audit works

Why this matters beyond the CFO: RERA and the quarterly scramble

There is a compliance reason to fix the reconciliation too, not just an operating one. Under the RERA Act, developers must keep 70 percent of the money collected from homebuyers for a project in a separate escrow account, usable only for that project, and must file a Quarterly Progress Report within a short window after each quarter closes (RERA Consultants). MahaRERA, for instance, moved to a financial-quarter QPR filed within days of the quarter end.

If your collections, demands and project-level cash flows are reconciled continuously, the QPR is a report you generate, not a fire drill you survive. If they are not, the same manual reconciliation that hides the cash leak also turns every quarter-end into a scramble to assemble numbers the regulator wants and the bank managing the escrow account wants. The disconnected stack does not just cost you working-capital visibility; it costs you a week of finance-team time four times a year, and it raises the risk that a QPR figure disagrees with what the bank sees in the escrow account.

Finding your leak first, before building anything

Every developer's stack is wired slightly differently, so the honest first step is to look at your actual Tally, CRM and Excel exports and see where the reconciliation breaks. That is what our AI Stack Audit does: we examine your existing data, show you which project is draining cash and how much collection is slipping, and tell you what it would take to see it live. We then ship the pipeline that keeps those three systems reconciled, rather than leaving you with a report that is stale the day it is printed.

This is the first of a short series on the hidden numbers in a developer's business. The companion pieces look at why unsold inventory is a data problem rather than a pricing problem, and how collection efficiency and the quarterly RERA scramble both trace back to this same disconnected stack.

Key takeaways

  • Group P&L hides the leak: one project can drain working capital for weeks while the consolidated numbers still look healthy.
  • The leak lives in the joins between Tally (actuals), the CRM (demand schedules), and Excel (cash flow, covenants), three systems that were never built to reconcile with each other.
  • The three views that surface it: cash flow per project, a collection waterfall (demand raised versus received versus slipped, with aging), and cost-to-complete against budget.
  • Collection efficiency and cost-to-complete move in days, but manual monthly reporting shows them too late to act. The fix is reconciling the data you already have, not another dashboard.
  • The same reconciled foundation turns the quarterly RERA report from a fire drill into a report you generate.

Frequently asked questions

How do I connect Tally with CRM and booking data for reporting?

You build a pipeline that pulls actuals from Tally and demand schedules from the CRM into one reconciled model keyed by project and unit. The hard part is the join, because Tally ledgers and CRM unit IDs rarely share a common key, so the model has to resolve the match that a person used to do by hand. Doing it manually in Excel is why the report is always a week behind.

What is a good collection efficiency percentage for a real-estate project?

It varies by market and project stage, so the useful benchmark is your own trend over time and by project rather than a universal target. A project selling ahead of construction will look very different from one collecting on possession-linked milestones. The point is to compute collection efficiency weekly and by tower, not once a month at the group level, so a soft month is visible while you can still act on it.

Which of my projects is actually losing money?

You cannot tell from group P&L, because a strong project can mask a weak one in the consolidated numbers. You need cash flow and cost-to-complete per project, reconciled from Tally and your CRM, to see which project is cash-negative before it drains the business. A per-project cash book plus a live cost-to-complete number is what makes the answer obvious rather than a month-end surprise.

Do we need to replace Tally or our CRM to get this?

No. The point is to reconcile the systems you already run, not rip them out. Tally stays the financial record, the CRM stays the sales and demand system, and a lightweight pipeline joins them into one reconciled view. Replacing either system is expensive, disruptive, and does not fix the join, which is where the leak actually lives.