Disclosure: DROZlegal publishes this guide and builds the real estate practice-automation tools described below, including its closing-document generation, review agents, and By-Law 7.1 verification gate. This article is general information about Ontario real estate legal practice, not legal advice, and does not create a solicitor-client relationship; it reflects Ontario law and publicly available research as of August 31, 2026.
The real estate file, stage by stage — what practice management software actually has to cover
An Ontario real estate closing isn't one job; it's six, and they happen in a fixed order. A firm shopping for "real estate practice management software" is really evaluating six separate capabilities bundled under one marketing term, and most demos make one or two of them look effortless, then wave a hand at the rest.
| Stage | What has to happen | What to check in the software |
|---|---|---|
| Intake & verification | Confirm who the client actually is, to a documented, defensible standard | Authentication, not just an ID upload — see the next section |
| Title search | Confirm the seller can convey clear title, or flag what's clouding it | Structured review against the search results, not a generic document reviewer |
| Mortgage review | Confirm the lender's instructions, conditions, and priority | A reviewer scoped specifically to mortgage documents |
| Closing documents | Produce the client letter, lender letter, statement of adjustments, and undertakings schedule | Fixed-layout generation an assistant can audit line by line against source documents |
| Trust accounting | Hold and disburse the deposit and closing funds correctly | By-Law 9 books, reconciliation, and a human authorizing every disbursement |
| Requisitions & undertakings | Clear title objections and satisfy post-closing promises before the file is truly done | Whether the software can actually mark these satisfied — see the honest gap below |
Treat that table as the spine of this guide. The next four sections walk the first five stages and where DROZlegal's real estate stack genuinely stands today, per its own capability inventory. The two sections after that are about the stage that doesn't yet have a route, and where the whole feature actually lives in the app — both worth knowing before you sign anything.
Client verification and intake — where fraud risk concentrates
Real estate is the practice area where identity fraud does the most damage, because the thing being stolen is a title, not just a payment. Reported fraud losses tracked by the Canadian Anti-Fraud Centre rose from $165 million in 2020 to $644 million in 2024, with Ontario recording the highest reported loss volume of any province throughout that period — and title fraud specifically depends on a fraudster successfully impersonating a real owner during exactly the kind of virtual retainer a modern practice runs every day.
The Law Society of Ontario has required, since January 1, 2024, that a lawyer verifying a client only virtually authenticate that client's government-issued ID — confirm it's genuine — rather than simply view it on a screen, or else use one of the Law Society's other approved methods (the credit file method, the dual process method, or a verification agent). Source: Law Society of Ontario By-Law 7.1, as reported by Real Estate Magazine, February 28, 2024.
What DROZlegal actually has here, per its own capability inventory: a By-Law 7.1 client-verification gate (client_verification.py) with a manual verification surface a lawyer can review directly — this piece is live. Layered on top of it is a vendor-agnostic identity-verification system built to avoid locking a firm into one authentication vendor.
That layer is flag-off in production (ENABLE_IDV_VENDOR is absent from prod.tfvars), and the detail underneath the flag matters more than the flag itself. Only a mock adapter functions, and that mock refuses to run in a production environment at all. Treefort and Vaultie are registered as NotConfiguredIDVAdapter placeholders — sockets waiting for a signed vendor contract, not finished integrations waiting to be switched on. There is zero working remote identity verification in production today. Any firm evaluating this stage should ask directly whether "identity verification" means an authenticated, third-party-backed check or a manual review surface waiting on a vendor — today, for DROZlegal, it's the second one.
Title search and mortgage review — where task-specific agents earn their keep
The vaguest pitch in this category is "our AI reviews your file." DROZlegal's real estate stack is built the opposite way: three named, task-specific review agents, each scoped to one document type.
title_search— reviews title search results.mortgage_review— reviews lender instructions and mortgage documents.purchase_review— reviews the agreement of purchase and sale.
None of the three is a generalist claiming to read "the whole file," and none of them act on what they find — per DROZlegal's agent registry, the real-estate trio sits among 17 of the platform's 22 agents marked auto_dispatchable=False: they observe and propose, and a lawyer decides what happens next.
Deadlines on the file run on a separate, deterministic engine — real_estate_transaction_service.py wires the file's dates through Rule 3.01's business-day, holiday-roll-forward computation, so a requisition date or a closing date lands on the calendar without a human doing the math by hand. The date is a calculated fact for a lawyer to confirm, not an action the system takes on its own.
This guide stays at the evaluation level on purpose. For the document-by-document mechanics of exactly how the review agents' findings feed into a generated statement of adjustments, and what a lawyer checks on each of the four closing documents before signing, see our deeper walkthrough of AI closing document generation for Ontario real estate lawyers.
Closing day — documents, trust accounting, and the statement of adjustments
Four documents make up the closing-report package DROZlegal generates today: a client reporting letter, a lender reporting letter, a statement of adjustments, and an undertakings schedule — all produced from a hand-authored, fixed-layout document registry (doc_registry.py) as firm-letterhead DOCX and PDF, rather than free-form AI drafting. A fixed layout is the operative detail for a buyer: it's auditable line by line against the title search, mortgage instructions, and purchase agreement, in a way a paragraph an AI composed on the fly is not.
The statement of adjustments is where document generation and trust accounting meet, and it's worth being precise about the boundary. DROZlegal's trust-accounting layer is separately built and live — By-Law 9 books, three-way reconciliation, client trust ledgers, and a $7,500 aggregate cash-retainer guardrail enforced by default — and it is compute-only: no AI in the platform touches money.
DROZlegal drafts the statement of adjustments; a lawyer reviews the trust math and personally authorizes any disbursement, because trust money movement is one of DROZlegal's six permanent hard ceilings and can never be automated, on a real estate file or anywhere else in the platform. The same is true of the transfer itself: a lawyer, not DROZlegal, logs into Teraview and registers it, because court and land-registry filing is another of those six ceilings.
If your firm's evaluation of "real estate software" is really an evaluation of trust-accounting discipline — which for many firms it should be — see our dedicated guide to LSO By-Law 9 trust accounting in Ontario, and the trust accounting product page for how the reconciliation and reporting layer works day to day. For the identity-verification and fraud framing this section only touched briefly, see Ontario real estate closing software: what it needs to do.
Requisitions and undertakings — the stage where a file can get stuck
This is the honest gap, stated plainly rather than buried in a footnote. Requisitions are the objections a buyer's lawyer raises against title before closing — a lien that needs discharging, a survey that needs updating — and undertakings are the promises each side makes to sort out loose ends after closing, like delivering a discharge or a final tax certificate. A file isn't actually finished until both are cleared, no matter how clean the closing-day paperwork looked.
Per DROZlegal's own capability inventory, this is where the backend's HTTP surface stops short of the backend's logic. api/v1/realestate_transactions.py exposes exactly two routes today — GET and PUT /cases/{case_id}/transaction. Undertakings CRUD, the platform's own 14-item closing checklist, and the function that would confirm requisitions are cleared all exist in real_estate_transaction_service.py, but none of them has a route a lawyer or clerk can actually call.
Nothing in the codebase publishes the event that would signal requisitions are cleared — REAL_ESTATE_REQUISITIONS_CLEARED is defined in the event taxonomy and consumed by the workflow engine, but never emitted by anything — so a real estate matter cannot leave the "requisitions" state. The practical consequence is direct: a firm cannot currently mark an undertaking satisfied or a requisition cleared through DROZlegal itself. That has to happen outside the platform — a phone call, a letter, a note in a paper file — the same way it did before any of this software existed.
And because DROZlegal's own case-closing logic refuses to close a file with an outstanding undertaking, a real estate file with an open undertaking cannot currently be closed through the app's own state machine either, until that route ships. This is a known roadmap gap, not a hidden one, and it's the single most important question to ask before you plan to run a live closing calendar through any version of this software today.
Where real estate actually lives in the software — and why that matters for adoption
The second honest gap is about navigation, not logic, and it's easy to miss in a sales demo built around one polished case file. There is no top-level /realestate route in the application. Real estate is reachable only as a conditional tab that appears inside an already-open case once that matter is set up as a real estate file — it isn't even its own module key for licensing purposes; the license gate that governs it is nested inside the case-management module ("cases": ["/cases", "/realestate"]), not listed as a standalone product line the way litigation or corporate are.
Per DROZlegal's own engineering assessment, the honest summary is that the backend is complete but structurally under-surfaced: a lawyer who doesn't already know to open a case and click a conditional tab will never find it. For a firm evaluating this as "real estate practice management software" in the way it would evaluate a litigation or corporate module — something you can point a new associate to and say "that's where real estate lives" — the honest answer today is that it doesn't have that kind of home yet. It works once you know where to look; it does not yet advertise itself.
A buyer's framework — the questions to ask before you commit
Whatever platform your firm is evaluating — DROZlegal or otherwise — these are the questions that separate a real answer from a feature list, in the order they'll actually come up on a live file:
- Does it authenticate ID, or just collect it? By-Law 7.1's standard since 2024 is authentication — or another Law Society-approved verification method — not a stored photo of a document. Ask what happens when the authentication vendor isn't yet under contract — a mock path and a live vendor integration are not the same feature.
- Who still files the transfer and moves the money? If the answer to either isn't "the lawyer, personally, every time," that deserves a second look. No Ontario platform can legally take trust disbursement or land-registry filing off a lawyer's desk.
- Can the file actually clear requisitions and satisfy undertakings inside the software, or only outside it? A closing-document generator and a file-tracking system solve different problems. Ask which one you're being sold, and whether marking an undertaking "done" is a real button or a future roadmap item.
- Where does real estate live in the app, and is it its own module or a tab inside something else? This affects how discoverable the tool is for anyone on your team who isn't the person who bought it.
- Is document generation a fixed layout or free-form AI drafting? A fixed layout is auditable against source documents line by line; free-form correspondence is harder to spot-check for one wrong figure buried in a paragraph.
- Where is the data processed, and under what retention terms? Client data staying in Canada and AI processing that doesn't train on client data are specific, checkable claims — press any vendor for the actual terms rather than a marketing adjective.
Real estate is one practice area inside a wider platform. For the full roster of DROZlegal's named, task-scoped agents across every practice area, see the AI Agents page. For how the closing stack fits into the rest of the workspace — trust accounting, RAG search, the daily briefing — see the product overview.