An off-plan payment plan decides three things at once: how much cash the project receives during construction, how much risk the buyer carries, and which kind of buyer says yes. The headline ratio — 60/40, 70/30, 80/20 — describes only the split between the construction period and handover. What matters operationally is the shape inside that split, and whether it matches your escrow release profile.
The main structures
| Structure | During construction | At handover | After handover | Typical buyer |
|---|---|---|---|---|
| 60/40 | 60% across booking and milestones | 40% | — | Balanced; the market default |
| 80/20 | 80%, front-loaded | 20% | — | Developer-favourable; needs strong demand |
| 50/50 | 50% | 50% | — | End users cautious about delivery |
| Post-handover | 40–60% | 10–20% | Remainder over 2–5 years | Yield investors |
| 1% monthly | Small booking, 1% per month | Balance | Sometimes | Entry-level and first-time investors |
The escrow constraint nobody plans around
Buyer money in Dubai goes into the project escrow account, and the developer draws against it as certified construction progresses, with a retention held after completion. That means a front-loaded plan does not simply give you more cash — it gives you more cash in escrow, releasable only as the build progresses. A plan designed to improve liquidity that ignores the release mechanism improves nothing. DLD escrow milestone releases covers how the release chain actually works.
Post-handover plans, honestly
Post-handover instalments are a receivable that survives the buyer taking possession, which changes your collection problem. Two consequences:
- Collection continues after handover. The team that chased instalments during construction has to keep chasing after the unit is occupied, with less leverage.
- Title timing matters. How and when the title transfers relative to the outstanding balance has to be set in the SPA, because a buyer holding title with money outstanding is a different exposure to one who does not.
Neither makes post-handover plans wrong. They make them a financing product, which should be priced and monitored as one.
Registration is the real constraint on creativity
A sales manager can invent a plan; the project registration cannot. Plans are registered with the project, and Oqood registration reads from what was approved. Every ad-hoc plan therefore creates a downstream problem — the SPA does not match the registered plan, and the registration stalls. See Oqood registration for what that looks like in practice.
The practical answer is a small, approved menu — three or four plans, each registered, each with its own discount position — and a rule that anything outside the menu needs the same approval as a price change.
Matching the plan to the buyer
- End users respond to a low entry cost and a predictable monthly figure.
- Yield investors respond to post-handover terms, because rental income can service the tail.
- Capital-growth investors respond to lower total price, so they prefer front-loaded plans with a discount attached.
Selling one plan to all three loses two of them. A CRM that records buyer intent at enquiry lets the sales floor lead with the right structure — see developer CRM vs broker CRM.
What to do next
List every payment plan currently attached to a signed SPA in your live projects, and check each against the plan registered for the project. Any mismatch is a registration delay waiting to happen — see how plans, units and escrow records line up.