Odoo for real estate developers selling flats over years, not minutes.

The Bangladesh Developer Revenue Model

Bangladesh's private real estate sector, concentrated heavily in Dhaka and Chattogram and represented industry-wide by REHAB (Real Estate & Housing Association of Bangladesh), runs on a sales model fundamentally different from almost every other business this site covers. A developer sells a flat or a plot years before, or at best around, the point of physical handover, and collects payment across a schedule that typically includes a booking money payment, a down payment on agreement signing, and then a series of installments spread over one to five years, often structured to align loosely with construction milestones (foundation complete, structure complete, finishing stage) even when the legal payment schedule is calendar-based rather than strictly milestone-triggered.

This creates two distinct ERP problems that a standard sales order in most other industries never has to solve simultaneously: tracking a single sale's revenue collection across years against dozens or hundreds of individual buyers, and tracking project cost accumulation across the same multi-year timeline to eventually know whether a specific flat, sold at a specific price two years before its walls existed, actually made money once land, construction, and overhead are fully allocated to it.

In manufacturing, the sale ends when the goods leave. In real estate, the sale begins when the buyer signs, and the real accounting work runs for years afterward.

Structuring Installment Sales in Odoo

Odoo has no purpose-built real estate payment-plan module out of the box, and any Bangladesh consultant claiming otherwise is describing a heavily customized build, not a standard feature. What Odoo does offer, and what a properly structured implementation builds on, is a combination of Sales and Accounting capability flexible enough to model an installment schedule accurately: each unit (a specific flat or plot) is set up as a distinct product or project task, the buyer's full payment schedule is captured as a sales order with either a series of scheduled invoice lines dated to the agreed installment dates, or Odoo's recurring invoicing capability under Sales > Configuration > Recurring Plans adapted to the developer's specific schedule rather than a true subscription cadence.

The critical configuration decision is whether installments are calendar-based (due on fixed dates regardless of construction progress) or milestone-linked (due when a defined construction stage completes). Calendar-based schedules map cleanly onto Odoo's native recurring invoice or scheduled invoice functionality. Milestone-linked schedules require tying invoice generation to a Project task or milestone completion event, which is a more customized build (typically an automated action or a small server action script triggering invoice creation when a linked project milestone is marked done) but avoids the common real-world problem of a construction delay leaving a calendar-based invoice due for a flat that has not actually advanced to the stage the buyer was told would trigger that payment.

Payment Structure	Odoo Mechanism	Trade-off
Calendar-based installments	Scheduled/recurring invoice lines on the sales order	Simple to configure, but disconnected from actual construction progress
Milestone-linked installments	Project milestone completion triggers invoice generation	More accurately reflects buyer expectations, requires custom automation
Hybrid (calendar with milestone gates)	Scheduled invoices with a manual hold released on milestone sign-off	Most common in practice; balances predictability with fairness

Project-Based Costing Across a Multi-Year Build

A real estate project's true cost is not known at the moment units are sold, since sales often begin during or even before land development and construction, well before final costs are locked in. Odoo's Analytic Accounting, with each project set up as its own analytic account under Accounting > Configuration > Analytic Accounts, lets every cost, land acquisition and registration cost, construction contractor bills, architect and structural engineering fees, RAJUK and utility connection charges, and sales and marketing commission, post against that single project regardless of which accounting period the cost falls in across the multi-year build.

This is structurally similar to the multi-year project cost tracking any project-based business needs, and the project charter and tracking discipline in the Odoo Project Charter Template is directly applicable to structuring a real estate project as a trackable Odoo project with phases, tasks, and budget lines, even though the underlying deliverable here is a physical building rather than a service engagement.

Rolling Costs Up to a Per-Unit Margin

The number a developer actually needs, and the number that is genuinely hard to produce without deliberate system design, is per-unit margin: what did this specific flat cost to build, fully loaded with its fair share of land and overhead, against what it actually sold for. The standard approach is apportionment by built-up area or plot size: total project cost (land plus construction plus overhead) divided by total sellable area gives a cost-per-square-foot figure, multiplied by each unit's specific area to arrive at that unit's allocated cost.

