Tracking off-plan payment milestones for your buyers

How an off-plan payment plan works

Off-plan means buying a property before it is finished, from the developer's plans. Instead of paying the full price at once, the buyer pays in stages set out in a payment plan inside the sale agreement (the SPA, sale and purchase agreement). The stages usually fall into two patterns: payments tied to calendar dates, and payments tied to construction milestones such as completion of a floor or the building structure. Many plans mix both, with a deposit at booking, instalments during construction and a final amount at handover. Some developers also offer post-handover plans, where part of the price is paid after the buyer receives the keys.

I am describing the shape, not the rules. How buyer payments must be handled, and how the sale is registered, are set by Dubai's property authorities. Published guides explain that off-plan buyer payments are meant to go into a project escrow account (a bank account that holds buyers' payments for the project) and that the sale is recorded on a system called Oqood run by the Dubai Land Department (DLD, the government body that registers property). Confirm the current requirements, fees and timelines with DLD directly before advising a client.

Why the brokerage cares

The developer sends the payment demands. So why is it your problem? Because the buyer calls you. Buyers forget dates, change phone numbers, are travelling, or assume the broker is watching. A late instalment can lead to charges or worse under the contract, and a client who feels you let them slip will not refer you. For investors who bought several units across projects, nobody has the full picture unless you build it.

Where tracking breaks down

• The sheet has one owner. The person who built it leaves, goes on leave, or just forgets to update it.
• Milestone-linked dates move. A construction-linked payment has no fixed date. Somebody has to learn that the milestone has been reached, and then tell the buyer.
• Reminders are manual. Agents send messages when they remember. The buyer with the biggest unit gets the same effort as the smallest.
• No single view per buyer. An investor with units in three projects has three lines in three places.
• Payment status is guessed. Without a record of what was actually paid and when, you end up asking the buyer for a bank receipt every time.
• Currency and amounts are typed by hand. One slip in a percentage and the whole schedule is wrong.

What a tracker should do

Whether you use a ready-made tool or have one built, the useful checklist is short:

1. One record per unit. Buyer, project, unit, price, SPA date, and the full schedule of payments with each amount and due date or milestone.
2. Percentages and amounts calculated for you. Enter the plan as percentages of price and let the tool compute the amounts, so nobody retypes numbers.
3. Status per payment. Upcoming, due, paid, late, with the date and a place to attach proof of payment.
4. Milestone handling. A payment tied to construction progress shows as "waiting for milestone" until someone marks it reached.
5. Reminders before the due date. A message to the buyer, and a task for the agent, at fixed points before each payment (for example two weeks and three days out). The exact timing is your choice.
6. An investor view. A simple page the buyer logs into to see their own plan, what they have paid and what is next. It reduces "what do I owe?" calls. This is the same idea as a client portal.
7. A manager's list. Everything due in the next 30 days across all buyers, and everything late, on one screen.

How software and AI help with off-plan instalments

The reminder itself is a date and a message, so plain software does it better than AI. A scheduled job reads the due dates and sends the message. This is exactly what business process automation is for.

Where I would add AI is at the edges:

• Reading the payment plan. You can give an AI tool the payment plan page of an SPA and ask it to list each instalment with its percentage and date or milestone. It turns twenty minutes of typing into a draft to check.
• Wording reminders. A short, polite message in English or Arabic that mentions the project, the amount and the date.
• Summaries for investors. A plain paragraph on what has been paid and what comes next. See AI for investor communication for updates and replies.

What still needs a human: checking the extracted schedule against the signed document, deciding when a construction milestone has actually been reached (the developer confirms it), and handling any conversation about a late payment.

WhatsApp is the messaging app most buyers actually read, so reminders go there. It is owned by Meta, and sending automatic messages at volume goes through its business tools, which have their own rules and approval of message templates. Check Meta's current terms for your setup. In the tracker I build for brokers, the reminder goes by WhatsApp, with email as a fallback, and the agent sees every message that was sent.

Spreadsheet or built tracker?

