Channel Partner Brokerage and Payouts in India (2026): Slabs, Timelines, TDS and Dispute-Proofing

Ask any channel partner in Pune, Thane or Gurugram what actually kills their month, and brokerage almost never comes up first. Payout timing does. The 2% was agreed in the empanelment letter; the problem is that the booking closed in April, the agreement registered in June, and the cheque still hasn't landed in September because someone at the developer's end can't reconcile which of three CPs sourced the lead.

This guide is the operational version of the brokerage conversation: how slabs are actually structured in Indian primary residential sales in 2026, what triggers a payout release, the TDS and GST mechanics that quietly stall invoices, and the specific records that decide a source dispute before it becomes an email war. It is written for both sides of the table, because the fix is the same for both: a shared, timestamped record of who touched the lead first.

What "brokerage" actually means in a developer–CP contract

Brokerage in Indian primary sales is a success fee paid by the developer to an empanelled channel partner for a booking that survives to a defined milestone. It is not a commission on a listing, and it is not the buyer's money. Three things define it in the empanelment letter, and all three get argued about later:

• The base. Is the percentage on agreement value, on total consideration including floor rise and PLC, or on "basic sale price" only? The gap between BSP-only and all-inclusive can be 8–12% of the fee on a premium unit with a good view charge.
• The trigger. Booking confirmed, agreement registered, or a collection threshold (commonly 10–20% of consideration received)? This single line decides whether you wait 30 days or 120.
• The clawback. What happens if the buyer cancels at month four, or defaults on the second demand? Most 2026 contracts carry a clawback window tied to cancellation, and a surprising number of CPs sign without reading it.

If those three lines are vague in the empanelment letter, every later dispute is a negotiation rather than a lookup. Nail them at signing, not at invoicing.

How brokerage slabs are structured in 2026

There is no regulated rate. What exists is a fairly stable market convention, plus incentives layered on top of it. Broad ranges seen in Indian primary residential sales:

• Standard residential primary sale: roughly 1–3% of agreement value, with 2% the most common anchor in metro markets.
• Slow-moving or aged inventory: 4–6%, sometimes higher, because the developer is buying velocity on units that have been sitting for four quarters.
• Launch and pre-launch pushes: often 2% base plus a per-unit cash incentive or a slab bonus for the fifth, tenth and twentieth booking in the quarter.
• Commercial and office: typically thinner on percentage, though absolute ticket sizes make it worthwhile. How commercial brokers get paid works differently enough to be worth reading separately.

Slab structures are where most of the real money sits, and where most of the reconciliation pain comes from. A 2% base with a jump to 2.5% retrospectively on all bookings once the CP crosses ten units in a quarter sounds simple until three of those ten cancel in month five. Insist that the contract states whether the slab is computed on gross bookings or net-of-cancellation bookings, and at what date the count is frozen.

One more clause worth arguing over: co-broking splits. When two CPs claim the same buyer, some developers split 50/50 to avoid the fight. That policy is well-intentioned and quietly expensive, because it rewards whoever is loudest rather than whoever actually sourced the lead. A tagging system beats a split policy every time.

The payout timeline: what actually triggers a release

A realistic end-to-end timeline for a residential booking, from the developer's process side:

• Day 0: Booking form signed, booking amount received, unit blocked in inventory.
• Day 15–45: Source verification. The developer's presales or CRM team confirms the lead was first registered by the claiming CP and not already in the database from a portal or a Meta campaign.
• Day 30–90: Agreement executed and registered. Most contracts make this the earliest invoiceable event.
• Day 45–120: Collection milestone met (commonly 10–20% received). Some developers release 50% of brokerage at registration and the balance here.
• Plus 30–60 days: Invoice raised, verified against the sanctioned brokerage note, routed to finance, paid net of TDS.

So a booking closed in April genuinely can pay out in September without anyone behaving badly. The problem is that CPs plan cash flow as if it pays in June. If you run a broking desk, model your working capital on the collection-milestone date, not the booking date, and ask for a written brokerage sanction note at registration so at least the amount is frozen even if the cash isn't.

Developers who want better CP loyalty should look hard at step two. Source verification is where most of the delay hides, and it is almost always a data problem rather than a finance problem. If your CRM can produce a first-touch timestamp in one click, verification takes minutes instead of a fortnight.

TDS, GST and invoicing: the compliance layer that stalls payouts

Three compliance facts you should be able to recite, because getting them wrong is the second-most-common reason an invoice bounces back:

