The Deal Closed. What Are We Owed?

Ask a managing broker what the firm is owed this month and watch what happens. Somebody opens a spreadsheet. Somebody else opens a second spreadsheet, because the first one is only their own deals. And the answer arrives tomorrow, with a caveat. That is not a discipline problem. It is a shape problem. A sales system holds one amount per deal. A brokerage deal has a gross commission, a house share, a broker share, a co-broker on the other side and sometimes a referral, and it is paid in pieces.

So the money lives outside the system, and the system cannot answer the question. Everything on screen is a mock demo of Commercial Brokerage OS with sample data, the solution we design on Zoho with one surface: a custom set of screens for the brokerage, and on every screen a conversation pane that is the AI control plane. You talk to it or you click, on the same screen. Six minutes, one screen that answers the question. Here is the deal record on the brokerage's own screens. Two sides, because a lease has a landlord and a tenant, and both are on the record with their contacts and their broker.

One property. One timeline that runs past the signing, because in brokerage the deal is not over when it closes; that is when the money starts. On the right is the pane. It knows this is the deal page and which deal, so when the broker asks a question, she does not say which deal she means. On the left is the page, and anything the pane does shows up on the page as soon as it is done. Nothing about the commission yet. First the shape has to be right, because every number on the money screen hangs off these two sides.

Now the money screen. The commission is not a number on the deal. It is a set of lines on the deal. The first line is the gross: the rate, the term, the base it applies to, and the gross commission that produces. Below it the split rules run: the house takes its percentage, the listing broker takes hers, the co-broker on the other side takes his under the co-broke agreement, and if a referral is owed, that line is there too. Each line has a payee, an amount, and an expected date, because commissions are paid when the tenant pays, not when the paper is signed.

The broker did not type these. The split rules are set once for the firm, and the plane computed the lines when the terms went on the deal. If she thinks the co-broke percentage is wrong, she can ask in the pane, and it will tell her which agreement it read the number from, or she can change it by hand on the page. Either way the lines recompute and the page refreshes. Here is the decision that makes all of this work, and it is the only thing in this video you actually have to decide.

The commission lives on the deal. Not on the invoice, not in the accounting system, not in the spreadsheet. The invoice is created from the commission lines when a payment falls due, and the accounting system records what was paid against those lines. The deal is the source, and everything else reads from it. Most firms have it backwards. The invoice is raised first, from memory, and the deal record is updated later, if at all. So the deal says one thing, the ledger says another, and the spreadsheet exists to reconcile them.

Put the commission on the deal and the reconciliation disappears, because there is nothing to reconcile. And now the question. The managing broker opens the pipeline page and asks, in the pane, what we are owed this month. The pane knows the page and the date range on it. The plane reads every commission line across every deal whose expected date falls in the month, groups them by payee and by status, and redraws the page: owed to the house, owed to each broker, owed out to co-brokers, and what has already been collected against each.

The report on the screen is the same report she could have built with the page's own controls. She just did not have to. That took the time it takes to read this sentence. Not because the plane is clever, but because the numbers were already on the deals, as lines, with dates. The question was always easy. The data was in the wrong place. Under the skin, the pieces are ordinary. The deal, the contacts and the split rules live in Zoho CRM. The invoices and the payments live in Zoho Books.

The lease documents are signed through Zoho Sign and filed in Zoho WorkDrive. The skin is one set of screens over all of them, designed for how a brokerage works, so nobody has to know which application holds what. The pane is the same control plane on every screen, and it is the same brain that answers in Slack or Cliq on a phone when the broker is at a property. Same gates, same record of who did what. The commission decision is the only part that is specific to brokerage.

The rest is how we design every solution. If your firm answers the owed-this-month question from a spreadsheet, the fix starts with one decision: put the commission on the deal, as lines, and let everything else read it. We design and deliver the brokerage solution on Zoho, starting with a no-risk discovery: you pay only if you go ahead. The link is below, and so is the video on why a brokerage deal has two sides.