Commission tracking software for SDR teams
Commission computed from the booking itself, one row per booking enforced by the database, moving through approve and pay — with cancellations resolved by a defined compensation matrix rather than a monthly negotiation.
What this gets you
- One commission row per completed booking, enforced by a unique database constraint
- A duplicate or retried job cannot double-pay — the database rejects it
- Cancellation and no-show outcomes resolved by a stored policy, applied identically every time
- The same billable set drives both the payout and the client invoice
- Historical payouts stay reproducible after a price change
Why commission spreadsheets fail
Not because they are unprofessional, but because they have no constraints. A spreadsheet will let you paste the same booking twice and pay twice. It has no opinion about whether a no-show is commissionable. And when a price changes, the old value is simply gone — so last quarter silently recomputes at the new rate and an invoice you already sent no longer matches the sheet that produced it.
Those are not discipline problems. They are properties of the tool.
How Dialbrew computes it
Products are the unit of pricing. Each client has products, and each product carries a customer price and an SDR commission. One product is the default for that client. Products are archive-only — never deleted — so historical rows always resolve to the product that priced them.
One booking, one commission row. A completed booking generates exactly one commission row, enforced by a UNIQUE (booking_id) constraint. This is the important part: the guarantee lives in the database, not in application logic that could be bypassed and not in a human checking a sheet. If a background job retries, or a queue redelivers the same message, the second insert is rejected.
Rows have a lifecycle. Commission moves through approve → pay, with reversion available. Each transition is a recorded state, so “has this been paid” is a stored fact rather than a recollection.
Cancellations run a matrix. When a booking is cancelled or no-shows, a compensation matrix decides what the rep keeps and what the client is credited. The policy is encoded once. The same situation resolves the same way in March and in November, regardless of who is doing the month end.
Why the invoice cannot drift from the payout
Both derive from the same billable set. The definition of “the client has been billed” is shared: a record in sent or paid counts as invoiced, while one still in creating, ready, failed or invoiced (a draft in Procountor) does not. Because the portal flag and the compensation matrix read that same shared definition, they cannot disagree about whether a given meeting was billed.
The price is then frozen onto the billing record, so changing a product price tomorrow does not retroactively alter an invoice you sent last month.
Employment types and permissions
Reps are not all the same legally. employment_type distinguishes ENTREPRENEUR from EMPLOYEE as a pure HR fact, and it drives which default permission template gets applied when someone accepts an invite. Data scope then keys off permissions rather than role, so a contractor SDR who should only see their own rostered projects is a configuration, not a code change.
What you still own
Dialbrew computes and tracks commission; it does not run payroll. The payout itself happens in your own payroll or invoicing process — what the platform guarantees is that the number handed to that process is correct, singular, and reconciles with what the client was charged.