Transaction management at brokerage scale

Agents buy transaction software to get their evenings back. Brokerages buy it for a different reason, and confusing the two produces rollouts that fail.

A broker of record carries supervisory responsibility for transactions the broker did not run, did not see, and in many cases first learns about when the file is submitted after closing. That is the actual problem. Everything else is a feature list.

The visibility gap

In a typical brokerage without a shared system, the broker's view of a file is whatever the agent submits, whenever the agent submits it, usually post-closing. Compliance review is therefore archaeology. You are examining a completed transaction to determine whether it went well, at a point when the only available remedy is documentation.

The specific risks that live in that gap:

• Missing required disclosures, discovered after the parties have moved on
• Files that closed with a contingency never formally released, which is fine until it is not
• Advertising and agency-disclosure issues nobody saw in real time
• Agents who developed idiosyncratic practices that work until the file where they do not
• Records held personally by an agent or coordinator who then leaves

That last one is the quiet catastrophe. If the transaction history for a departing agent's files lived in their inbox and their drive, the brokerage's retention obligation is now dependent on the goodwill of a former employee.

Review during, not after

The single most valuable change a brokerage makes is moving file review from post-closing to in-flight. Not because in-flight review is more thorough, but because it is the only version where finding a problem is useful.

That requires the broker's view to be live rather than submitted. Practically it means a view across every agent's active files showing completeness against the correct jurisdiction checklist, what is outstanding, and what is at risk right now.

Post-closing review tells you whether you had a problem. In-flight review is the only kind that lets you not have one.

Jurisdiction is where generic tools quietly fail

A brokerage operating across a metropolitan area is usually operating across jurisdictions, and the requirements genuinely differ. A Maryland file needs the Maryland disclosure and disclaimer set, and lead paint disclosure on pre-1978 homes. Prince George's County requires its county addendum on every residential contract. A DC sale needs a TOPA tenant opportunity check where applicable and a condo right of first refusal check. Fairfax County files run against NVAR paper with a resale package requested within days of ratification.

A generic platform models a transaction and lets you attach whatever documents you like. Completeness then means "complete against a list somebody typed," which is only as good as the person who typed it and silently degrades as staff change.

For a broker carrying supervisory liability, this is the difference between a system that reduces risk and one that produces a tidy record of the risk you already had.

What a brokerage should actually require

• Broker-level visibility across every agent and every office, without asking agents to submit anything
• Jurisdiction-aware checklists maintained by the vendor, not by your staff
• Immutable document history, so a superseded disclosure is retained rather than overwritten and provenance survives a dispute
• Retention that outlives people and vendors, with the brokerage as the owner of record
• Export on demand, in a usable format, without needing the vendor's cooperation or goodwill
• Role-based access that reflects your actual structure, including team leads who should see their team and not the whole firm
• An audit trail on the review itself, so supervisory diligence is evidenced rather than asserted

The export requirement is the one most often waived during purchasing and most regretted later. Ask exactly how you get your data out on the day you decide to leave, and treat a vague answer as the answer.

Rollout is change management, not installation

The instinct is to create accounts, send a login email, and announce the policy. Adoption does not follow, because agents are busy and have a system that works for them.

What works better is front-loading everything the brokerage can do without the agents. Configure the jurisdictions, checklists, roles and templates before anyone logs in. Migrate active files yourself. Have coordinators running fully in the system before agents are asked to change anything, so that on day one the tool already contains real work rather than an empty shell.

Then start with the highest producer rather than the most willing volunteer. A system the top of the firm does not use becomes a second-class record, and a second-class record is worse than none because it creates the appearance of oversight without the substance.

The measure that matters to a broker

Not seat adoption. Not logins. The share of active files that are complete against their correct jurisdiction checklist at any given moment, and the age of the oldest gap.

If that share is high and the oldest gap is days rather than weeks, supervision is real. If it is high only for closed files, you have rebuilt post-closing archaeology inside better software, and you have bought a filing cabinet at a subscription price.