How Do You Track Off-Plan Payment Plans Without a Spreadsheet?

Hold the payment plan against the unit rather than in a file. Each instalment needs a trigger (a date or a construction milestone), an amount, a status, an owner and a reminder. Once those five fields exist per instalment, statements, buyer reminders and collection forecasts all come from one record instead of three spreadsheets.

A payment plan is not a document you send once. It is a schedule with a state, and the state changes every time money moves or a construction milestone slips.

Key takeaways

• Dubai recorded over 270,000 real estate transactions worth AED 917 billion in 2025, up 20% year on year in transaction numbers and 29% in investment value, with approximately 193,100 investors, of whom 129,600 were new (Dubai Land Department, reported by Dubai's Public Debt Management Office).
• A spreadsheet records what a payment plan is. It does not record what has happened to it, which is the only part an agent needs at 16:00 on a Tuesday when a buyer rings.
• The unit of tracking is the instalment, not the unit and not the buyer. A plan with seven instalments is seven records with seven states, and collapsing them into one row is where the errors begin.
• Milestone-triggered instalments have no fixed date until the milestone is reached. Any system that stores only a date is storing a guess, and it will be wrong the first time construction slips.
• Payment reminders sent on WhatsApp are governed by the customer service window: "when the window closes, you can only send pre-approved template messages" (Meta for Developers, Send messages, checked 7 September 2026). A reminder to a buyer who has not messaged you in 24 hours needs an approved template.
• Version drift is the failure nobody notices until it is expensive. Three copies of a schedule circulating by email means three different answers to "how much do I owe in March".

How are Dubai off-plan payment plans usually structured?

Off-plan plans in Dubai are commonly advertised as a pair of numbers, such as 60/40 or 40/60, describing the share payable before handover against the share payable at or after it. Underneath that headline, most plans are built from three kinds of instalment.

Booking and immediate instalments. A percentage payable on reservation, frequently followed by a second percentage within a fixed number of days of signing. Date-triggered and predictable.

Construction-linked instalments. A series of percentages falling due as the project reaches stated stages of completion. Milestone-triggered, which means the date is an estimate until the milestone is certified.

Handover and post-handover instalments. A balance payable at handover, and in some plans a further schedule running for a defined period afterwards, typically date-triggered from the handover date.

A note on scope, because this is where property content usually overreaches. This article covers the operational problem of tracking a schedule. It does not cover registration, government fees, or the regulatory and contractual framework surrounding an off-plan sale, including what follows a missed instalment. Those matters vary by project and by agreement, and they should come from the sale and purchase agreement, the developer and your own legal advice, not from a CRM vendor's blog.

What does an off-plan payment schedule actually look like?

The table below is an illustrative example constructed for this article. It is not a real project, not a real developer's plan, and not a recommendation. It exists to show the shape of the data a system has to hold.

Illustrative example only. Unit price AED 1,800,000. Plan structure 60/40, booking 15 March 2026, estimated handover Q3 2028.

Two things in that table cause every downstream problem. First, five of the seven instalments have an estimated date rather than a real one, because the trigger is a milestone. Second, the status column changes over time while everything to its left stays fixed. A spreadsheet handles the fixed columns perfectly well. It handles the moving one badly.

What goes wrong when payment plans live in a spreadsheet?

Four failures, in the order brokerages usually meet them.

Missed milestones. A construction stage is certified, an instalment becomes due, and nobody is told, because a spreadsheet has no way to notice anything. The first person to find out is often the buyer, when the developer contacts them directly, which is a poor advertisement for the agency that sold them the unit.

Wrong figures given to buyers. A buyer asks what is outstanding. The agent opens the copy on their laptop, current in April, and gives a number one instalment out of date. The buyer now holds a figure from you and a different figure from the developer, and they will trust the developer.

No reminders. Nothing in a spreadsheet reaches out. Every reminder is a human remembering to look, and humans remember for about six weeks after a process is introduced. The decay is silent, and only visible when a payment is late.

Version drift. The most expensive one, because it is invisible while it happens. A schedule is emailed to the buyer, amended after a plan change, re-emailed by a second agent, and saved to a shared drive by a third. Four versions exist and none is authoritative.

Underneath all four sits the same structural problem: a spreadsheet stores the plan, but the thing you need to manage is the plan's state. The state changes on events, and a spreadsheet has no events.

What does a system need to hold for every unit?

Not a document, a set of records. One record per instalment, each carrying enough to answer a buyer's question without opening anything else.

The last row is the one most teams skip and the one that resolves disputes. If a plan is amended, the record should show that it was amended, by whom and when, rather than silently becoming the new truth.

Spreadsheet or system: what actually changes?

The honest boundary is somewhere around a dozen units under active plans. Below it, a well-kept spreadsheet owned by one disciplined person is genuinely adequate and anyone telling you otherwise is selling. Above it, the number of state changes per month exceeds what one person can track by inspection, and the failures stop being occasional.

How does payment tracking connect to buyer communications?

Directly, because almost every buyer conversation after the sale is about the schedule: what is due, when, how much, and what happens if the project slips. An agent who has to assemble that answer from a file is slow, and a slow answer about money reads as an evasive one.

Three connections matter operationally.

Reminders have to originate from the instalment. A reminder written by hand is a reminder that stops when the writer goes on leave. A reminder attached to instalment 4 fires whether or not anybody remembers instalment 4 exists.

The channel has rules. On WhatsApp, Meta's documentation states that "when a WhatsApp user messages you or calls you, a 24-hour timer called a customer service window starts", and that outside that window "you can only send pre-approved template messages" (Meta for Developers, Send messages, checked 7 September 2026). A payment reminder is almost always business-initiated to a buyer who has not messaged you that day, so it needs an approved template. Write and submit those templates before you need them. The wider mechanics of running WhatsApp across a brokerage are covered in WhatsApp CRM for Dubai.

Statements should be generated, not written. A buyer asking for a summary of what they have paid and what remains should receive a document produced from the records, on demand, identical whichever agent sends it. Anything assembled by hand will eventually disagree with the record it was assembled from.

How does WIYO handle off-plan payment plans?

The Off-Plan Pillar is WIYO's flagship module, and payment plans sit inside it against the unit rather than in an attached file. Instalments are held individually with their trigger, amount, status and owner, so a milestone that moves updates the estimates that depend on it rather than requiring a manual edit of every subsequent row.

Because the module sits in the same workspace as the pipeline and messaging, the schedule, the buyer record and the conversation history are one thing. The seven-stage pipeline (New, Contacted, Qualified, Viewing, Negotiating, Won, Lost) covers the sale, and the payment schedule covers what happens after Won, which is where off-plan differs from resale and where most general-purpose CRMs stop. WIYO also applies AI buyer-to-project matching across off-plan inventory, and operates RERA-aware workflows.

Wider off-plan requirements are set out on the off-plan CRM for the UAE page and in off-plan real estate CRM for the UAE. The pipeline that feeds it is covered in where Dubai property deals actually die.

WIYO is published by WIYO L.L.C-FZ, Trade Licence 2649536.01, Meydan Free Zone, Dubai.

Frequently asked questions

How do Dubai off-plan payment plans usually work?

Most are advertised as a pair of numbers such as 60/40, describing the share payable before handover against the share at or after it. Underneath sit three instalment types: date-triggered booking payments, construction-linked instalments that fall due as the project reaches stated stages, and a handover balance, sometimes followed by a post-handover schedule.

Can I track off-plan payment plans in Excel?

Up to roughly a dozen units under active plans, a well-kept spreadsheet owned by one disciplined person is adequate. Past that, the number of monthly state changes exceeds what one person can track by inspection. Excel stores the plan accurately; what it cannot do is notice a milestone, send a reminder or record who changed what.

What should a payment plan record contain?

One record per instalment, carrying the unit reference, buyer, instalment number, trigger type (date or milestone), trigger value, amount and share of price, status, date paid with reference, a named owner, a reminder rule, and a change history. The change history is the field most teams skip and the one that resolves disputes.

What happens if a construction milestone slips?

Every instalment triggered by that milestone and everything estimated from it moves. In a spreadsheet this is a manual edit of each affected row in every copy in circulation. In a system holding the trigger separately from the estimated date, the estimates shift together and the buyer-facing schedule stays consistent.

How far ahead should you remind a buyer about an instalment?

Set the rule per instalment rather than per buyer, and make it consistent across the book. What matters operationally is that the reminder originates from the instalment record rather than from an agent's memory, so that it still fires when that agent is on leave, has changed desk, or has left the brokerage.

Can I send off-plan payment reminders on WhatsApp?

Meta's rules turn on the customer service window. Inside a 24-hour window opened by the buyer messaging or calling you, free-form service messages are permitted. Outside it, only pre-approved template messages may be sent. A payment reminder is usually business-initiated, so it needs a template written and approved in advance.

What happens if a buyer misses an instalment?

Operationally, the status changes to overdue, the named owner is alerted and the buyer is contacted with the exact figure from the record. The contractual consequences are a separate matter entirely and are set by the sale and purchase agreement and the developer, so take them from that agreement and your own legal advice.

---

Want your payment schedules to live on the unit instead of in a file? Book your free demo at wiyo.ae.

---

Written by Shaffay Bajwa, Founder of WIYO. Software engineer, five years in UAE real estate technology. Published 7 September 2026.