Ask a broker firm owner how commissions get tracked and you will hear one of two answers. The honest one is "a spreadsheet." The optimistic one is "our CRM handles it" — and if you sit with that CRM for ten minutes, you will find the spreadsheet open in the next tab anyway.
This is not because the software is bad. It is because nearly every product that markets itself as commission management software models the wrong half of the problem. It models the split — agent gets X percent, firm keeps Y, sub-broker takes a slice off the top. That calculation is real, but it is the easy half. The hard half is everything that happens to the money after the deal closes: when it arrives, in how many pieces, net of which deductions, owed to whom, and what happens when the deal falls through after you have already promised someone a payout.
This is a field guide to that hard half — written for broker firms in India running agents and sub-brokers, where the gap between "the CRM calculated my commission" and "I know exactly what I am owed and what I owe" is where the money quietly leaks.
What "commission management" usually means
Open the commission feature in almost any real estate CRM — the Indian ones like Sell.Do, Leadrat, or TeleCRM, or the mature Western back-office products like BrokerMint and BrokerSumo — and the shape is the same. You define commission plans: flat splits, sliding scales, caps. You attach a plan to an agent. When a deal closes, the engine multiplies the deal value by the split and produces a payout figure, sometimes with a tidy breakdown.
For a US brokerage, that is most of the job. The seller's commission is contractually fixed, it is paid at closing in one clean transaction through an escrow or title company, and the split is a known percentage. The calculator and the reality match.
In India they diverge almost immediately. The brokerage you earn from a developer is not a fixed percentage of a clean closing — it is a negotiated rate that the developer pays you on their schedule, in tranches, after their own internal approvals, often net of deductions you did not get to decide. The split engine answers a question nobody is actually arguing about. The arguments are about money that has not arrived yet.
Commission is a lifecycle, not a line item
Here is the sequence a single primary-sale brokerage actually moves through:
- Booking. The buyer pays a token. The developer may release a small advance of your brokerage, or none at all.
- Agreement. The sale agreement is executed. A larger slice of brokerage typically becomes due — sometimes paid, sometimes only invoiceable.
- Registration. The sale deed is registered. This is where the bulk of brokerage is usually released, often weeks after you raise the invoice.
- Possession. On some structures a final tail is held back until handover.
Each of those is a separate event, with its own date, its own amount, and its own probability of slipping. A commission calculator that fires once on "deal closed" cannot represent this. The brokerage is not a number; it is a receivable that fills up over months. And the question the owner actually needs answered on a Monday morning — how much brokerage have I earned but not yet collected, and from which developer — is invisible to a tool that only stored the final split.
This is the same reconciliation-shaped problem that shows up across the verticals we work in — the leverage is rarely in the headline calculation, it is in tracking the money as it actually moves. We have written about the broader version of this in our piece on the broker lead pipeline beyond the CRM cliché, and the channel partner portal where the commission ledger is one of five jobs a real portal does.
The four things a real commission ledger tracks
Strip the problem down and a commission ledger that actually holds up has to own four things the split engine does not.
The receivable, per developer. For every closed deal, what is the agreed brokerage, what have I invoiced, and what has the developer actually paid? This is an accounts-receivable view by counterparty, not a per-deal payout figure. Most disputes between a broker firm and a developer are reconciliation disputes — the firm thinks three deals are unpaid, the developer thinks two were paid and one was cancelled — and they are unwinnable without this ledger.
The staged collection. Each brokerage receivable fills against the lifecycle above. The ledger has to record partial receipts, attribute each to the right deal and stage, and show the outstanding balance. Without this, "collected" is a binary the moment it should be a running total.
The split with origination credit. Once money lands, who gets what. This is where sub-brokers and agents make it genuinely hard: the split often depends on who originated the lead versus who closed it, and the firm's cut sits in between. The origination credit has to be captured at the start of the deal, not reconstructed from memory at payout time, or it becomes the thing two agents argue about in your office.
The statutory layer. Commission paid to a sub-broker or agent attracts TDS under Section 194H of the Income Tax Act, which the paying firm is obliged to deduct and deposit — see the Income Tax Department's reference on Section 194H. On the inbound side, your brokerage typically carries GST. A ledger that records only the net amount handed over throws away the deducted figure your accountant needs at filing time, and the GST treatment your CA needs at quarter-end.
A spreadsheet can be coaxed into one or two of these. It cannot hold all four cleanly across thirty agents and a moving book of deals, which is why the spreadsheet always loses to the first determined dispute.
The clawback nobody models
Then there is the case that breaks every clean design: the deal that cancels after you have paid out.
A buyer books, you release the sub-broker's origination slice on the booking advance, and three months later the buyer walks before registration. The developer claws back the advance. Now you are owed money by your own sub-broker, against a deal that no longer exists, recorded in a system that has no concept of a negative payout.
In a spreadsheet this becomes a manual red-ink edit that someone forgets. In a real ledger, a cancellation is a first-class event: it reverses the receivable, reverses the dependent payouts, and opens a recoverable against whoever was paid early. That is not an exotic edge case in Indian primary sales — pre-registration cancellation is common enough that any commission system which cannot represent it is incomplete by design.
Where the packaged CRM ends
None of this means your CRM is wrong. It means it is scoped to the deal, not the money. The CRM should remain the system of record for leads, inventory, the pipeline, and the deal itself. What it does not give you is the receivable lifecycle, the staged collection, the origination-aware split, and the statutory layer — and bolting those onto a CRM's rigid commission module usually fails, because the module was built around the single-payout assumption.
The honest architecture is a thin commission ledger that reads closed deals from the CRM and owns the money layer on top. This is squarely the kind of focused internal tool and admin system that earns its cost quickly, and the staged-collection and TDS handling are exactly the sort of finance-adjacent process automation where a small custom surface beats both the spreadsheet and the generic product.
What we would build
For a typical mid-size firm — say a 30-agent, multi-office broker firm in Pune with a primary-sales book across four or five developers and an active sub-broker network — the build is well bounded.
A commission ledger that ingests closed deals from the existing CRM by a nightly sync or webhook. A receivable view per developer, with each brokerage agreement modelled as a staged schedule and partial receipts logged against stages. An origination credit captured at deal entry, feeding a split engine that computes each agent and sub-broker payout. A statutory layer that applies TDS under 194H, records the gross and the deduction, and tags the GST treatment on inbound brokerage. A cancellation flow that reverses cleanly. And one screen the owner opens on Monday: earned, collected, outstanding, and owed — by developer, by agent, by month.
A focused version of this is INR 7–12 lakh over seven to nine weeks on top of your CRM. Add a sub-broker self-serve statement portal — so a sub-broker can see their own ledger instead of calling your office — and a developer-receivable reconciliation view, and it is INR 13–18 lakh. After launch, this is precisely the kind of system that wants a light ongoing support retainer rather than a hand-off, because the statutory rules and developer payout structures shift, and a stale ledger is worse than none.
The number that matters is not the build cost. It is the brokerage you have earned and not collected because nobody had a clean view of it — and the sub-broker relationships you have kept because the payout was never in doubt.
If you are running commissions out of a spreadsheet that three people edit and nobody fully trusts, that is the conversation worth having. Tell us how your book actually works and we will tell you honestly whether this is a build or a discipline problem — because sometimes it is the latter, and we will say so.