Property instalment sales: receivables, ageing and the customer ledger

One sale, many obligations

A cash sale is one event. An instalment sale of a plot or an apartment is a signed agreement followed by years of dated obligations — a down payment, then a schedule of instalments — each of which will be invoiced, each of which will be paid in full, in part, late or not at all. The developer’s receivable is the sum of what has been invoiced and not yet collected, and it changes every day.

A booking register cannot carry that. It knows which units are sold and for how much; it does not know which instalment is overdue by 47 days, which customer has paid ahead, or what the business is owed this morning. Those are ledger questions, and they need ledger documents: an invoice for every obligation, a receipt for every payment, and an account per customer that both post into.

From available unit to signed agreement

BuilderOne’s Project Selling module runs the sale as a sequence of documents, each of which changes what the unit is and what the customer owes:

1. Unit — inventory in a selling project, with an availability state. A unit is available, reserved, booked or under agreement; two customers cannot hold it at once.
2. Reservation — a customer holds a unit for a period. It is an option, not a sale.
3. Booking — the customer commits, usually with a booking fee. The fee is real money received and is recorded as such; it is not yet revenue.
4. Selling agreement — the contract: agreed price, discount, the customer, the unit and the payment plan. It moves through draft, submitted and approved to executed; the executed agreement is the commercial fact everything downstream reads.
5. Instalment schedule — generated from the executed agreement: the net sale price (agreed price less discount) laid out against the plan’s template as a down payment and a series of instalments, with the booking fee credited once against the down payment. The lines sum to the net price exactly; the final line absorbs any rounding.

The pipeline in front of all this — the lead, the follow-ups, the opportunity — lives in CRM, on the same contact record. A won lead becomes the customer on the reservation without being re-entered, which is why the customer who owes instalments and the lead who was chased six months earlier are the same person in the system.

The schedule is not the receivable. The invoice is.

The instalment schedule is an operational document — it says what will be due and when. It is not a financial fact and it posts nothing. The receivable is created when a schedule line is invoiced: the invoice is the customer’s obligation, with a due date, and it is the invoice accrual that reaches the general ledger as revenue and receivable, attributed to the selling project.

Money coming in is a receipt: an amount, a date, a payment method and the cash or bank account it landed in. A receipt is then allocated to one or more invoices. The allocations are the link between “the customer paid 500,000” and “instalment 4 is settled and instalment 5 is half paid”, and they obey two rules that a spreadsheet never enforces:

• The allocations of one receipt can never exceed the receipt — you cannot apply 600,000 of a 500,000 payment.
• An allocation can never exceed the invoice’s outstanding amount — you cannot over-settle an instalment and lose the excess.

A receipt allocated in error is not edited. It is reversed in full, with a reason, and the receipt and its allocation rows are preserved so the history shows what happened. The receipt posting adapter carries the cash movement into the ledger against the receivable; the reversal is a linked reversing journal.

Receivables ageing: how late, in buckets

Outstanding invoices are aged by days past due as at a chosen date. BuilderOne’s outstanding-invoices register groups them into the buckets below, and can be grouped by bucket, by customer or by currency:

Two details make the register trustworthy. First, ageing is measured to a date you choose — the register does not silently age to “today”, so a month-end ageing can be reproduced. Second, if no date is chosen, the outstanding amounts are still exact but no ageing is stated at all, rather than a misleading one being implied. The recovery worklist on the module’s home is the same data, sorted by who to call first.

The customer ledger, and what it refuses to do

The customer ledger is the account: every invoice, receipt and reversal for one customer, in order, with a running balance. It is the document a customer disputes against, so it has to be exactly right — which is why BuilderOne’s ledger report is strict about scope in a way that is worth understanding.

• It never runs without a subject. A ledger needs a customer, a unit or a project; there is no tenant-wide ledger, because a ledger with no subject is a table scan wearing a report’s name.
• The running balance is stated only for a whole customer. Filter the same customer to one project, or ask for one unit, and the running balance is left blank — a running total over a subset of a customer’s entries is not that customer’s balance and is not anything else either.
• A unit scope is declared incomplete by the report itself: entries that belong to the customer but were never attributed to a specific unit cannot appear, and the report says so as a control fact rather than dropping them quietly.

That last behaviour is the general principle behind the module. A number that looks complete and is not is worse than one that admits what it is missing.

Transfers, reallocations and cancellations

The lifecycle a spreadsheet never survives is the one where the sale changes shape after it is signed. Project Selling treats each of these as a document with its own approval rather than as an edit to the agreement:

Because none of these rewrites history, the customer ledger and the project’s receivable stay reconcilable to the ledger through the change — the thing a “corrected” spreadsheet row can never offer.