Brokerage back office software: a buyer’s checklist

Brokerage back office software is bought infrequently, kept for years, and evaluated — too often — on the strength of a demo that shows the happy path. The costs of a weak choice arrive later, in commission disputes, examination prep, and the quiet return of the spreadsheets the system was meant to retire. This checklist is the one we would hand a managing broker who asked what to actually look for, whatever platform they end up choosing — ours included.

A note on how to use it: do not score vendors on features claimed. Score them on the specific questions under each heading, asked live, with your own scenarios. The questions are designed so that a weak platform cannot answer them well.

1. The deal record and pipeline

The deal is the atom of a brokerage, and everything else — commissions, deposits, compliance, documents — should attach to it. The pipeline view matters less than the record underneath it.

• Does one deal record carry the parties, dates, property context, conditions, documents, deposits, and commission — or do those live in separate features that reference each other loosely?
• Are stage changes and edits logged with who and when? Ask to see the history of a demo deal after they change it in front of you.
• Can a deal’s history be locked or made tamper-evident once it closes, so the record you rely on later is the record that existed?

2. The commission engine

Commission disputes are rarely about math; they are about which calculation is final. The engine needs a lifecycle, not just a formula.

• Can it model your actual plans — flat, tiered percentage, caps, team splits, referral carve-outs, franchise and transaction fees — from configuration rather than per-deal typing?
• Is there a calculate-approve-lock flow, where the approved figure becomes locked history and later changes are new attributable events?
• Do broker statements and office ledgers read from the same locked source? Ask where a statement’s numbers come from, exactly.

3. Trust and deposit records

Software in this category is generally a workflow layer, not your brokerage’s books of record — a vendor who blurs that line is telling you something. Within its honest scope:

• Does a deposit create a structured record — amount, payor, date, method, deal — at the moment it is recorded, tied to the deal?
• Are releases routed through recorded approvals, so "who authorized this" has a documented answer?
• In BC, does the workflow support the record-keeping posture BCFSA’s rules assume — per-deal visibility, prompt recording, a coherent trail? The rules themselves, and your managing broker, are the authorities.

4. Compliance workflow

FINTRAC obligations are knowable; the operational question is whether evidence accumulates as work happens or gets reconstructed at examination time.

• Are compliance checklists generated per deal type, so the diligence that applies is decided by configuration, not memory?
• Do reviews run through a queue with status, aging, and sign-off timestamps?
• Could you produce, today, the record set for a sample of files — identification, receipt of funds, determinations, review sign-offs — as an export rather than an archaeology project?

5. Platform structure: the un-demo-able layer

The properties that decide how the software ages never appear in demos.

• One permission model across everything, or per-feature sharing logic? Ask how a conveyancer’s access differs from an agent’s, everywhere.
• A real audit trail on records that matter — and can you see it, or only the vendor?
• Can agents see their own deals, figures, and statements in a portal, so the office stops re-answering the same questions?
• Does it grow modularly — adopt the office layer now, transactions when ready — or is it all-or-nothing?
• Exit honesty: can you export your data, completely, in a usable format? Get the answer in writing.

Running the evaluation

Three habits make the checklist bite. Bring five of your real deals — including your ugliest commission plan and a collapsed deal with a deposit in play — and make the vendor drive them through the system live. Ask every "does it" question as a "show me" question. And weight the un-demo-able layer heaviest, because permissions, audit trails, and data exit are the differences you will live with longest and can change least.

We built OpSphere DealFlow to pass this checklist, and we publish honest statuses precisely so buyers can hold us to it — DealFlow is available today, alongside the free OfficeOps core it shares a tenant with. But the checklist is the deliverable here: whichever platform you choose, ask the questions live, on your own deals, and keep the vendor’s answers next to the contract.