An ERP for a real estate developer links two sides of each project that usually live in different systems: the cost side (land, design, construction contracts, consultants, finance costs) and the sales side (unit inventory, reservations, sale contracts, payment plans and collections). Done well, every project shows budget, committed cost, cost to date, units sold, amounts due and cash received in one view.
Developers often run construction costs in an accounting package, sales in a CRM or spreadsheets, and payment plans in a separate tracker. The pain shows up at month end, when nobody can say with confidence how much is overdue on a tower or how much of the budget is already committed.
What does a real estate developer ERP need to do?
It needs to treat each project, and each unit inside it, as a first-class record. Generic ERPs model products and orders; developers need projects, phases, buildings, units and long-running payment schedules.
| Area | What it covers |
|---|---|
| Project structure | Project, phase, building or plot, floor, unit; cost codes per project |
| Budget and cost control | Approved budget by cost code, commitments (contracts and POs), actual cost, forecast to complete |
| Contracts and procurement | Main contractor and subcontractor contracts, variations, progress certificates, retentions |
| Unit inventory | Unit type, area, view, price list, status (available, reserved, sold, handed over) |
| Sales and reservations | Reservation, deposit, sale and purchase agreement, broker commission |
| Payment plans | Instalments linked to dates or construction milestones, post-handover plans |
| Collections | Invoices or demand notices, receipts, reminders, overdue ageing, penalties where the contract allows |
| Escrow and bank accounts | Which receipts go to which account, per project (see the UAE section) |
| Handover | Snagging, completion, title registration status, service charge start |
| Reporting | Project profitability, cash position, sales velocity, collections ageing |
If you have looked at packages and find yourself forcing units and payment plans into product and invoice screens, custom ERP software built around projects and units is worth comparing. Groups with several development companies or SPVs should also read multi-entity ERP governance.
How should project costing work for developers?
Budget by cost code, track commitments as well as actuals, and forecast to complete every month. Actual cost alone tells you too little, too late.
A workable structure:
- Cost breakdown structure. Land, approvals and fees, design and consultants, enabling works, main contract, MEP, finishes, infrastructure, marketing, finance costs, contingency.
- Budget versions. Original approved budget, revised budgets with reasons and approvals.
- Commitments. Contracts and purchase orders raise committed cost when signed, not when invoiced.
- Progress and actuals. Contractor progress certificates and supplier invoices post to cost codes.
- Retentions and variations. Retention held per contract; variations approved and added to commitments.
- Forecast to complete. Project managers update expected remaining cost per code; the ERP shows forecast final cost against budget.
For a deeper look at the accounting mechanics, see our guide to ERP project accounting. Developers who also run their own construction arm should read ERP for construction companies.
How do unit sales and payment plans fit into ERP?
Each sold unit carries a payment schedule, and the ERP should generate what is due from that schedule rather than from manual invoices.
Payment plans differ by project and sometimes by buyer:
- Date-based instalments (for example, a percentage every quarter)
- Milestone-based instalments tied to construction stages that an engineer certifies
- A handover payment
- Post-handover instalments over an agreed period
- Fees and charges collected at specific stages
When a milestone is certified, the system should raise demands for every unit on that milestone, send notices, and track receipts. Changes to a buyer's plan (a rescheduled instalment, a transfer to another unit, a cancellation and refund) need approval and an audit trail.
Illustrative example: one tower, two plan types
A tower has 200 units. Early buyers took a construction-linked plan; later buyers took a plan with a larger handover payment. When the structure reaches a certified stage, the ERP raises demands only for the first group, while the second group's next date-based instalment is due later. The collections dashboard shows both, aged by due date, with the unit, buyer and broker on every line.
What should developers know about escrow in the UAE?
In Dubai, Law No. (8) of 2007 concerning escrow accounts for real estate development (checked on the Dubai Legislation Portal in October 2026) applies to developers selling units off-plan. It requires payments from off-plan purchasers and project financers to go into an escrow account, requires a separate escrow account for each project where a developer runs several, and gives the Land Department oversight, including regular statements from the escrow agent. Other emirates have their own rules.
For the ERP, that means:
- Bank accounts are mapped to projects, and the system knows which receipts must go to which project escrow account.
- Receipts are reconciled per project escrow account, separately from operating accounts.
- Withdrawal requests and supporting documents can be tracked against project progress.
- Reports can show, per project, what was received, what was deposited to escrow and what was released.
Treat this as design input for your finance and legal teams, not legal advice. The ERP is designed to support your obligations; your advisers and the escrow bank confirm what is required. UAE developers should also read our guide to ERP software in the UAE.
Which data should a developer migrate into the new ERP?
Migrate what is still open: active projects with approved budgets, signed contracts with commitments and amounts certified to date, retentions held, every sold unit with its buyer, sale price and remaining payment schedule, receipts to date and overdue balances. Closed projects and fully paid units can be summarised or archived. Reconcile each project's receivables and cost to date against the old records before anyone relies on the new collections dashboard.
In the UK, what changes?
In the UK, off-plan deposits are usually handled through solicitors and contract terms rather than a project escrow law of the Dubai kind, so the ERP emphasis shifts to development appraisal against actuals, funding drawdowns, sales progression with conveyancers, and plot-level costing. The project and unit model is the same.
How should collections and receivables be managed?
Collections are where developer cash flow is won or lost, so the ERP should make the overdue position impossible to miss. Every instalment due should appear in an ageing view by project, building, unit, buyer and broker, with the reminder history alongside.
A sensible collections flow:
- Notices generated automatically before each due date, in the buyer's language where you sell to several markets.
- Receipts matched to the unit and instalment, whether paid by transfer, cheque or through a mortgage lender.
- Reminders at agreed intervals after the due date, with escalation to the sales or legal team.
- Late payment charges calculated only where the sale agreement allows them, and approved before posting.
- Cancellation, resale and refund workflows that reverse the right entries and keep a full history.
Post-dated cheques, still common in some markets, need their own register: received, deposited, cleared or returned, linked to the instalment they settle.
How do broker commissions and handover fit in?
Broker commissions should be calculated from the sale record, using the agreed rate for that broker and project, and released only when the conditions in the broker agreement are met (for example, a minimum percentage collected). That keeps commission payments tied to cash rather than to signed contracts alone.
At handover, the unit moves from the sales side to the operating side. The ERP should record completion, snagging items and their closure, the handover date, and the start of service charges, then pass the unit and owner to property or facilities management if you run it.
Real estate developer ERP checklist
- Project, phase, building and unit hierarchy with statuses
- Cost codes, budgets, commitments, actuals and forecast to complete
- Contractor contracts, variations, progress certificates and retentions
- Price lists and unit availability shared with sales and brokers
- Payment plan templates and per-buyer variations with approvals
- Milestone certification that triggers demands for the right units
- Collections ageing by project, building, unit and buyer
- Bank and escrow account mapping per project (where applicable)
- Broker commission calculation and approval
- Handover, snagging and service charge start dates
- Integration with CRM for leads and with the bank for receipts
When is a custom ERP not the right approach for a developer?
If you build one project at a time with simple payment plans, an accounting package plus a well-run sales tracker may be enough for now. If a property-specific package already handles your payment plans and the reports your lenders ask for, configure it. Custom work fits developers with several concurrent projects, mixed plan types, multiple entities, escrow reporting needs and a CRM or sales portal they want tightly connected to collections.
How to start
Collect a sample of your real payment plans, your cost code structure, your bank and escrow account list, and the three reports your board or lenders ask for most. Use the software requirements brief template, and plan the move of open sales and balances with the ERP data migration plan.
Then discuss the project with us. Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, for example unit inventory with payment plans and collections, so your sales and finance teams can test them on a real project.