In Dubai's off-plan regime, the money a buyer pays does not reach the developer's operating account. It goes into a project escrow account — a trust account tied to that specific project — and the developer draws from it as construction is certified. The structure exists because buyers were once asked to fund buildings with no guarantee the money would be spent on them. For a developer, it means cash availability is a function of certified progress, not of sales.
The chain, end to end
- Project registration. The project is registered and the escrow account opened with an accredited escrow agent.
- Buyer payments in. Every instalment goes into the account, referenced to the unit. Payments made anywhere else create a compliance problem and a registration problem — see Oqood registration.
- Construction proceeds. Work is executed and measured on site.
- Certification. The appointed engineer or consultant certifies the completed percentage.
- Release request. The developer submits the request with the certificate and supporting documents.
- Release. Funds are transferred to the developer, less any amounts that must be retained.
- Post-completion retention. A portion is held for the defined period after completion before final release.
What this does to your cash planning
Two consequences follow, and both surprise developers coming from markets without escrow:
Front-loaded payment plans do not front-load your cash. An 80/20 plan puts more money into escrow earlier, but it does not release earlier — release follows the build. A plan designed for liquidity without reference to the release schedule improves the account balance and not the bank balance. Off-plan payment plan structures covers how to choose with this in mind.
A construction delay is a cash event twice over. The project spends longer, and the release that would have funded the next phase does not arrive. Modelling the two together is the only way to see the real exposure.
The document set behind one release
| Document | Produced by | Common failure |
|---|---|---|
| Engineer's or consultant's certificate | Appointed consultant | Percentage differs from the developer's own claim |
| Measurement and supporting records | Contractor and site team | Records assembled after the request rather than during the work |
| Contractor invoices for the period | Contractor | Invoices not matched to certified work |
| Payment records into escrow | Escrow agent | Buyer payments unreferenced, so they cannot be attributed |
| Unit registration status | Developer, via DLD | Sold units not registered, so the sales position cannot be evidenced |
The last row is where developers most often lose time. A release request implicitly asserts a sales and collection position, and if your registered units and your sold units do not agree, that assertion cannot be supported.
Keep the records where the work happens
The practical difference between a developer who submits a release request in a day and one who takes three weeks is not sophistication. It is whether the certificate, the measurements, the contractor bills and the buyer payments are attached to the project as they occur, or gathered afterwards from four departments. The discipline is the same one that makes contractor payment defensible — see certifying a contractor bill.
Reconciling escrow to your own ledger
Once a month, three numbers should agree: total buyer payments recorded in your system for the project, total credited to the escrow account, and total unallocated. Differences are always explainable — a payment made to the wrong account, a transfer in transit, a buyer who paid without a reference. All are fixable in the month they occur and painful a year later.
What to do next
For your largest live project, reconcile last month's buyer payments in your system against the escrow account statement, and check that every sold unit has been registered. Anything unmatched is a release request that will take longer than it should — see how unit, payment and escrow records line up.