Condominium Presale Software Problems: The 7 That Fail a Lender Audit, and How to Avoid Them

Why does this keep getting scoped as a sales CRM?

Because the visible activity is sales. Releases, worksheets, realtor teams, allocation, a signing event. Anyone looking at the process sees a pipeline, and a pipeline is a customer relationship management problem with deals, stages and a close date.

The close is where the model stops being right. A presale contract is not a sale, it is a multi year obligation. It carries deposit instalments that arrive on dates, a rescission window measured precisely from a delivery event you must be able to prove, an amendment history that changes what the purchaser agreed to, money sitting in trust under rules specific to the jurisdiction, an assignment right that may be exercised, and a qualification status a construction lender is relying on. That object has to stay correct for three or four years while the building goes up.

Scope it as a pipeline and you get a sales tracker, the sales director keeps the spreadsheet, and every one of those obligations lives somewhere outside the system.

The fix: make any prospective developer model the domain before they quote. The right answer separates unit, release, worksheet, contract, deposit instalment, amendment, assignment and qualification status, and treats inventory state as an event log rather than a status column, so the price grid at any past date can be reconstructed exactly. If they draw a deals pipeline, you already know what you will be getting and you will keep the spreadsheet alongside it.

What goes wrong with deposits and the trust position?

Deposits get modelled as an amount on a contract row, sometimes with a second column for the next instalment. That works until the second instalment is late, the third is due on a milestone rather than a date, one purchaser paid from a third party account the lawyer will not accept, and another paid the right amount into the wrong project trust.

Reconciliation is the other half. The application does not hold the money, the lawyer or brokerage does, and if the comparison between what should be held and what the trust ledger says is held happens at quarter end, a discrepancy has months to grow. In Canada, purchaser identification and source of funds obligations attach to this process, so a third party payment is not just an accounting question.

The fix: model each instalment as an obligation with a due date, an amount, a status and a document trail, and drive the chase workflow from that rather than from a report. Reconcile against the trust ledger on a schedule so gaps surface in days. Generate late instalment notices from templates that cite the contract clause and record delivery, because enforcing a default later requires proof that notice was properly given. Track deposit protection or insurance obligations per unit where they apply rather than assuming them. And be clear with any developer that the software is never the trust ledger, only the expectation against which the ledger is checked.

Why do the signature, trust and schedule integrations break after launch?

Electronic signature integrations break on the document rather than the interface. A contract package is a set of documents with schedules, disclosure receipts and sometimes jurisdiction specific forms, and the signing order matters. When the package changes for a new phase and the template mapping is not versioned, signatures land on the wrong schedule or a required initial is skipped, and you find out when a lawyer reviews the file.

Trust ledger integrations break on identifiers. The law firm's file numbering is not your unit numbering, a purchaser name changes between the worksheet and the contract, and a payment arrives referencing a realtor rather than a unit. Matching then falls back to a person, which is exactly the manual process you were replacing.

Construction schedule feeds break on meaning. A schedule slip is published, but the field that drives finishing selection cut offs was not the field that moved, so purchasers are notified of a deadline that no longer exists, or are not notified of one that does.

The fix: version document packages and signing sequences per release and per jurisdiction, and test a full package end to end before each new phase rather than assuming carry forward. Reconcile trust payments on unit and contract identifiers you control, with an explicit unmatched queue that a person works daily. Drive selection cut offs from named schedule milestones with an approval step before purchaser notifications go out, because a wrongly issued deadline generates calls from people who have already paid you a deposit.

What happens when disclosure amendments and rescission are not covered?

Presale sales sit inside consumer protection regimes. In British Columbia the Real Estate Development Marketing Act requires a disclosure statement and provides a rescission period after receipt. In Ontario the Condominium Act provides a cooling off period for new condominium purchases. The specifics of period length, what starts the clock and what constitutes proper delivery are jurisdiction specific and belong with your counsel.

The operational consequence is universal though. The clock runs from a delivery event you have to be able to prove, per purchaser, not per project. Over a multi year build there will be several amendments: parking reallocation, amenity changes, completion date extensions, floor plan revisions. Each produces a set of purchasers who received it, a set who acknowledged it, and possibly a set whose rights have changed.