Be honest about where you are. A spreadsheet is fine for a handful of buyers and one person managing it. If you want a starting layout, see my off-plan payment plan template. Move to a real tracker when any of these are true: more than one person edits the sheet, reminders depend on someone's memory, buyers ask for visibility, or you track more than a few dozen active plans.

Check first whether your CRM (customer relationship manager, the system where you keep leads and deals) can do it. Many CRMs can hold custom fields and run reminders, but milestone-linked schedules and a buyer-facing view are where they usually run out. If that is where you are, this is a good case for a small custom build next to your CRM. It is the core thing I make for brokers: a tracker with WhatsApp reminders and an investor view, fed from your own data.

Try it yourself with Claude

Claude is an AI assistant you can chat with in a browser. Paste the payment plan table from an SPA (remove the buyer's name and ID) and ask: "Turn this into a table with columns: number, description, percentage, amount for an example price of AED 1,200,000, due date or milestone. Flag anything unclear." Then compare the answer line by line to the document. Use the same chat to ask for a friendly reminder message for the next due payment. Do not rely on it for legal interpretation of the contract.

Plan types the tracker has to model

A tracker built for one plan shape breaks on the next developer. Published guides (dubizzle, Real Estate Club, Huspy, Binghatti) describe these shapes, and your data model should hold all of them:

• Construction-linked: instalments due at build stages. No fixed date until the developer confirms.
• Split plans such as 80/20, 70/30, 60/40, 50/50: the share paid during construction against the share at handover.
• Time-linked: fixed dates every few months, whatever the build progress.
• Monthly plans: for example a deposit and then about 1% of the price a month. Dozens of rows per unit, so it must be generated, not typed.
• Post-handover: part of the price paid after the keys. Guides describe periods of a few years, but the terms are the developer's, so read the agreement. One source advises checking that any post-handover terms are registered in Oqood, since changes outside the register may not be recognised. Ask DLD to confirm that.

What happens when a payment is missed, and what the tracker should surface

This is the part buyers worry about and most guides skip. dubizzle reports that developers may offer a revised plan or waive late charges (not guaranteed), and that DLD can issue a notice and mediate before a dispute reaches termination, which can mean losing payments made. Another guide quotes late fees and forfeiture percentages, but I could not find those on an official page, so I will not repeat them. Read the late-payment and cancellation clauses in each SPA and record them in the tracker.

So the tracker should store per unit: the grace period if the SPA gives one, the late-payment clause reference, and the date the buyer was last contacted. A payment that is ten days late with no contact logged is the one a manager needs to see first.

Cash the instalments do not show

A buyer looking only at the plan can miss two cash events. The first is the registration fee near the start of the purchase, which I cover in DLD fees explained and Oqood registration. The second is the handover balance. One guide notes mortgages are typically arranged at handover rather than during construction, while another says banks do finance off-plan purchases with a larger upfront share, so ask the bank. Either way, a good tracker flags the handover amount six to twelve months ahead so the buyer is not scrambling.

For investors with several units, show total due per month across all plans. Real Estate Club suggests keeping a cash buffer when stacking plans; I would add that the combined monthly view is what shows an investor they are overcommitted before it happens.

A decision rule for what to build first

1. If you track under about 20 active plans and one person owns them: clean sheet plus calendar reminders.
2. If buyers ask "what do I owe" more than a few times a month: add the buyer view.
3. If milestone confirmations arrive from developers by email or WhatsApp and get lost: build the milestone log first, because it feeds every other reminder.
4. If you manage investors with many units: build the combined monthly view and the handover flag.

For an owner the priority is no missed instalments and a clear paper trail. For an agent it is fewer chase messages. Start with the owner's list.

How I would approach this

Start by writing down, for ten real buyers, what is paid, what is due and what is waiting for a milestone. If that takes more than an hour, the process is already costing you. Put it in a clean sheet first, add reminders next, and only then think about the buyer view. If you reach the point where agents and investors both need to log in, that is when it earns a proper build.