Payment Plans and Collections: The Manual Work Behind Off-Plan Sales

Every off-plan sale looks finished on the day the sales agreement is signed. The unit is reserved, the deposit has cleared and the sales team moves on to the next buyer. For finance, that is when the work begins. A payment plan can run for years, tied to construction milestones or fixed dates, and every instalment has to be tracked, reminded, collected, receipted, reconciled and reported.

In many developers and brokerages, that chain is held together by people. A collections officer exports an ageing report from the ERP, pastes names into a spreadsheet and checks the CRM to see who owns the relationship. Reminders go out from personal WhatsApp accounts. Receipts are raised by hand after someone matches a bank transfer to a unit number. None of it is exotic, and all of it is slow.

This article looks at where that manual work sits, what it costs when your systems do not talk to each other, and how to fix it without replacing software you have already paid for. It is also a revenue operations problem. The handoff between sales, finance and customer service is where booked revenue turns into collected revenue, and in most organisations nobody owns it end to end.

What a payment plan asks of your systems

A payment plan is a schedule of obligations: a booking deposit, a percentage on signing, instalments on set dates or construction milestones, and a final payment at handover. Plans are rarely static. A buyer asks to move a date, a sales manager grants a concession, a unit is swapped, or a post-handover plan is restructured.

Each change has to be right in several places at once: what is owed, when, against which unit, in which currency, and under which tax treatment. The sales team records the deal. Finance holds the ledger. The bank or gateway holds the cash. The escrow account holds the regulated portion. Customer service holds the conversation with the buyer. Five places, one fact, and no guarantee they agree.

The stack most developers are running

Most developers and brokerages, in whatever market they operate, have the same four building blocks, even if the brand names differ.

• ERP. Oracle, SAP or Microsoft Dynamics is common, or a real estate-specific finance package. This is the system of record for receivables, the general ledger, invoicing and tax. It knows what should have been paid. It rarely knows what the customer was told.
• CRM. Salesforce, Dynamics, Zoho or HubSpot holds the lead, the buyer, the broker, the unit interest and the sales history. It knows who the customer is and who owns the relationship. It often holds a version of the payment plan that was true at signing.
• Payment gateways. Card and online payment links, bank transfer references and cheque deposits arrive through different channels, each with its own reference format and settlement timing. The gateway knows a payment arrived. It does not know which instalment it was meant for.
• Escrow reporting. In many jurisdictions, regulated off-plan projects must route buyer funds through escrow arrangements, with reporting back to the bank and the regulator. This depends entirely on the ledger and the collections data being clean.

Each system does its own job well. The trouble is the handoffs, and the handoffs are done by people.

A day in collections, without a backbone

Consider a mid-sized developer with two towers under construction in one country and a new launch in another. It is the last week of the month and a milestone-linked instalment has fallen due across around a hundred units.

The collections officer starts the morning by exporting the due list from the ERP. The CRM is a separate login, so she searches buyer by buyer to confirm contact details and note whether a sales manager has agreed an extension. Some extensions live in the CRM as a note. Some live in an email. Some live in the sales manager's memory. She builds a spreadsheet to reconcile these, and that spreadsheet becomes the real working document for the day.

By late morning, a payment arrives from a buyer abroad. The transfer reference is a partial unit number and a surname spelled differently from the CRM. Someone in finance has to decide which instalment it belongs to, and while they work that out, the customer calls sales to ask whether it was received. Sales cannot see the bank statement. Finance cannot see the call. By the afternoon, the buyer has been told two different things by two different people.

Now multiply that by every site. When each project or country office keeps its own spreadsheet and its own habits, leadership has no single view of what is due, what is late and what has been promised to whom. Nothing here is a failure of effort. Each person did their job. The failure is that the job was designed around systems that do not share the facts.

Reminders and receipts: where the hours go

Reminders are the most visible manual task, and the most inconsistent. In many markets, customers now expect messaging apps such as WhatsApp. A formal email may sit unread, while a short message gets answered within the hour. So collections officers and sales coordinators send reminders from their own phones, or from a shared business number with no link back to the ERP or CRM.

That creates several problems at once:

• Wrong amounts. The reminder is typed from a spreadsheet that may be a week old. If the plan was amended, the buyer receives a figure that contradicts their contract.
• Wrong language. A multilingual customer base may prefer a range of different languages, and the message goes out in whichever language the sender is comfortable with, rather than the one recorded on the customer's profile.
• No audit trail. The CRM shows no record that a reminder was sent, so the next person chasing the same buyer repeats it or contradicts it. Customer contact details and payment information also end up on personal devices, which sits awkwardly with data protection laws such as GDPR.
• Reminders after payment. A buyer who has already paid receives a chaser because the payment has not yet been matched. That is a quick way to irritate a customer who is about to spend a great deal more with you.