Without a model for that, the two reports you actually need are impossible: which contracts still have an open rescission period, and which purchasers have not acknowledged the current amendment. From a spreadsheet with four hundred rows, neither exists.

The fix: treat the disclosure package as a versioned artefact, record delivery to each purchaser with method and timestamp, and compute rescission expiry per contract rather than per project. Make amendments events that fan out to affected contracts with acknowledgement tracking. Keep the legal interpretation with counsel and keep the evidence in the system.

Should you build custom or configure what you already own?

If you are selling a single tower under roughly 150 units, or you develop occasionally rather than continuously, buy. Avesdo and Spark are purpose built for this market, handle contracts, deposits and reporting to a standard most developers do not exceed, and are priced per project in a way that makes a build hard to justify. Lasso CRM remains a reasonable front end for lead management alongside either.

Before assuming a limit, push your existing tool on the specific thing that is failing. Configurable qualification criteria, instalment schedules and amendment tracking exist in more depth than most teams use, and a week finding that out is cheap next to a build.

Build when several of these are true. You run multiple projects concurrently and need a portfolio view of trust balances, qualification and absorption that no per project tool provides. You operate in more than one jurisdiction with genuinely different disclosure and deposit regimes. Your release and pricing strategy is part of your edge and you want it modelled rather than executed by hand. A lender audit has already produced a lower qualified number than your internal reporting. Assignments are a material part of your activity and currently untracked. The tipping point is continuity rather than volume: a developer selling presales for the next decade is buying an institutional record, a developer with one tower is buying a service.

How do hidden costs get into the quote?

Jurisdictions treated as configuration. Disclosure, rescission, deposit protection and trust rules do not generalise across provinces or states, and a second jurisdiction is real scope with its own document set, its own clock and its own counsel review.

Lenders treated as one. Different facilities define qualification differently, so criteria must be configurable per facility rather than encoded once, and each new facility brings a mapping exercise.

Realtor commission, which sounds trivial and is not. Tranched payments, co-operating brokerages, clawbacks on rescission and different rates per release combine into one of the more intricate calculation problems in the build.

Identity verification. Where anti money laundering identification requirements apply to the purchaser and the source of funds, that is a workflow with document handling and retention rather than a field on a form.

Accounting and trust ledger integration, which is where the reconciliation value comes from and which involves two external parties with their own systems and their own change calendars.

From Digital Heroes delivery experience, a first release covering inventory and release management, worksheet to contract workflow, the deposit schedule with instalment tracking and trust reconciliation, and a configurable qualified presale report runs $80,000 to $170,000 over 12 to 18 weeks. A full platform adding amendments and rescission handling, assignments, upgrade and selection orders, commission tranches and occupancy to closing handoff runs $200,000 to $500,000 across 6 to 12 months.

What separates a build that works from one that fails here?

Qualification computed continuously. Every contract carries its qualification status and the specific reason if it fails, with the lender's criteria expressed as an explicit ruleset per facility. Related party detection runs on purchaser entities, shared addresses and shared principals so concentration limits are tested rather than assumed. Then the quantity surveyor's export is a report rather than a three day assembly exercise, and the number in your board pack is the number the lender will compute.

Inventory as an event log. Every state transition timestamped with an actor, so the grid at any past date can be reconstructed exactly, which is what a lender audit or a dispute actually asks for. Price changes versioned so a contract always references the schedule in force when it was written.

Assignments as first class transactions with consent workflow, fee calculation, document set and identification checks on the incoming purchaser, rather than as an edit to the purchaser name field. That edit is how assignments usually get handled, and it is why assignment history is so often unreconstructable.

Reconciliation on a schedule, not at quarter end, with an unmatched queue somebody works daily.

Ownership in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire another firm. At Digital Heroes that is the default from the first commit. This system holds the contractual record of multi year obligations to hundreds of purchasers and may be evidence in a dispute years after the building completes, so it should never sit somewhere you cannot reach.