• TDS: Brokerage and commission attract TDS at 2% where the payee has furnished a valid PAN, and 20% where they have not. The rate was cut from 5% to 2% with effect from 1 October 2024. The threshold is ₹20,000 of aggregate commission to one payee in a financial year. What was Section 194H of the Income-tax Act, 1961 is renumbered as Section 393(1) under the new Income-tax Act from FY 2026-27, with the rate and threshold unchanged.
• GST: Brokerage is a supply of service. A registered CP invoices GST at 18% on the brokerage amount. TDS is deducted on the brokerage value, not on the GST component, provided GST is shown separately on the invoice.
• RERA: An agent facilitating a sale in a registered project must hold a valid agent registration in that state, and the registration number belongs on the invoice. Developers increasingly refuse to process a brokerage invoice without a live RERA agent number, and renewals lapsing mid-quarter is a real cause of stuck payments.

Practical version for CPs: keep PAN, GSTIN and state RERA registration current and on file with every developer you are empanelled with, and re-share them the moment a renewal happens. Practical version for developers: store those three fields on the channel partner record itself with expiry dates, and let the system flag a lapse before an invoice arrives rather than after.

None of this is tax advice, and slabs and thresholds change. Confirm current rates with your CA before you build them into a payout sheet.

Where payout disputes actually come from

In practice, almost every brokerage dispute reduces to one of five arguments:

• Source conflict. The buyer's number already existed in the developer's CRM from a portal enquiry six months earlier, so the developer treats it as a direct lead. The CP says they did the site visit and the closing.
• Duplicate registration. Two CPs registered the same buyer within days of each other, and the lead-registration window in the contract is either undefined or was never enforced.
• Base-value drift. The CP calculated on all-inclusive consideration; finance calculated on BSP.
• Cancellation clawback. Brokerage was released, the buyer walked, and now the developer wants it back from the next payout with no written schedule for how.
• Slab dispute. The CP believes they crossed the ten-unit slab; the developer's count excludes two cancelled units.

Four of those five are records problems, not commercial disagreements. That is the encouraging part, because records problems are fixable with process. The same failure mode shows up upstream too, in the way brokers lose leads before they ever become a booking.

Dispute-proofing: the six records to be able to produce on demand

If both sides can produce these six artefacts in under five minutes, brokerage disputes largely stop happening:

• First-touch timestamp. When this phone number first entered the system, from which source, tagged to which CP. Timestamped and immutable.
• Lead registration acknowledgement. A system-generated confirmation to the CP when a lead is accepted, with the validity window stated (30, 60 or 90 days is typical).
• Site visit proof. Geo-tagged or OTP-verified site visit logged against the CP, not a WhatsApp message saying "brought them yesterday".
• Booking record linked to the CP ID. Not the salesperson's memory of who introduced the buyer.
• Brokerage sanction note. Issued at the agreed trigger, stating base value, percentage, slab applied, gross amount and expected release date.
• Payment and clawback ledger. Every release, every deduction, every reversal against a booking, visible to the CP in their own login.

The last one matters more than it looks. Most CP frustration is not about the amount; it is about not being able to see status without calling someone. A partner portal where the CP can log in and see their own bookings, sanctioned brokerage and pending releases removes an entire category of phone calls from both teams' weeks.

What to automate, and in what order

If you are a developer fixing this, sequence it like this:

• Tag at capture, not at booking. Every lead from a CP portal, subdomain, WhatsApp or walk-in must land with a CP ID attached automatically. Manual tagging at booking time is how source disputes are born.
• Enforce the registration window in software. Duplicate check on phone number at the moment of registration, with a clear accept or reject reason sent back to the CP.
• Give CPs a login. Whitelabel portal or subdomain, their leads, their site visits, their bookings, their payout status.
• Automate the sanction note. Trigger it off the inventory and collection milestone rather than off a finance team member remembering.
• Report on payout ageing. Median days from registration to brokerage release, by project and by CP. If you don't measure it, you will not know why your best partners went quiet.

Sell.do handles the first four of these natively: CP-specific capture with automatic tagging, duplicate-check on registration, whitelabel channel-partner portals with CP logins, and payout tracking linked to bookings and collections in the post-sales module, so the brokerage sanction and the collection milestone live in the same record instead of two spreadsheets. Choosing which partners to empanel in the first place is a separate exercise, and worth doing deliberately.

For CPs evaluating which developers to work with, ask one question during channel-partner empanelment: "Can I see my own lead registrations and payout status in a login?" The answer predicts your next twelve months of cash flow more accurately than the percentage on offer does. A 2% payout you can track beats a 3% payout you have to chase.

Related reading

• Channel Partners in Real Estate: Role, Benefits and How the Model Works in India (2026)
• Real Estate Lead Leakage: Where Brokers Lose Deals — and How to Plug Every Gap (2026)
• Real Estate Post-Sales Management in 2026: From Booking to Possession

Fix the record, and the payout fixes itself

Brokerage disputes are almost never about the percentage. They are about a missing first-touch timestamp and a payout status nobody can see without a phone call. Sell.do's channel-partner module gives every CP a whitelabel login with their own leads, site visits, bookings and payout tracking, and gives your finance team one auditable source-to-booking trail. See the whitelabel channel-partner module, or book a walkthrough with your own empanelment structure and we'll map it end to end.