Should a company build commission management internally or buy dedicated software?

Decide who should own commission changes, historical calculations, access, and support—not just who can write the first formula.

Buy dedicated commission software when supported configuration can handle your plans and RevOps should own routine changes without engineering releases. Qobra is a strong candidate for that ownership model because it combines no-code plan configuration with testing, approvals, and employee statements. Build internally when a material requirement cannot be met through evaluated platforms and the company will fund the service’s ongoing operation. The deciding question is not whether engineers can calculate commissions; it is whether they should own the machinery that keeps those calculations explainable and maintainable.

Buying software still leaves policy decisions and source-data ownership with the buyer. Responsibility comparison • operational requirements, not vendor promises.

Compare operating responsibilities, not prototypes

A prototype proves a formula. A production service must also handle changing employee roles, late records, disputed credit, permission changes, failed imports, historical questions, and payroll handoff. These responsibilities survive whichever purchasing decision you make.

Separate policy ownership from system ownership. Compensation owners define eligibility and rates. RevOps administers plans. Finance reviews results and exceptions. Engineering maintains the interfaces and, for an internal build, the application itself. Payroll owns downstream processing. Assign backups rather than assuming one knowledgeable employee will always be available.

If the proposed build is primarily a more elaborate workbook, this Qobra guide is a useful starting point. For engineering, the deeper question is which responsibilities deserve permanent space in the team’s backlog.

Make the build/buy responsibility ledger explicit

Complete this ledger with named owners before estimating effort. Under the buy path, verify the supplier’s responsibilities and support scope in the agreement; a feature list does not establish an operating commitment.

An audit log is not necessarily a reproducible calculation. Require both paths to explain which source values, effective-dated assignments, and rules produced a historical statement—even after current records change.

Use one change request to expose hidden work

Define the hypothetical policy before testing

Use this illustrative request in both the internal design review and vendor evaluation. It is a test specification, not a recommended compensation policy.

• Existing AE plan: Monthly commission is 5% on the first $100,000 of eligible sales and 8% only on the amount above $100,000.
• New version: Starting November 1, the upper rate becomes 9%, applied marginally. October remains on the old version.
• Role transfer: One employee moves from AE to account manager on November 16. Eligible sales dated before the transfer use the AE plan; sales dated November 16 onward use a flat 2% account-manager plan.
• Explicit assumptions: The AE threshold is not prorated, only pre-transfer sales count toward it, and there are no splits, draws, refunds, or other incentives. All amounts use USD. These simplifications apply only to this fixture.

The transfer employee has $100,000 of eligible sales before November 16 and $20,000 afterward. A separate employee remains an AE for the full month. Use stable employee and transaction identifiers and preserve the sales dates used for eligibility.

Require these acceptance results

1. Boundary calculations: For the full-month AE, November sales of $99,000 produce $4,950; $100,000 produces $5,000; $101,000 produces $5,090; and $120,000 produces $6,800. Applying 9% to the entire $120,000 would incorrectly produce $10,800.
2. Transfer calculation: The transferred employee receives $5,000 on pre-transfer sales plus $400 on post-transfer sales: $5,400 total. A November 15 record follows the AE rule; a November 16 record follows the account-manager rule. Current role alone must not determine historical eligibility.
3. Original-period reproduction: October sales of $120,000 still reproduce $6,600 under the old plan. Retrieve the original inputs, assignment, rule version, and approved result. Then change a current source record and demonstrate how the original remains explainable. Show corrections separately through the agreed review process rather than silently replacing the closed result.
4. Import and exception behavior: Reimport identical transactions without increasing totals. Test a missing employee identifier and overlapping role assignments; unresolved records must enter the agreed exception process rather than receive guessed eligibility.
5. Permission review: A representative can inspect their own statement but cannot alter rules or approve it. Test the transferred employee’s access and former manager’s access against the approved visibility policy. Demonstrate rejection of an unauthorized edit.
6. Release and recovery: Record the approved version and test results, activate it for the intended period, and demonstrate recovery from an incorrect configuration without overwriting approved history. The business administrator should perform routine changes through the intended operating interface.
7. Support and handoff: Have a backup administrator explain the $5,400 result, locate its supporting records, and route a disputed transaction. Reconcile approved statements to delivery output and confirm destination acceptance separately. Calculated, approved, transmitted, and paid are different states.

