Knowledge Base
Off-plan payment plans in Salesforce: instalments, collections and reconciliation
For a developer, the sale is the start of the relationship. Everything difficult happens in the three years afterwards.
Managing off-plan payment plans in Salesforce means holding the unit, the buyer, the schedule and the money in one place, so that a question like “which instalments are overdue across this tower, and by how much” has an answer that takes seconds rather than a morning.
The CRM part of this is straightforward. The difficulty is agreeing what happens when money arrives late, short, or against the wrong reference — which it does, constantly.
Why a brokerage CRM does not cover this
A brokerage pipeline ends at a closed deal. A developer’s obligations start there:
- A unit generates a schedule of instalments, often tied to construction milestones rather than dates
- Each instalment needs invoicing, reminding, collecting and reconciling
- Payments arrive through multiple channels and frequently do not match the amount due
- Off-plan proceeds in the UAE go into a project escrow account, so what the developer can access is not simply what was received
- Broker commission becomes payable, on terms that may depend on collection rather than sale
- Buyers resell before handover, and the schedule transfers with the unit
None of that fits into an Opportunity with a close date. It needs its own structure.
How off-plan payment plans in Salesforce are structured
The objects involved
- Project — the development, holding milestone definitions and the escrow arrangement
- Unit — the individual property, with status from available through reserved to sold and handed over
- Sale — the agreement between buyer and developer for a specific unit
- Payment Schedule Line — one record per instalment, with due trigger, amount and status
- Payment — money actually received, which is deliberately separate from the instalment it settles
Keeping Payment separate from Payment Schedule Line is the design decision that makes everything else possible. A single payment can settle part of one instalment, or two instalments at once, or arrive with no clear reference at all. If money and obligation are the same record, none of those can be represented honestly.
Milestone-driven schedules
Off-plan schedules in this market are often tied to construction progress rather than the calendar:
| Trigger type | Example | CRM implication |
|---|---|---|
| Date | Booking deposit, then monthly | Simple scheduling |
| Construction milestone | On completion of the structure | One milestone update generates hundreds of due instalments at once |
| Handover | Final instalment on possession | Ties to a per-unit event, not a project-wide one |
| Post-handover | Instalments continuing after possession | The schedule outlives the project record |
The second row is where systems break. Marking a milestone complete on a 1,000-unit project makes a thousand instalments due simultaneously, each needing an invoice and a notification. Design for that volume from the start rather than discovering it on the day.
Reconciliation, and the four awkward cases
Matching received money to expected money is where most of the operational pain sits. Four cases need an agreed rule before any of it is automated:
- Short payment. Does it part-settle the instalment, leaving a balance, or sit unallocated until the rest arrives? Both are defensible; only one can be the rule.
- Overpayment. Credit against the next instalment, or refund? Silence here produces inconsistent handling across the finance team.
- Unidentified payment. Money arrives with no usable reference. It needs a holding state and an owner, not a spreadsheet on someone’s desktop.
- Late payment. Whether a penalty applies, from which day, and who can waive it.
We built this structure for a 2,500-unit residential development — instalment schedules, collection tracking and reconciliation against the finance system. The technical work took a fraction of the time spent agreeing those four rules, which is the honest lesson from that project.
Where the finance system fits
The CRM should not try to be the accounting system. A workable division:
- Salesforce owns the schedule, the customer relationship, reminders, collection status and sales reporting
- The finance or ERP system owns the ledger, receipts and statutory reporting
- The integration carries confirmed receipts inward and invoice requests outward
The rule that keeps this clean: a payment is only “received” in Salesforce when finance has confirmed it. A sales team marking payments received creates a reconciliation problem that takes months to unwind.
Reporting a developer actually uses
- Collections due this month, by project and by milestone
- Overdue balance, aged — not just a count of late instalments
- Collection rate by payment plan type, which informs how future plans are structured
- Units sold versus units collected on, a gap that widens quietly
- Broker commission payable, split by earned and paid
The fourth line is the one that surprises management. A project can be 95% sold and considerably less than 95% collected, and the difference is the working capital nobody budgeted for.
Resales before handover
A buyer selling their unit before completion is routine in this market and awkward in most systems. The unit does not change, the schedule mostly does not change, but the counterparty does.
Model it as a transfer on the Sale record with history retained, rather than closing one Sale and opening another. Closing and reopening breaks the payment history, and the payment history is exactly what somebody will need when a dispute arises two years later.
Frequently asked questions
Can Salesforce manage off-plan payment plans?
Yes, using custom objects for the project, unit, sale, schedule lines and payments. Schedules can be driven by dates, construction milestones or handover, with instalments generated accordingly.
How are construction milestone payments handled?
A milestone update on the project marks the corresponding instalments due across every affected unit at once. The design needs to anticipate that volume, since one update can generate hundreds of invoices and notifications.
Should Salesforce hold payment records or the finance system?
Both, with a clear division. Salesforce holds the schedule, collection status and customer communication; the finance system holds the ledger. A payment is marked received in Salesforce only once finance confirms it.
What happens when a buyer pays less than the instalment?
That is a policy decision to make before automating: either it part-settles the instalment and leaves a balance, or it sits unallocated until the full amount arrives. Inconsistent handling is what creates reconciliation problems.
How are resales before handover handled?
As a transfer on the existing sale record, with the payment history retained. Closing the original record and creating a new one loses exactly the history needed if a dispute arises later.
Does this work alongside portal lead capture?
Yes. The same Salesforce org can capture enquiries from property portals and manage the post-sale payment lifecycle, which is usually the point for a developer selling directly as well as through brokers.
Talk it through
If collections are tracked in spreadsheets alongside your CRM, tell us how your projects and payment plans are structured. Get in touch — the first assessment is free.
Let us look at your collections process
Tell us how many units you are selling and how payment plans are structured. We will come back with scope, timeline and an indicative cost — free, and with no obligation.