At Sales Cookie, we often come across highly disciplined individuals (typically in finance or payroll) who manually calculate sales commissions without any error. At the same time, we believe that automation is the only efficient, sustainable, and human-neutral way to calculate sales commissions. But why do we believe that our own commission calculations are in fact accurate? Let’s go behind the scenes and show you!
Commission Calculation Test Suites
Below is one of our automated test suite. As you can see, this test suite includes 764 individual tests organized around a few major categories. Each test simulates a unique scenario. Some of those tests are very narrow. For example, they could verify that scoring formulas work as expected. Other tests are more broad. For example, they could run a full calculation using a sample incentive plan and a synthetic data set.
Commission Calculation Scenarios
Below are just a few of the tests we run each time we make a change to our code base. We have approximately 1000 tests, and all must pass in order for us to update our cloud-based service. Tests come into different flavors such as:
- Positive tests – verify calculations under normal conditions
- Ex: running calculations for a “typical” revenue-based plan
- Edge tests – verify calculations under border-line conditions
- Ex: running calculations when revenue is very large, negative, etc.
- Negative tests – verify calculations when things are incorrect
- Ex: running calculations when revenue is missing or not a number
Commission Calculation Test Structure
All our tests follow the same structure:
- Arrange
- In this step, we generate test data. Typically, we create a workspace with incentive plans, sales transactions, users, teams, etc. We then generate synthetic sales transaction data to simulate a scenario.
- Act
- In this step, we calculate commissions. We ask the engine to calculate sales commissions using our synthetic sales data. And we collect sales commission results – credits and rewards.
- Assert
- In this step, we verify that calculations were correct. We compare obtained results with expected ones. We make the test fails if obtained results don’t match the expected output.
Commission Calculation Test Example
Below is a single test. Here, we verify that calculations are correct when attainment thresholds are expressed as percentages of a fixed quota. Note the Arrange / Act / Assert code blocks. Most of the work is done in the Arrange phase. We programmatically create an incentive plan with one attainment level and a cash reward. We add users and generate sales transactions. Next, in the Act phase, we run a calculation and collect results. Finally, in the Assert phase, we verify that calculation results match the expected output.
Number Accuracy
To ensure calculations are accurate, we use a special data type called decimal. All computer numbers are represented using a set of bits. This can lead to accuracy or rounding problems when calculating sums, averages, etc. To avoid this type of issue, the decimal data type was invented. Here is the wikipedia article about the decimal data type if you want to learn more on this subject. The short version is that using the decimal data type helps use ensure our sales commission calculations remain accurate – to the penny (and beyond). If requires more storage space, but it is well worth it. From Wikipedia:
In Conclusion
We hope this blog helped back our claim that automated sales commission calculations will always be an order of magnitude more accurate than manual ones. We leverage ~1000 tests to verify various permutations, edge cases, and more. All tests must pass in order for us to update our online service. In addition, for most customers, we also run manual tests against their own data set to make sure everything works as expected. Visit us online to learn more about how you can automate your sales commission program!
Sales Commissions Explained 