Receipts follow the same pattern. A receipt should be issued once cash is matched to an instalment, carrying the right unit, amount, date and tax details. Where regional e-invoicing mandates apply (for example, Peppol-based schemes), the document also has to meet the required format and be reported correctly. When receipts are produced by hand from a template, formatting varies, numbers are mistyped, and the receipt may be delayed by days. A buyer who has paid and has not received proof of payment is a buyer who calls, and who starts to wonder how carefully the rest of their purchase is being managed.

Escrow reporting and the month-end scramble

Escrow reporting is where small data errors become expensive. A developer has to show, with evidence, what was collected, from whom, against which unit, and how it was applied. If the ERP, the CRM and the bank statements disagree, someone has to reconcile them by hand before a report can go out.

Consider the month-end of a developer working through a peak season, when working hours shorten, staff take leave around public holidays, and the collection calendar compresses. The finance team spends days tying instalments to bank lines, chasing sales for missing payment-plan amendments and correcting unit references. The report is eventually produced, but the same people who should be following up late payments have spent the week on reconciliation.

The pattern repeats at quarter-end and at each launch, when new projects, new bank accounts and new payment plan structures all arrive together. For a multi-country group, it repeats in every entity, each with its own bank formats, reporting rules and calendar. Without a link between systems, volume is absorbed by overtime rather than by process.

Where the money leaks

When these handoffs are manual, the cost does not appear as one big line. It shows up in small, ordinary ways:

• Late collections. If reminders depend on someone remembering, some instalments will be chased late. Every extra week outstanding is working capital the project is not using.
• Unapplied cash. Payments sit in a suspense account because nobody could match the reference. The money is in the bank, but the buyer's account still shows an overdue balance.
• Concessions nobody recorded. A waived fee or a shifted date agreed verbally never reaches the ledger, so the buyer is later charged or chased for something the company promised to forgo. Reversing it costs goodwill as well as time.
• Tax and invoicing errors. VAT treatment differs by property type and jurisdiction. Where a charge, a receipt or an adjustment is keyed by hand, a wrong code is easy to make and slow to find.
• Forecasts nobody trusts. If leadership cannot see collected, due and overdue amounts from one consistent source, cash forecasts are assembled by hand and argued over before they are used.
• Staff time. Skilled finance and customer-success people spend their days copying data between screens. That is a hidden payroll cost, and it is also why good people leave.

None of these will look alarming alone. Together they describe an operation that works only because capable people are compensating for its design.

How The Ninjaz Group approaches it

The Ninjaz Group is a managed-services partner that designs the change, wires a client's existing systems into one operating backbone, and stays on to run it. For payment plans and collections, that work usually follows three phases, and you can stop after any one of them.

Blueprint. We map the collections operation end to end: from signing, through the payment plan, reminder, payment, receipt and reconciliation, to escrow reporting. For groups with several sites, we map how each location does it and where the practices differ. The aim is to find every gap where work is done twice, data goes stale or money leaks. You keep the map whether or not you continue with us, and many teams find the map valuable on its own, because it shows which of the manual steps matter and which exist only out of habit.

Build & Link. We then build what is missing and connect the systems you already have into one backbone. There is no rip-and-replace. Your ERP, CRM, gateway and messaging stay in place. In practice this means the payment schedule in the CRM and the receivable in the ERP stop being separate copies, and gateway payments can be matched to the right instalment. Reminders can be triggered from the live schedule, in the customer's recorded language, and receipts follow cash matching rather than someone's to-do list. Once the data is shared, a central command center or operating-center view becomes possible for leadership: what is due, what has been collected, what is overdue and which concessions are open, across every project and location. This work sits in our Managed Link layer, the operating layer between systems, which we build, own and maintain so that finance, CRM, website and messaging behave like one system.

Operate. Systems drift. Plans change, banks update formats, tax rules move, and projects launch. In the Operate phase, our managed and remote IT support, monitoring and continuous improvement keep the backbone working after go-live, as your operations and IT team without the headcount.

Delivery combines local strategy and account leadership in your market with engineering, AI development and support from our dedicated delivery operation in India, working across your business hours. We sell the outcome, not software: a collections process that runs from one set of facts.

Where to start

You do not need to fix everything at once. A sensible first step is to pick one project and follow a single instalment from due date to escrow report, writing down every person, spreadsheet and screen it touches. Count the points where someone re-types, re-checks or re-sends. That list is the case for change, and it is usually more persuasive than any presentation.

If you would like a second pair of eyes on that exercise, or want to see what a Blueprint would look like for your own collections operation, book a consultation. We will start with how your payment plans actually run today and be straightforward about what is worth connecting, what is worth leaving alone, and what it would take to get your teams out of the spreadsheets.