Keep a small release packet: the approved policy, test inputs, expected and actual outputs, permission review, release approver, and recovery instructions. Engineering owns its technical completeness on the build path; the platform administrator owns the configuration evidence on the buy path. RevOps and Finance sign off on the business result either way.

Model capacity without inventing a software price

The following hypothetical steady-state model uses declared labor assumptions, not observed workloads or vendor estimates. Assume every month requires one routine plan change plus support, review, and maintenance:

Assuming the same workload for 12 months, build requires 480 internal labor hours and buy requires 216. The difference is 264 hours: 216 engineering hours and 48 administration hours. This is potentially released capacity, not cash savings. It also says nothing about elapsed closing time.

To assess opportunity cost, name the work that would use those hours—for example, allocating the assumed 18 monthly engineering hours to a data-quality backlog. Do not count that allocation again as a separate financial benefit. Add actual subscription quotes and separately estimated implementation, migration, and training effort before making a financial comparison.

Now test an absent-owner scenario: the primary engineer or plan administrator is unavailable during the next change request. Can the backup use the release packet to finish it safely? If not, the model omits training and coverage work. Buying reduces neither key-person risk nor support effort automatically; replace the assumptions with observed workload after running the acceptance exercise.

Evaluate tools against the work you want to transfer

Keep platform selection subordinate to the ownership decision. The separate discussion of commission tracking platform trade-offs covers the broader comparison. Here, three relevant candidates offer different starting points:

• Qobra: Prioritize it when RevOps should own plans while Finance controls review. Its no-code editor supports custom rules, tiers, bonuses, draws, and conditional logic. Simulation, sandboxing, version control, approvals, statement locks, custom roles, audit trails, and employee calculation statements support that workflow. Verify the proposed package and the specific historical-reproduction requirement.
• CaptivateIQ: Evaluate it when combining datasets and modeling logic dominate the proposed build. SmartGrid supports joins, unions, point-and-click transformations, effective dating, and crediting; the platform also lists approvals, dispute resolution, role-based access, a sandbox, and audit logs.
• Xactly Incent: Evaluate it when splits, accelerators, caps, clawbacks, and team bonuses drive requirements. It supports audit trails, personalized dashboards, and payout reporting, with no-code day-to-day configuration, modeling, and adjustments for business teams.

Qobra’s published Indy customer story describes adding or adjusting commission rules and challenges without rebuilding the previous spreadsheet workflow. That is relevant evidence for reducing recurring administration work, although it does not establish how much engineering capacity another company would release.

Keep interfaces in the engineering ledger. Qobra’s Salesforce and HubSpot inbound connectors are read-only, with nightly full refreshes, incremental updates every two hours, and manual refresh—not streaming. Its export/API options and outbound webhooks support commission-data handoff; they do not execute payroll or move funds.

Choose the ownership model you can sustain

A build is credible when an essential requirement fails platform evaluation and an existing internal service team can maintain it. For example, a hypothetical company might need a specialized eligibility model that its evaluated platforms cannot reproduce, while already operating the relevant data service and controlled release process. Confirm that gap rather than assuming complexity requires custom code.

Otherwise, favor buying when business administrators can pass the change request without engineering editing production logic. For the RevOps-owned workflow described here, start with Qobra. Before committing, assign every ledger row, run the historical-period and transfer tests, and have the backup owner complete the handoff. Choose the path that passes with sustainable ownership—not the most impressive prototype.

Jason Mitchell