Commission calculation is the finance process most likely to generate a heated dispute, because it directly affects take-home pay and the math (base rate, accelerator tiers, clawbacks for churned deals) is genuinely complex enough that manual spreadsheets diverge between reps without anyone noticing until someone compares notes. This workflow calculates every rep's payout with identical logic, flags disputes for review instead of guessing, and never submits to payroll without a human sign-off.
Workflow diagram
flowchart TD
A[Monthly Trigger] --> B[Pull Closed-Won Deals]
A --> C[Pull Commission Plans]
B --> D[Merge]
C --> D
D --> E[Split By Rep]
E --> F[Calculate Base Commission]
F --> G{Quota Exceeded?}
G -->|Yes| H[Apply Accelerator]
G -->|No| I[Merge Rate Paths]
H --> I
I --> J[Check Clawbacks]
J --> K[Apply Deductions]
K --> L[Calculate Final Payout]
L --> M{Disputed?}
M -->|Yes| N[Hold For Review]
M -->|No| O[Generate Statement]
O --> P[Send To Rep]
P --> Q[Manager Approval Gate]
Q --> R{Approved?}
R -->|Yes| S[Submit To Payroll]
R -->|No| T[Return For Correction]
S --> U[Log Payout]
U --> E Every branch shown here (IF/Switch outcomes) exists as a real conditional in the downloadable JSON, not a simplification for this diagram.
Why the same calculation logic for every rep matters more than the formula itself
Most commission disputes are not actually about the commission plan being unfair, they are about two reps discovering their accelerators were calculated differently because two different people built two different spreadsheets. Calculate Base Commission and Apply Accelerator Multiplier run identical logic for every rep in Split In Batches By Rep, so the plan is applied consistently even when a hundred reps are processed in one run.
This consistency is worth more than getting the underlying commission plan perfectly optimised. A slightly generous plan applied consistently generates far less friction than a precisely-tuned plan applied inconsistently.
Clawbacks: the calculation nobody wants to do manually
Check For Clawbacks looks back at deals from prior periods that were refunded or churned within the plan's clawback window, typically 90 to 180 days, and Apply Clawback Deductions reduces the current payout accordingly. This is the single most error-prone manual calculation in commission processing, because it requires cross-referencing the current period against several previous periods simultaneously.
Doing this automatically, consistently, every month, means a rep is never surprised months later by a large deduction for something that should have been caught and communicated immediately when the churn happened.
Disputes get a review path instead of a guess
Deal Attribution Disputed? checks for cases where a rep has flagged that a specific deal should not count toward their number, a common scenario when deals get reassigned mid-cycle or split between an SDR and an AE. Disputed calculations route to Hold For Manual Review rather than the workflow guessing at the correct attribution.
Every non-disputed statement still requires Manager Approval Gate before Submit To Payroll fires. This is not bureaucracy for its own sake, it is the same principle as the board-reporting template's review gate: a payroll submission is exactly the kind of action that should never happen without a human confirming the number first.
Node-by-node reference
| Node | Type | Role |
|---|---|---|
| Split In Batches By Rep | Split In Batches | Ensures identical calculation logic runs per rep, not a bulk approximation |
| Quota Exceeded? / Apply Accelerator Multiplier | IF + Code | Accelerated rate applied consistently above quota |
| Check For Clawbacks | HTTP Request | Looks back across the clawback window for refunded/churned deals |
| Deal Attribution Disputed? | IF | Routes contested calculations to a human instead of guessing |
| Manager Approval Gate | Wait (webhook resume) | No payroll submission without explicit human sign-off |
25 total nodes in the downloadable file, including sticky-note documentation embedded directly on the canvas.
Key logic, in code
Final payout calculation
const baseCommission = $json.baseCommission;
const acceleratorBonus = $json.acceleratorBonus || 0;
const clawbackDeduction = $json.clawbackDeduction || 0;
const finalPayout = baseCommission + acceleratorBonus - clawbackDeduction;
return [{
json: {
...$json,
finalPayout: Number(finalPayout.toFixed(2)),
hasDispute: $json.disputedDealIds?.length > 0,
}
}];Before / after
| Metric | Before | After this workflow |
|---|---|---|
| Calculation consistency across reps | Varies by whoever built the spreadsheet | Identical logic applied to every rep |
| Clawback tracking | Manual cross-reference, often missed | Automatic, every payout cycle |
| Time to generate statements | Days for a sales team of 20+ | Minutes, human review only |
| Payroll submission errors | Caught after the fact, if at all | Gated behind explicit manager approval |
Prerequisites
- n8n v1.40+ with Split In Batches and webhook-resume Wait support
- CRM API access (HubSpot or Salesforce) for closed-won and churn data
- Airtable PAT for commission plans and payout logging
- Payroll API access (Gusto, Rippling, or your provider)
Common pitfalls
Clawback windows must match your actual contract terms
A clawback window that is shorter than your refund policy period will miss legitimate clawbacks; longer than necessary creates disputes over deals that should be settled.
Never skip the manager approval gate to save time at month-end
A payroll submission error is far more expensive to unwind than the few minutes an approval step costs, this is the one place in a commission workflow where speed is not the priority.
Deal reassignment history needs to be preserved, not just current state
If a deal changes owner mid-cycle, the commission calculation needs to know who owned it when, not just who owns it now, or attribution disputes become unresolvable.
Want this deployed, configured and monitored?
The template is free. Wiring in your real credentials, tuning the logic to your business, and keeping it running when an upstream API changes is what we do.
Get my free automation plan →Frequently asked questions
Can this handle split commissions between an SDR and an AE?
Yes, add a split-percentage field to the deal record and adjust Calculate Base Commission to allocate accordingly, the same workflow structure supports any attribution model.
What if a rep's plan changes mid-year?
Version your commission plans in Airtable with an effective date, and have Pull Rep Commission Plans select the plan version active during the period being calculated, not just the current plan.
How are draws or guaranteed minimums handled?
Add a comparison step after Calculate Final Payout that pays the greater of the calculated commission or the guaranteed draw, then tracks any draw balance owed against future periods.