A Bangladeshi developer outgrows spreadsheets at the point where more than two people need to change the same numbers on the same day. That is usually somewhere between the second and third live project — around 120 to 200 sold units, three or four collection staff, and one accountant reconciling bKash, bank transfers and cash receipts against a kisti schedule that three people maintain separately. Unit count is not the trigger. Concurrent editing is.
The four files every developer eventually has
Ask an operations manager in Dhaka what the business runs on and you will usually be shown four things:
- An inventory workbook — every unit, its size, its price, its status.
- A collection workbook — buyer names, kisti dates, amounts, what came in.
- A land file — mouza, khatian and dag numbers, purchase deeds, mutation status, scanned in a folder.
- A WhatsApp group where the real decisions happen.
Each one is fine. The problem is that none of them knows about the others. When a buyer transfers BDT 5,00,000 to the company account, that transaction has to be found in the bank statement, matched to a person, matched to a unit, matched to a specific installment row, receipted, and reflected in the collection report the MD reads on Sunday. Every one of those steps is a human copying a number, and each copy is a place where the number can differ.
What that actually costs
The cost is rarely a single dramatic loss. It is a set of small, recurring ones:
| Leak | How it happens | Typical size |
|---|---|---|
| Late collection | Nobody sees an overdue kisti until the monthly report | 2–5% of scheduled collection slips a quarter or more |
| Unrecorded discount | A sales manager agrees a price adjustment verbally | BDT 50,000–2,00,000 per unit, invisible until handover |
| Double allocation | Two staff commit the same unit from two copies of the sheet | One cancelled booking, one lost buyer, one refund |
| Broker dispute | No record of who introduced the buyer first | 1–2 disputes per project, settled by paying twice |
| Registration delay | A document is missing on the day, discovered on the day | Days of staff time, an angry buyer |
None of these appear in a profit and loss statement with a helpful label. They appear as "collection is behind" and "margin came in lower than budget".
What a real estate ERP replaces
A real estate ERP is not a better spreadsheet. It is a single record of the things a spreadsheet can only describe:
- The unit as an object with a state — available, held, booked, agreement signed, registered, handed over — that only moves forward and only with the right permission. This is what makes double booking structurally impossible rather than merely discouraged. See how double booking happens.
- The kisti schedule generated from the price, the payment plan and, where you use them, construction milestones — so a buyer ledger, a due list and an overdue list are the same data viewed three ways, not three files. See building a schedule that does not live in Excel.
- The receipt as the thing that creates the collection entry, so reconciliation is a matching exercise rather than a re-keying exercise.
- The land record attached to the project rather than to a folder — khatian, dag, mutation status and the deeds that prove them. See land acquisition records.
- The landowner share in a joint venture, computed rather than remembered, including signing money adjustment and which specific units are theirs. See how the split is calculated.
The market context that makes this urgent
REHAB member companies compete for a buyer who now compares three projects on Facebook before calling anyone. Two things follow. First, response time decides who gets the site visit — the first developer to call back wins a disproportionate share, which is a CRM problem, not a marketing one. Second, an NRB buyer sending money from Dubai or Kuala Lumpur expects a receipt the same day and a statement on request. A team that needs two days to answer "how much have I paid so far" loses referral business quietly.
What good looks like after the move
The honest test of a system is not the demo. It is these four questions, asked on a random Tuesday, answered in under a minute each:
- How much was due this month, how much came in, and who is behind?
- Which units are genuinely available right now, at what price, with what discount authority?
- What is the landowner still owed on the Uttara project, in units and in money?
- What does this project's margin look like if construction runs three months late?
If your answer to any of those is "let me check with accounts", the spreadsheet is already costing more than the software would.
What to do next
Pick the single number that hurts most — usually monthly collection against schedule — and see it modelled on your own project structure rather than on a demo dataset. That is a forty-minute conversation, and it is the fastest way to find out whether the problem is your process or your tools.