Building your own commission system makes sense when you have one sales team, a couple of plan types, and an analyst who is good with formulas. Commercial software looks expensive for what a well-kept workbook can do.

But when the commission plans multiply, the analyst moves to a new role, and an auditor asks for last year's calculation history, you might start second-guessing yourself. Plan changes have to wait on an engineer, and reps might have their own spreadsheets because they can't see how their number was reached.

A homegrown commission system can run a year or two past the point where it stopped being the cheaper option before someone connects the ticket queue, the late close, and the shadow spreadsheets to the workbook itself. It was built for the plans and headcount of the previous years, and can't keep up with the ones you have now.

This article lists the seven signs a homegrown system has hit its limit, explains what a commission plan migration involves, and lays out how to switch to commission software without breaking a payout cycle.

Key Takeaways

• Most homegrown commission systems are a calculation engine with no audit trail and no change process. Both get noticed only when an auditor asks or a plan changes.

• You'll see the signs in how the team works long before anything breaks. The builder left, plan changes wait on engineering, reps keep shadow spreadsheets, and finance can't forecast commission expenses.

• A commission plan migration has three parts: data migration, historical recalculation, and a parallel run.

• Reps keep getting paid correctly through the switch. They're paid from the old system until the new one matches it for a full payout cycle.

• Rebuild when the missing piece is a feature. Replace when it's an audit trail, a second person who can run the system, or plan changes that don't need an engineer.

Why Homegrown Commission Systems Break Down

Homegrown commission systems handle part of what they're supposed to: commission calculation. Where they tend to fall short is in keeping accurate records of how the numbers were calculated and changing commission rules without breaking that record. Once an auditor asks questions or a plan changes mid-year, you'll realize a homegrown system's shortcomings.

Payouts calculated in a homegrown system might be correct for years because the analyst who built the workbook knows every exception and checks every run by hand. But if you ask how a payout was reached, the answer is in formulas edited dozens of times, plus the exceptions the analyst kept in their head. A mid-year plan change requires editing those formulas with no test copy and no approval step.

Ninety-one percent of organizations report high payee trust in their compensation system, while 64% experienced payout errors in the past year. Both can be true at once because a rep only finds out a payout is wrong when it lands in their account. A workbook or homegrown system gives reps a final number but none of the deals or rates behind it.

7 Signs You've Outgrown Your Homegrown Commission System

If two or more of these describe your current quarter, your system has hit its limit.

1. The Person Who Built It Left (or Is the Only One Who Can Touch It)

The workbook has dozens of tabs and only one owner, so rate changes, exception handling, and the monthly run all have to go through that person. When they take two weeks off, payouts wait.

The Bank of England's Prudential Regulation Authority called this a key-person dependency when it fined Metro Bank £5.4 million for regulatory reporting failures. The bank's capital calculations depended on a small number of individuals familiar with spreadsheets. 

A commission workbook carries the same risk. When its one owner gives notice, you have weeks to learn a system that took years to build.

2. Every Plan Change Waits on Engineering Time

On a homegrown system, a plan change is a code change. A new accelerator needs an engineer who understands the crediting logic to put the work in a sprint queue. Only 12% of organizations can implement a plan change in under two weeks, while 39% take one to two months. Until the change ships, reps are selling under one plan, and the system is paying under another. The difference shows up as a dispute on the first payout after the change.

3. Your First Audit Request Landed, and the Calculation History Cannot Be Reconstructed

An auditor asking for the support behind an accrual wants the calculation as it ran at the time. A workbook that has been overwritten doesn't have the version from that quarter and no way to show how the number was reached. 

Commissions capitalized under ASC 606, the revenue recognition standard, have to be spread over the period the contract earns revenue, so the auditor needs a schedule that traces each payout to its contract. A workbook with no version history can't produce one.

The Bank of England's Prudential Regulation Authority also handed Standard Chartered a £46.55 million fine for slow escalation and weak reporting controls after a liquidity spreadsheet showed roughly $10 billion positive in a cell that should have been zero or negative. An accrual whose history can't be rebuilt has no support, which the auditor writes down as a control deficiency.

4. Reps Run Shadow Spreadsheets Because They Do Not Trust the Numbers

Reps keep their own trackers when they can't see which deals were credited, at what rate, under which rule. A workbook gives them a final number and none of the inputs, so the first week of the month goes to reconciling their spreadsheet against yours. 

Every hour of reconciliation comes out of selling time, and every dispute that reaches you costs more than the hour, because resolving it without losing the rep takes an investigator who didn't run the original calculation, a documented review, and a timeline the rep can hold you to. A workbook has none of that built in, so the analyst who ran the calculation ends up defending it.

5. Month-End Close Slips Because Calculations Need Manual Review

Commission accruals are the last number finance closes each month, and on a homegrown system, they close last because the analyst checks every exception by hand. The exception list grows with every new hire, split deal, and mid-quarter territory change. 

Finance works around it by booking the accrual on an estimate and correcting it the following month once real payouts are known, which is the red flag. The commission expense in the management report is always a month behind what reps were paid, and if the estimate is off, the correction lands as a surprise in next month's numbers.

6. New Plan Constructs Get Promised to the Field Before Anyone Checks the System Can Model Them

Leadership announces a new plan construct, say a multi-currency accelerator with split credit for overlay reps, before checking whether the workbook can model a split. It can't, so the analyst builds a side calculation in a new tab. The problem is that every construct the workbook can't model becomes another undocumented calculation, and each one is a place a payout can go wrong that only its builder can check.

