A channel partner registers a lead. Somebody walks in. A booking happens. Months later the developer and the partner each open their own file and disagree about who is owed what — and neither file can prove first touch. This is the register that settles it: append-only, timestamped, and readable by both sides from their own point of view.
Try itEverything on this screen was generated by running the system: 148 leads, 27 bookings and every disagreement they produced. Compare Disputed value with Payable this cycle. That gap is the reason the register exists.
Six dispute classes. Each one is decided by the register, not by whoever argues hardest or has the developer's phone number. Switch the role above and the same disputes re-read from the other side — same facts, opposite interest.
Try itClick the top dispute and read its chain from top to bottom. Green is the entry that wins, red is the entry that loses. Then press Channel partner at the top of the page and read the two coloured boxes again: the facts do not move, only the advice does.
Slab against booking value, GST added, TDS deducted, split across the milestones actually reached. Every rate is a visible input, not a number buried in a formula. The partner sees the same computation the developer does.
Try itLook at the payout table, then at one booking taken apart beside it. Any booking still in dispute is excluded from the run, so a contested commission is never paid quietly.
| Partner | Bookings | Value | Slab | Brokerage | Net payable |
|---|
Disputed bookings are excluded from the run, not silently averaged in. A payout that quietly includes a contested booking is how the next dispute starts.
Sold inventory, area booked, collections received and the share held in the designated account are all already in the register — they are the same booking events, counted differently. Evidence accumulates as a byproduct of operating, instead of being reconstructed in a panic the week before filing.
Try itRead the shortfall line. Then press Run conformance suite in the next section to see the rules checked.
Brokerage reconciliation is a fight you have once a quarter. The statutory filing is a deadline you have every quarter, with a penalty attached and a named person accountable for it.
A system that turns the filing from two weeks of spreadsheet archaeology into a review screen does not get switched off — and the data it needs is the data the payout run already produced.
A register that settles money arguments is only worth anything if its rules are checkable. So they are written as executable cases and run in front of you — including the adversarial ones where the obvious implementation quietly favours one party.
First-touch ordering, validity-window arithmetic, slab boundaries, tax computation in integer paise, exclusion of disputed bookings from payout, and symmetry — the register must produce the same facts whichever side reads it.
Re-import the same cycle and nothing moves. That is the first thing a finance team tries, and it is what separates this from a report.
Awaiting run.
Lead and booking exports from the CRM of record, and the partner's own claim sheet. No migration, no replacement, no asking anyone to stop using what they use.
Nothing is edited or deleted. A correction is a new entry with actor, timestamp and reason. Both parties read the identical register — only the framing changes.
A payout run with contested items held back, a dispute queue each item of which names the evidence that decides it, and a quarterly filing already assembled.
Synthetic project, synthetic partners, synthetic bookings. Tax and slab rates are demo inputs shown on screen, not tax advice. No client implied, no live CRM connected in this build.