When is custom sales commission software worth it?

A shared account, a split outside the system

Suppose your standard plan assigns commission to the rep who owns the account. One account is managed jointly. The company has agreed to split commission on its sales between two designated reps for the current period, using an agreed allocation. The software still applies the standard rule, so someone in sales finance recalculates this account in a spreadsheet.

Before commissioning an application, find out why the split remains outside the system. Perhaps nobody has configured the relevant rule yet. Or the data coming from the CRM may lack the shared-account information. Working through this with your administrator or vendor will establish whether you need a new feature.

If the agreed exception became part of the calculation, finance would no longer need to adjust the standard result each time. Each sale would record which reps share the commission and the period covered by that arrangement. A rep could open their statement line and see that it reflects the shared account. The explanation would lead to the sale and the agreement, saving finance from reconstructing it from spreadsheet comments.

The application therefore needs more than a field for typing in an adjusted total. It should apply the agreed split to subsequent transactions covered by the exception and let someone follow how it reached the result. Your company defines the commission rules and approves changes. The software project turns those decisions into working calculations.

If the calculations already work and the problem is explaining discrepancies in a completed statement, our article on sales commission reconciliation covers that decision. Here, the purchase concerns the tool that calculates the commissions.

What happens when the plan changes?

In the next period, the company may end the shared-account arrangement and return to the standard rule. New calculations should use the new agreement. Someone reviewing the earlier period still needs to see the split that applied then, along with the sales data used to calculate it.

That matters when designing a custom system. Storing the result alone is insufficient if someone needs to reconstruct it months later. The calculation needs to retain the version of the rules it used and the underlying data. Today's account assignment in the CRM may differ from the assignment in the period under review.

If an earlier sale later requires a correction, finance should be able to record what changed and why. The original calculation and its correction need to remain connected. Otherwise, the rep sees a changed result without an explanation, and finance returns to searching old spreadsheets. Your company determines how corrections should be handled; the application should support those decisions and preserve their history.

Investigate the features you already have

Standard products include ways to manage plan changes. Salesforce Spiff supports start and end dates for a user's plan assignment. That is a concrete feature to examine when comparing how tools handle successive commission periods (Spiff plan assignment effective dates).

Spiff also documents freezing statements to protect them from changes during recalculation. Freezing does not make the entire history unchangeable (recalculating and freezing Spiff statements). Ask the vendor to walk through a specific plan change and reproduce an earlier calculation.

Configuration is a good option if your current product can record the split, its effective period, and the explanation you need. The work may also include cleaning up CRM data. Compare available modules or another standard product before treating the spreadsheet as proof that you need custom software.

An extension may be enough when the product calculates standard commissions well and one kind of exception keeps recurring. It could store agreed allocations and pass them into the calculation. Establish whether the current product can accept that information and preserve its connection to the sale. An extra screen from which finance still copies totals would leave much of the manual work in place.

A custom application becomes a stronger candidate when several recurring rules require extensive workarounds in the available tools. An initial scope could cover one plan and its shared-account exception. The CRM could continue supplying sales data, while other financial processes remain in existing systems.

The calculations will need maintenance

With custom software, establish who changes a rule when your company agrees on a new plan. The person responsible for commissions needs to explain the rule and confirm results against sales they know. The application provider handles the agreed software changes and maintains data connections. How that working relationship is organized affects the ongoing cost as much as the initial build does.

Moving calculations out of a spreadsheet also requires decisions about history. The current plan needs working rules and open exceptions. Older periods can remain in an accessible archive if it contains what staff need to explain their results. Before switching, reproduce a known period in the proposed system and inspect the split on an individual sale. Matching the overall total could conceal a different allocation between reps.

Also agree on exports of data and rule history, along with code ownership. If another provider eventually takes over maintenance, it will need access to the application and a record of how your agreements were implemented. Include those arrangements when comparing custom software with the terms of your current SaaS product.

Syntalith builds custom applications. A possible project here is calculating one plan with shared accounts and showing reps how the split affects their results. Start the conversation with an exception that returns to the spreadsheet every period. Explain what the software already calculates and what finance has to adjust outside it. That gives us a basis for comparing configuration, an extension, and a custom application. See Syntalith pricing for information about billing.