Commission management is one of those things that starts simply enough. Someone builds a spreadsheet, it works for a while, and then the business grows. More reps, more product lines, more rules — and suddenly that spreadsheet is a liability. Finance doesn't trust the numbers. Sales doesn't understand why their payout changed. And reconciling it all takes days every month.
Salesforce is a natural home for a commission management system. The customer data is already there, the invoice data can be brought in from the ERP, and the platform has everything you need to build calculation logic, reporting, and audit trails — without buying a separate commission management tool.
This article walks through what it takes to build one from scratch, based on real implementation experience.
Why Spreadsheets Always Break Down
The problem with spreadsheet-based commission tracking isn't that the math is wrong — it's that the process is fragile. Every month someone has to manually export data from the ERP, paste it into the right columns, apply the right rates for each rep or broker, handle exceptions, and then email the results to finance for approval. Each of those steps is a place where something goes wrong.
More fundamentally, spreadsheets have no audit trail. When a broker calls to dispute a payout, you're digging through old files trying to reconstruct what happened two months ago. When a commission rule changes mid-year, you need to manually update every formula. When a new product line launches with different rates, the spreadsheet grows another tab and another set of manual steps.
The system that replaces spreadsheets needs to do three things better: calculate automatically from source data, store a clear record of what was calculated and why, and make disputes easy to investigate without anyone having to reconstruct history by hand.
The Core Data Model
Before writing a line of logic, you need to get the data model right. This is the part most teams rush, and it's where most commission systems run into trouble later.
The Commission Record
At minimum, each commission record should capture: the invoice or transaction it was calculated from, the rate that was applied, the resulting commission amount, the period it belongs to, the payee (rep, broker, or team), and a status field that tracks whether it's been reviewed, approved, or paid. That's your audit trail. Every commission that gets paid out should be traceable to a specific record with a specific calculation.
Commission Rules
Rules live separately from the commission records themselves. A rule might say: "For this broker, on invoices to these customers, apply a 5% rate to the net invoice amount." Rules need effective dates — commission structures change, and you need to know which rule was in effect at the time of the transaction, not which rule is current today. This is often the part that gets missed in early designs and causes reconciliation headaches later.
The Link to ERP Data
The calculation engine needs to read invoice data. If your ERP is integrated with Salesforce, invoice line records are probably already in Salesforce — which means the commission logic can run directly against that data without a separate export step. If the ERP isn't integrated, you'll need a data load process. Either way, the invoice data needs to be in Salesforce before the commission engine can run.
Design tip: Build your commission records so they store both the input (the invoice amount, the rate, the rule that was applied) and the output (the calculated commission). When someone questions a payout, you want to be able to show them exactly what went into the calculation — not just the result.
Building the Calculation Logic
The calculation itself is usually the simplest part of the problem — multiply an amount by a rate. The complexity is in the rules engine: matching each transaction to the right rule, handling exceptions, and dealing with the edge cases that always exist in real-world commission structures.
How Rules Get Applied
A typical rules engine works by looking at each transaction and asking: which rule applies here? The matching criteria might include the customer, the product, the salesperson or broker, the invoice date, and the distribution channel. If multiple rules could apply, you need a priority or tie-breaking logic. If no rule applies, that transaction needs to be flagged for manual review rather than silently producing a zero commission.
Apex vs. Flow
For straightforward commission structures, Salesforce Flow can handle the logic. For anything with more than two or three variables in the matching criteria, or for high transaction volumes, Apex gives you more control and significantly better performance. A record-triggered flow firing on every invoice line is fine at low volumes — it becomes a problem at thousands of records per month.
Handling Exceptions
Every commission structure has exceptions. A customer gets a special rate for Q4. A new rep gets a higher rate during their ramp period. A product line is excluded from a broker's commission. The system needs to handle these without requiring code changes for every exception. Building a flexible rule structure up front — one that can accommodate overrides and exceptions as configuration rather than code — will save a significant amount of time over the life of the system.
Reporting That People Actually Use
A commission system that calculates correctly but produces reports nobody trusts is still a problem. Reporting is where the system earns its credibility with the people who rely on it.
The reports that matter most are usually: a period summary by payee (what does each rep or broker get paid this month), a transaction-level detail report (the underlying invoices that make up that total), a variance report (how does this period compare to the same period last year), and an exceptions report (transactions that didn't match any rule and need manual attention).
Build these as Salesforce reports on top of your commission object from day one. The advantage of keeping commissions in Salesforce is that all the standard reporting infrastructure is already there — you don't need to export data into a separate tool to produce dashboards for management.
Role-Based Access and Approvals
Commission data is sensitive. Reps shouldn't see each other's payouts. Managers should see their team's commissions but not others'. Finance needs full visibility for reconciliation. Senior leadership wants summary dashboards, not transaction detail.
Salesforce's standard permission model handles most of this — object-level permissions, field-level security, sharing rules, and role hierarchy. Set it up thoughtfully at the start and it's easy to maintain. Retrofit it later and you'll spend a week cleaning up what reps have seen that they shouldn't have.
An approval process on the commission records — moving them from "Calculated" to "Reviewed" to "Approved" to "Paid" — gives finance a clear workflow and creates timestamps at each stage that are useful when disputes arise later.
Putting It Into Production
A few things that always come up when moving a commission system from sandbox to production:
- Historical data. Does the system need to process past invoices, or does it start fresh? If you're processing historical data, test your calculation logic against periods where you already know what the right answer is.
- Cutover. The first live period is the highest-risk one. Run the system in parallel with the old spreadsheet for at least one period before decommissioning it.
- User training. The reps and brokers who depend on these numbers need to know how to read their commission records, where to go when something looks wrong, and who to contact for disputes. Don't underestimate this.
- Month-end process. Document the steps someone needs to follow at the end of each period to review exceptions, approve the batch, and mark records as paid. Make it a checklist, not institutional knowledge.
From experience: The first full period after go-live will surface edge cases your testing didn't catch. Budget time for this. It's not a sign something went wrong — it's how every real-world system behaves when it encounters actual data at scale.
Is a Custom Build Right for You?
A custom commission management system in Salesforce makes sense when your commission structure is complex enough that off-the-shelf tools don't fit without significant configuration anyway, when you want the data in Salesforce for reporting alongside your other sales metrics, and when you have the Salesforce admin or development capacity to build and maintain it.
It's not the right answer for every company. Simple flat-rate commissions paid to a handful of reps can be managed with a lightweight Salesforce app or even a well-maintained spreadsheet. The complexity of a custom build is justified when the complexity of the commission structure demands it.
If you're evaluating whether this approach fits your situation, we're happy to talk through it — including a realistic assessment of what it would take to build and maintain for your specific structure.
We've built this. Purivo has implemented commission management systems in Salesforce for mid-market companies with multi-tier broker structures, multi-currency invoicing, and thousands of transactions per month. Let's talk about your situation.