In Odoo, this apportionment calculation is typically done as a costing worksheet, native project/analytic cost totals exported or referenced into a structured calculation (either a custom Odoo Studio report or a maintained spreadsheet fed by Odoo's cost data) that applies the allocation basis and compares it against each unit's actual sale price recorded on its sales order. This should be recalculated at defined checkpoints, not just once at project launch, since construction costs in Bangladesh have historically moved meaningfully within a single project's build timeline (steel and cement price volatility being the most common driver), and a developer who priced units at launch based on an early cost estimate needs to know, well before completion, whether actual costs are tracking to plan or eroding margin on units already sold at a fixed price.

RAJUK-Adjacent Approval Documentation

Every Dhaka-area development project moves through a sequence of approval stages with the Rajdhani Unnayan Kartripakkha (RAJUK), from land use clearance and building plan approval through to the occupancy certificate at completion, with equivalent authorities (CDA in Chattogram, for instance) governing outside Dhaka. Odoo has no RAJUK-specific compliance module, and no ERP vendor should claim one, but the approval pipeline itself, a sequence of stages, each with required documents, submission dates, and responsible staff, maps cleanly onto Odoo's Project module as a dedicated project with a kanban stage per approval milestone, or onto the Documents module for a structured, centrally accessible repository of scanned approval letters, drawings, and correspondence.

The practical value for a developer running several projects simultaneously, each sitting at a different approval stage, is having one system-of-record view answering "where does each project actually stand with RAJUK today" rather than that knowledge living in a single coordinator's memory or a personal folder of paperwork that becomes a serious operational risk if that person is unavailable during a critical filing window. Attaching scanned approval documents directly to the relevant project task also gives finance and sales teams visibility into which stage-gated milestone payments (where a buyer's schedule includes a payment tied to "on approval of building plan," for instance) are legitimately due to trigger.

Buyer Default and Cancellation

Buyer default, a purchaser who stops paying installments partway through the schedule, and buyer-initiated cancellation, someone who wants out of an agreement before completion, are both real and recurring situations in Bangladesh real estate sales, not edge cases. Handling them consistently matters both for cash flow planning and for the developer's reputation in a market where word travels fast about how a company treats buyers in distress.

The system-level fix is defining the forfeiture and refund policy explicitly in the sales order terms at the point of sale, not improvised at the point of cancellation: typically a percentage of amount paid is retained (covering the developer's incurred marketing, processing, and holding costs) with the remainder refunded, and Odoo's accounting can calculate this consistently once the policy percentage is stored against the sales order rather than negotiated fresh each time. This also gives management a clean reporting view of default and cancellation rate by project and by sales channel, which is a genuinely useful early-warning indicator: a spike in cancellations on a specific project often signals a pricing, construction delay, or sales-process problem worth investigating before it spreads to more buyers.

Collections and Follow-Up Discipline

With installment schedules running years long across hundreds of buyers, overdue payment tracking cannot be a manual phone-call exercise once a project passes roughly fifty active buyers. Odoo's standard customer aging report under Accounting > Reporting > Aged Receivable, combined with automated payment reminder emails or SMS (the SMS gateway setup covered in Odoo Email & SMS Setup Bangladesh applies directly here, since Bangladesh buyers respond more reliably to SMS payment reminders than email for this kind of transaction), gives a developer's collections team a prioritized, system-generated worklist instead of a spreadsheet someone updates inconsistently.

A well-configured collections view segments overdue buyers by how many installments they are behind and by total amount outstanding, since a buyer one installment behind by a small amount needs a different follow-up approach than one several installments behind on a large sum, and conflating the two in a single undifferentiated overdue list is a common reason collections effort gets misallocated on a large active buyer base.

Reporting a Developer Actually Needs

Beyond individual project costing and collections, the reports that matter to a developer's principals are portfolio-level ones: cash collected versus cash contractually committed across all active projects (the gap between these two numbers is effectively the developer's remaining financing need for ongoing construction), per-project margin trend as actual costs land against original estimates, and sales velocity by project and unit type, which of the flat sizes and price points in a given project are moving and which are sitting unsold. The dashboard approach in Odoo Dashboards & KPI Bangladesh applies directly to building this portfolio view for a developer running multiple concurrent projects, which is the normal operating state for any Bangladesh developer beyond its first project.

Managing the Pre-Sale Pipeline

Before a unit becomes an installment sale, it passes through a pre-sale pipeline, site visit inquiries, price negotiations, booking money collection, and agreement signing, that most Bangladesh developers still manage through a sales team's personal contact lists and a shared spreadsheet updated inconsistently between the sales office and head office. Odoo's CRM module, covered in general terms in Odoo Sales & CRM Bangladesh, applies directly here with a real estate-specific pipeline structure: stages for inquiry, site visit completed, unit reserved, booking money received, and agreement signed, each unit tagged to its specific flat or plot so the same inventory item cannot be double-booked by two sales staff working the same project from different desks.