7. Finance Cannot Forecast Commission Expense From the System's Outputs

Forecasting commission expense means running deals that haven't closed through the same rules as deals that have. A workbook calculates what was paid on closed deals and nothing else, so finance can't say what commissions will cost next quarter if bookings come in over or under plan.

Variable compensation is one of the largest lines in the sales budget, so without a commission forecast, the budget's biggest variable is a guess. Modeling what happens to expense if attainment shifts, accelerators kick in early, or a territory is recarved is a separate build the original never included.

What Switching Off a Homegrown System Involves

A commission plan migration has three parts: data migration, historical recalculation, and a parallel run. The first two take most of the time. The parallel run keeps reps paid on schedule while the switch happens.

Data Migration

Crediting rules, roster history, and transaction data all have to move to the new system. The rules say who gets paid on which deal and at what share, and the roster says who was on which plan, in which role, on which dates. Transaction data is the closed deals and adjustments the rules run against.

The rules and the roster are the hard part because in a homegrown system, most of the exceptions were never written down. A migration is the first time those exceptions get documented. Sit down with the analyst and the managers who approved each exception, and write each one as a rule the new system can apply: who it covers, what it changes, and when it expires. Budget more time for that than for moving the data.

Historical Recalculation

The new system has to reproduce last year's payouts from last year's data, to the cent, before it runs a live cycle. A difference of any size means a rule or an exception didn't migrate correctly. Caught here, it's a fix in a test file. Caught once reps are being paid from the new system, it's a wrong paycheck and a dispute. Load the closed periods, run the migrated rules, and compare the output to what was paid.

Where the two disagree, one of the systems was wrong. Trace every difference to its cause: a crediting rule that didn't migrate, an exception that was never documented, or a formula error in the old workbook that has been paying people wrong.

How far back to go depends on the plans. Teams carrying ASC 606 capitalization schedules need a full fiscal year so the amortization schedules reconcile. Teams on simple monthly plans can stop after a few closed months, which is enough to prove the rules reproduce what was paid.

The Parallel Run

Once the data is migrated and history reconciles, run the old and new systems side by side on a live payout cycle, a month for monthly plans or a quarter for quarterly ones. The team reconciles every difference between them, and reps are paid from the old system until the reconciliation is clean. 

One parallel cycle is enough for simple monthly plans. Plans with quarterly accelerators need two, because the first cycle won't exercise the accelerator logic.

How to Switch Without Breaking a Payout Cycle

Run the five steps below in this order. Each one checks the work of the one before it, so an error shows up before it reaches a live payout.

1. Freeze plan logic for the cutover window: No rate changes, new plan constructs, and roster exceptions from the day migration starts until cutover. Any change made mid-migration has to be made in both systems.
2. Migrate and validate the data: Before any calculation runs, both systems should show the same number of payees, transactions, and bookings total.
3. Recalculate history: Reconcile the closed periods against what was paid and document every difference, with its cause. That record is what you hand the auditor who asks why the numbers changed.
4. Run both systems in parallel: Calculate one or two live payout cycles in both systems. Pay reps from the old one and explain every difference between the two before each cycle closes.
5. Cut over after reconciliation: The new system becomes the payout of record on the first day of a new period, never mid-period. Keep the old system read-only until the periods it paid have been through an audit, then archive its files under your payroll records retention policy.

CaptivateIQ Incentives handles the modeling side of steps two through four. Plans are built in SmartGrid, a calculation engine with spreadsheet-style logic, so a compensation team already working with formulas can read and change plans without an engineer. Plans can be versioned, tested against historical data, and validated before deployment, and every payout is traceable from source data through the calculation logic, satisfying the auditors. 

Gong's compensation team, which runs plans for more than 200 sellers, tested CaptivateIQ's calculations against its previous model before trusting the new tool. Monthly commission runs went from five hours to five minutes, and payout accuracy is above 98%. 

Fin's compensation team moved from Excel to a fully automated commission process in 55 days and cut rep inquiries about commissions by 30%.

If you're comparing vendors before committing, look at the incentive compensation management software list that covers nine platforms and includes how to weigh implementation timeline and integration with your existing stack.

To see how your own plans, exceptions included, would model in SmartGrid, request a demo.

Frequently Asked Questions

How long does a commission plan migration take?

G2 reviewers put CaptivateIQ's average time to go live at three months. Published customer implementations run from 55 days at Fin to four months at Planview, with Ramp reaching live plans in two to three months. Across the category, G2's averages span one month to eight. Plan count, undocumented exceptions, and the number of source systems drive the range.

Can you migrate historical commission data?

Yes. Closed transactions, roster history, and crediting rules can all move over. Loading the data is the smaller job. The larger one is recalculating those periods in the new system and reconciling the output against what was paid, which is the only proof the migrated rules are right. Plan on a full fiscal year of history if you carry ASC 606 capitalization schedules.

What is a parallel run in a commission migration?

A parallel run is a period, usually one or two payout cycles, in which the old and new commission systems both calculate the same live deals. Reps are paid from the old system. The team reconciles every difference between the two outputs and documents its cause. Cutover happens only after a full cycle reconciles with no unexplained differences.

Should you rebuild or replace a homegrown commission system?

Rebuild when what's missing is a feature your analyst can add in a sprint, such as a new rate tier or an extra report. Replace when what's missing is an audit trail, a second person who can run the system, or plan changes that don't need an engineer.