A RevOps team was using a spreadsheet to handle their commissions, but it became unsustainable. The formulas needed constant patching just to keep up with new reps joining the company, deals that needed splitting, and new accelerator tiers being added. Someone pasted the comp plan into an AI model and had a working calculator by the end of the afternoon. It reconciled against last quarter's payouts, and it seemed like the problem was solved.

Now, finance is being asked to let it handle paychecks. But this is where it gets complicated. Commission expenses are part of a company’s financial statements. Adding that calculator to the payroll process automatically makes it part of internal control over financial reporting (ICFR). So auditors will test it the same way they'd test any other system that touches those numbers, and finance is the one who answers for it if it fails.

So, if you're being asked to approve a homegrown commission tool, ask yourself these five questions first.

Who Can Trace a Payout?

Someone who didn't build the tool needs to be able to trace any payout, step by step, from the source data to the final number on a rep's paycheck. Auditors check evidence directly rather than accept an explanation from whoever built the formula, and the person who wrote the formulas is also the one least likely to catch their own mistake in it.

Every commission payout ends up on the books when the period closes. An auditor then judges that automated calculation on the controls behind it, in other words, who can change the calculation, and who reviews the output. A spreadsheet or an AI-built tool that only one person understands has neither.

What to look for in your homegrown tool: A reviewer who didn't build it can pull up any single payout and see the deal it came from, the formula applied, and the rate used, without asking the builder to walk them through it.

What a production-ready tool can do: Log that trail automatically for every calculation, so tracing a payout back to its source data doesn't depend on anyone's documentation habits or memory.

Who Has Access, and Who Approves Changes?

If the same person can calculate a payout and also change the rule that produced it, there's no separation of controls. Nobody else can catch a genuine error, and nobody would necessarily know if a change was made without one.

Access and approval are usually the first things a controls review checks, and it's also where homegrown tools tend to fall apart. Shared spreadsheets or calculators are easily editable, and whoever owns them can change formulas, run calculations, and approve their own output. A payout can be wrong or altered, with no independent check before it reaches a rep's paycheck.

What to look for in your homegrown tool: The person who can edit the commission formulas isn't the same person who signs off on the numbers those formulas produce.

‍What a production-ready tool can do: Enforce that separation directly, so calculating and approving are built as two distinct steps.

Where Is the Change Log?

You need a record of any change made to a comp plan, a rate, or a rep's data. The record should state who made the change, when, and why.

Say someone lowers a commission rate or raises a quota threshold, and the next payout comes in lower as a result. Without a log, there's no clear way to answer reps or auditors who will inevitably ask why their payout dropped. The SEC's guidance for evaluating financial controls names program changes and access to programs and data as two of the areas that determine whether an automated calculation can be trusted. A spreadsheet's edit history, if it even has one, shows that a cell changed, not who was authorized to change it or why. This isn't enough to answer a rep's dispute or satisfy an auditor asking the same question.

What to look for in your homegrown tool: Every change to plan logic, rates, or data is written down somewhere permanent, with who made it and why, and that record can't be quietly edited or deleted afterward.

What a production-ready tool can do: Generate that record automatically as part of making the change, so the log exists whether or not anyone remembers to write it down.

How Does It Handle ASC 606?

Some commissions can't just be paid out and expensed. If a commission counts as a cost of winning a contract, it has to be recorded as an asset and expensed gradually over the life of the contract, instead of all at once.

If a rep earns a $12,000 commission on a three-year deal, under ASC 606, that $12,000 doesn't get expensed in the month it's paid. It sits on the balance sheet and gets expensed in pieces (about $333 a month) over the three years the customer sticks around. That schedule has to tie back to the specific deal, the specific rep, and the specific contract term, and it has to stay accurate through renewals, upgrades, and early terminations, all of which reset the math.

Homegrown tools aren't often built to track amortization schedules. Get the amortization timing wrong, and commission expense shows up in the wrong period relative to the revenue it's tied to, which misstates margin for that period. If the error is material, it can force a restatement of financial statements already reported to investors, not just a note in an audit.

What to look for: The tool tracks each commission back to its contract term and produces the data finance needs to capitalize and amortize it correctly.

What a production-ready tool can do: Generate and maintain those amortization schedules automatically as contracts renew, upgrade, or end early, so the schedule doesn't need to be rebuilt by hand every time something changes.

What Happens When the Builder Leaves?

If the person who built the tool is the only one who understands it, the company has no way to maintain or explain it once that person leaves or is not around.

For example, the person who built the calculator leaves the company, and three months later, the sales team rolls out a new accelerator tier. The team is now left guessing how to add it to a formula they didn't write or rebuild the calculator from scratch. If a rep disputes a payout from before the handoff, nobody can explain how that number was calculated. The SEC flags staff turnover on a control as a risk factor in its own right, and a tool with one builder is that risk in its purest form.

What to look for in your homegrown tool: The plan logic is written down clearly enough that someone new to it, not just the builder, could read it, understand how a payout was calculated, and make a plan change without breaking the formula.

What a production-ready tool can do: Keep the plan logic in a format the whole team can read and edit through the platform itself, so continuity doesn't depend on one person's documentation habits.

Can a Homegrown Tool Meet These Standards?

In theory, yes. None of the issues raised above requires commercial software. A spreadsheet or an AI-built calculator can have a documented audit trail, split access, and a permanent change log if someone builds and maintains all of that deliberately.

But maintaining all of that is ongoing work, and most teams don't have anyone employed to do just that. Commission software comes with traceability, separated access, a permanent change log, ASC 606 handling, and documentation, built in by default. The table below shows how each approach tackles the five questions. 

FAQ

Is it safe to run sales commissions on an internally built tool?

It can be, at a small enough scale, with the right controls in place. Someone besides the builder should be able to trace a payout, access and approval should be split between two people, changes need to be logged, ASC 606 should be handled correctly, and the tool shouldn’t depend on one person staying at the company. 

Can a homegrown commission system pass a SOX audit?

Only if it can produce evidence: who has access, what changed and when, and how each payout was calculated. A spreadsheet or AI-built tool with no access controls, no change log, and no way to trace a calculation back to its source data won't pass an audit, regardless of how accurate the underlying math is.

What controls does a commission system need for financial reporting?

Five, at minimum: traceability from source data to payout, separation between who calculates and who approves changes, a permanent log of what changed and why, a way to handle ASC 606 capitalization and amortization, and documentation that doesn't depend on one person's memory. A system missing any of these won’t pass an audit.

Should finance ever approve a homegrown commission tool?

Yes, when the scale is small and the five concerns we mentioned in this article are covered. But as the company grows, this often becomes unsustainable. More reps, a second comp plan, an upcoming audit, or the builder changing roles are all reasons to revisit the approval, since the conditions that made the tool safe don't last forever.

Approve the System, Not the Demo

The version of your commission tool that finance is looking at today likely isn't the version it'll have to defend during an audit two years from now. Plans get more complex, reps get added, and whoever built the original calculator eventually moves on. What holds up over that stretch of time is whether someone besides the builder can trace a payout, whether access and changes are split and logged, and whether the numbers hold up against ASC 606. 

Commission platforms like CaptivateIQ are built around this set of controls, so the five questions above are handled by default. Book a demo to see how commissions can be automated and audit-worthy.