Industry

ERP for Real Estate and Property Management in the UAE

Real estate businesses in the UAE run several different businesses at once. Here is how to structure an ERP so leases, service charges, development projects and owner reporting stop living in separate spreadsheets.

A UAE real estate group is rarely one business. It is a development arm, a leasing operation, a facilities and service charge function, and often a brokerage, all sharing a balance sheet and a finance team. Each part has its own rhythm and its own regulator-facing obligations, and in most firms each part has ended up with its own spreadsheet.

That works until the portfolio grows. Then the month-end takes two weeks, the owner reports disagree with the ledger, and nobody can answer a simple question like which units are three months in arrears without opening four files. This is what an ERP is for in property, and it is worth being specific about how to structure one.

Key takeaways

  • Property, unit and lease should be master data in the ERP, not columns in a spreadsheet, because every billing, collection and reporting question resolves back to them.
  • Development and management need different accounting structures, project accounting versus recurring contract billing, but they belong in one system with one chart of accounts.
  • Dubai's Mollak platform stays the official record for jointly owned property service charges. The ERP's job is to produce clean, reconcilable numbers for it.
  • Escrow discipline under Dubai Law No. 8 of 2007 is easier to evidence when the project code runs through sales, receipts, commitments and certified progress.
  • Owner and investor reporting is the deliverable that justifies the project. Design it before you configure anything else.

Start with the property, unit and lease register

Almost every failed property ERP we are asked to rescue made the same early mistake: it treated buildings and units as text on an invoice rather than as master data. Once that happens, nothing aggregates. You cannot report by tower, you cannot compare yield across communities, and you cannot answer an arrears question without manual work.

The structure that holds up is a hierarchy: community, then property or tower, then unit, then lease or contract. Every transaction in the system, rent invoice, service charge, maintenance cost, capital spend, carries the unit and therefore rolls up automatically. Get this right and most of the reporting you want falls out of the system for free. Get it wrong and you will be building reports by hand for the life of the platform.

Leases then sit on top of the unit as recurring contracts with a start date, end date, escalation clause, cheque or payment schedule, and renewal terms. The system generates the invoice schedule from the contract rather than someone raising invoices manually each quarter.

Recurring billing and collections

Property billing is unusual because it is predictable and high volume at the same time. A portfolio of 800 units generates thousands of scheduled invoices a year, plus service charge cycles, plus ad hoc recharges for utilities, chiller and maintenance. Manual invoicing at that volume is where errors and revenue leakage live.

What to insist on:

  • Invoice schedules generated from the lease, so a renewal or escalation flows through without re-keying.
  • Post dated cheque and instalment tracking, still a practical reality in UAE leasing, with clear visibility of what is presented, cleared and returned.
  • Automatic recharges for utilities and chiller against the correct unit and period.
  • An arrears view by unit, tenant and building that finance and the leasing team read the same way.
  • Deposits and refunds tracked as liabilities against the unit, not as a note in someone's file.

Service charges and jointly owned property

For Dubai jointly owned property, service charges sit under Law No. 27 of 2007, with budgets approved and monitored by RERA and administered through the Mollak platform run within the Dubai Land Department. Service charge funds are held in supervised accounts and cannot be drawn against without an approved budget.

This shapes the ERP design more than most vendors admit. Mollak is the official platform, so the sensible objective is not to replace it. The objective is that the ERP holds the accounting substance cleanly: the approved budget by cost line, the unit entitlements that drive each owner's share, the invoices raised, the collections received, the actual spend against budget, and the reserve fund position. Everything that goes to the platform should be reconcilable back to the ledger in one step.

The failure mode is a management company that maintains service charge accounting in spreadsheets alongside the platform, then spends every audit cycle reconstructing the link between the two. Building it properly once in the ERP removes that work permanently.

Development projects and escrow

The development side is project accounting, and it carries a regulatory constraint that pure contractors do not have. Under Dubai Law No. 8 of 2007, each off plan project requires its own escrow account with a RERA approved bank, buyer money passes through that account, and withdrawals must be supported by certified construction progress. Annual audit of the escrow position is part of the regime.

In practice this means the project has to be a controlling dimension throughout the system rather than a label added at reporting time:

  • Unit sales and buyer payment plans linked to the project and the specific unit.
  • Receipts identified against the escrow account, so the project's funded position is visible without a bank statement exercise.
  • Contractor and consultant commitments, certified valuations and retention held per project.
  • Cost to complete maintained continuously, because it is the number that supports both drawdown requests and revenue recognition.

Where a group both develops and then manages what it built, the handover point matters. The ERP should carry a defined transition where completed units move from project work in progress into the property and unit register, so the asset, the warranty period and the first service charge cycle all start from the same record.

VAT and e-invoicing in a property context

Real estate VAT in the UAE is not uniform, which is exactly why it should be handled by configuration rather than by memory. Residential and commercial treatments differ, and the correct treatment depends on the nature of the supply. The practical requirement is that the tax treatment is driven by the unit and contract type held in the system, so the right code is applied automatically at invoice generation instead of being chosen by whoever raises the invoice.

On e-invoicing, the UAE regime phases in from 2026 with the voluntary period, moving to mandatory application across 2027 by business size. High volume, recurring billers such as property companies have more exposure to this than most, simply because of transaction count. Two things are worth doing early: make sure customer master data, particularly tax registration numbers and legal names, is clean, and confirm how your platform will connect to an Accredited Service Provider. Those are the two items that consistently take longer than firms expect.

Owner, investor and board reporting

For a management company, the owner report is the product. For a developer, the investor and board pack is how the business is judged. Both are usually the last thing designed and the first thing complained about.

Design them first. Write down the exact reports you need to produce, per owner, per building, per project, per entity, and then configure the system so those reports are a query rather than an assembly job. Typical requirements include occupancy and yield by building, arrears ageing by tenant and unit, service charge budget against actual by cost line, project cost to complete and margin, and consolidated results across a group that often holds each asset in a separate entity.

That last point deserves attention. UAE property groups are frequently structured with multiple companies, sometimes across free zone and mainland. Multi entity consolidation with intercompany elimination should be a selection criterion from day one, not a phase two aspiration.

How to scope this without over-building

Property ERP projects go wrong in a predictable way: the group tries to build development, leasing, facilities, brokerage and owner portals simultaneously, and the scope collapses under its own weight. A more reliable sequence is to establish the property, unit and lease master data first, then recurring billing and collections, then service charges, then project accounting, then the reporting layer that sits across all of it.

Ask any prospective partner to show you their design for the unit and lease hierarchy before they show you a demo. If they cannot explain how a single lease renewal flows into billing, the ledger, the arrears report and the owner statement without manual intervention, they have not thought about property specifically. That question separates the partners who have delivered real estate implementations from the ones who will learn on your project.

At Kaido we implement across Odoo, SAP Business One, NetSuite, Dynamics 365 and others, and we take no vendor commissions, so the recommendation for a property group depends on the portfolio, the entity structure and the reporting obligations rather than on which licence we would prefer to sell.

Running property on spreadsheets and a basic accounting package?

Book a free consultation and we will map your leases, service charges, projects and owner reporting against what an ERP can actually carry. No obligation, and we take no vendor commissions.

Book a discovery call →