This matters more in real estate than in most other Bangladesh sales contexts because the inventory being sold is entirely non-fungible: unlike a trading company selling from a stock of identical SKUs, a developer is selling one specific flat on one specific floor with one specific view, and a sales team without a shared, real-time view of which units are reserved routinely wastes a prospective buyer's time confirming interest in a unit someone else already booked an hour earlier. A simple Odoo CRM configuration with unit-level reservation status visible to the whole sales team removes this entirely preventable friction, and it is often the fastest, cheapest win in an early-phase real estate Odoo rollout, well before the more involved project costing and installment billing configuration is built out.

Rolling It Out Across an Active Project Pipeline

Real estate developers rarely get the luxury of implementing Odoo before their first project is already selling, which shapes the realistic rollout sequence:

• Migrate existing buyer payment schedules for active projects first, since incomplete or inaccurate migration of who owes what, by when, is the single highest-risk failure point in a real estate ERP rollout.
• Set up project costing and analytic accounts for every currently active project even if some are already partway through construction, backdating cost entries where source documents allow, rather than starting cost tracking only from go-live forward and losing visibility into the true project-to-date cost.
• Build the RAJUK approval tracking structure next, populated with current status for every active project, since this is usually the fastest win with the least data migration risk.
• Introduce automated collections reminders gradually, starting with the most overdue segment first, to avoid overwhelming the sales and collections team with a sudden volume of system-generated follow-ups they are not yet prepared to action.
• Finalize the default/cancellation policy configuration before the next cancellation happens, not after, since retrofitting a consistent policy after several inconsistent manual settlements have already occurred creates its own fairness dispute among affected buyers.

Frequently asked questions

Does Odoo have a built-in real estate installment sales module?

No, Odoo does not ship a purpose-built real estate payment-plan module the way some dedicated property management software does. A Bangladesh developer builds installment-based plot or flat sales using standard Sales and Accounting building blocks: each unit is a product, each buyer's payment schedule is modeled as a sales order with milestone or recurring invoice lines mapped to the agreed schedule (typically a booking payment, followed by construction-linked or calendar-linked installments over one to five years), and Accounting's customer aging and follow-up tools track collection status per buyer per installment. It takes deliberate configuration rather than a checkbox, but it is a well-supported pattern once built correctly.

How do you calculate per-unit profit margin on a real estate project in Odoo?

Per-unit margin requires rolling up land acquisition cost, direct construction cost, and allocated shared overhead (architect and engineering fees, RAJUK approval costs, sales commission, common area construction) across the whole project and then apportioning that total cost to each flat or plot based on a fair allocation basis, most commonly built-up area or plot size. In Odoo this is typically modeled using Project or Analytic Accounting, with the project set up as an analytic account and each cost booked against it, then a costing worksheet (native Odoo reporting supplemented with a spreadsheet extract for the per-unit apportionment) divides total project cost by allocation basis to arrive at a per-unit cost, compared against that unit's actual sale price.

Can Odoo track RAJUK approval status for a real estate project?

Odoo does not have a RAJUK-specific compliance module, but its Project or Documents module can track the approval pipeline (land use clearance, building plan approval, occupancy certificate stages) as a series of tasks or milestones with attached scanned documents, due dates, and responsible staff. This gives a developer a single system-of-record view of where every project stands in the RAJUK (Rajdhani Unnayan Kartripakkha) or equivalent local development authority approval process, rather than relying on a coordinator's personal folder of paperwork, which becomes especially valuable when a developer runs several projects at different approval stages simultaneously.

How should buyer default or cancellation be handled in Odoo?

Buyer default and cancellation is a real, recurring scenario in Bangladesh real estate sales, and it needs a documented policy reflected in the system rather than an ad hoc negotiation each time. In Odoo, this is handled by defining the forfeiture or refund percentage in the buyer's sales order terms up front, so when a cancellation is processed, the system calculates the refund due (total paid minus the contractually agreed forfeiture percentage and any documented deductions) consistently rather than through a manual, case-by-case calculation prone to inconsistency between buyers, which is itself a source of disputes and reputational risk for a developer selling repeatedly in the same market.

What does an Odoo implementation cost for a Bangladesh real estate developer?

For a developer running 1 to 5 active projects with combined unit counts in the range of 50 to 300 flats or plots, an Odoo implementation covering installment sales tracking, project costing, and RAJUK-adjacent document tracking typically runs BDT 10 to 25 lakh, with BDT 4 to 10 lakh per year for support, varying significantly based on how many active projects need concurrent costing and how much customization the payment schedule logic requires beyond Odoo's standard recurring invoicing capability.