Why ICM Implementations Fail

The Software Is Almost Never the Problem

When an ICM project runs to twice its timeline, or goes live and quietly reverts to the spreadsheet, the post-mortem names the vendor. That diagnosis is usually wrong. Modern commission engines do what they are sold to do: ingest transactions, apply rules, pay, retain a trail. No engine can invent the rules, clean the data or settle a disputed split.

Read a failed implementation as a diagnostic. Spreadsheets tolerate ambiguity: a human resolves it each cycle and never records the resolution. Software does not. Every rule must be stated once, in advance, in a form that runs identically twice. The project does not create the problem, it exposes a compensation programme that was never specified — and that is uncomfortable enough that the software takes the blame.

Five root causes account for most of the damage. None is a product defect, and all are visible before signature.

Crediting Rules That Live in Someone's Head

Crediting decides who is attributed what, at what weight, in which period. Calculation turns credit into money. Vendors compete on calculation, buyers evaluate calculation, demos show calculation. Crediting is where projects die: it is the part the buyer must bring and usually cannot.

The reason is structural. Crediting rules accumulate one deal at a time, over years: a VP asks for an exception, the administrator grants it, and precedent forms that nobody writes down. Ask for a specification and you get rate tables, quotas and plan letters — none of which say who earns what when a specialist and an account owner both worked the deal. Eight dimensions go undocumented almost everywhere.

How it derails the project

Configuration blocks. The team needs a rule, the answer requires judgement, and the person who can give it is in a quarter-end. Discovery stretches and the partner bills for it. Then the parallel run starts, and every variance between system and spreadsheet is adjudicated line by line — not because the engine miscalculated but because the spreadsheet applied an unwritten rule. Nobody can say which result is authoritative, so reconciliation has no finish line.

Your CRM Is Usually the Root Cause

An ICM platform is a downstream consumer. It reads transactions from CRM and ERP, worker records from payroll, quota and territory from wherever those live, then asserts that a named person is owed an exact amount. You cannot automate a calculation over data nobody governs — and comp is the process that forces an organisation to admit its revenue data was reported on, never governed.

The defects are consistent. Opportunity ownership reflects whoever last touched the record, not who was commercially responsible at close. Splits are not fields at all; they live in the administrator's side spreadsheet. Closed-won records stay editable, so amount, close date, product mix and owner change after payment with no record of the prior value. Territory assignment is overwritten on each redraw, making coverage in March unanswerable. And quota, the most common gap, has no system of record.

One mismatch sits underneath all of it. Compensation asks point-in-time questions, repeatedly and retrospectively; operational systems answer what is true now. Effective-dating never appears in the business case and frequently decides whether the project can proceed.

None of this needs a data-warehouse programme. It needs field-level governance on a handful of objects, enforced at entry, plus retained history. That work belongs to whoever owns the CRM, and costs far less before the implementation than during.

Plan Sprawl and the Temptation to Redesign Mid-Build

Ask how many comp plans a company runs and the answer is six, maybe eight. Count the variants and it is routinely thirty to sixty. Region changes the accelerator. Tenure and ramp bands change the quota and the guarantee. Segment changes the measure. A product overlay adds a component. Then come grandfathered arrangements from an acquisition and negotiated deals nobody raises in a workshop.

Variants multiply rather than add. Each is configuration, test cases, documentation, and a row in every reconciliation for the life of the system. An estimate built on eight plans and delivered against forty-five does not overrun by a margin; it overruns by a factor. Establish the true count in week one.

The mid-project redesign

Discovery makes plain how incoherent the plans have become. Someone senior then says the obvious thing — if we are rebuilding anyway, let us fix the plans. Reasonable instinct, reliable way to lose a year. A design project now feeds a build already under way, so configuration starts on drafts and the test cases are written twice.

The default is to freeze design at kickoff, implement the plans you run today even where they are ugly, and redesign next plan year on a system that can model the change first. The exception is narrow: a plan the software cannot express, or one paying what the business has decided to stop paying. Then design first and accept the calendar cost explicitly. Where go-live must hit a plan-year boundary, freezing design is the only version with float in it.

Retroactivity, effective dates and SPIFs

Retroactive change is normal in compensation and almost never in the requirements. Quotas get backdated, a territory redraw lands on a quarter in flight, a rate error in month three changes months one and two — both paid, accrued and reported. The vendor question is not whether the system supports effective-dating but whether it can recalculate a closed period, produce the delta, preserve the original run and leave a trail showing both. Have that executed in a sandbox on your data.

SPIFs and contests need their own count. They are short-lived, invented mid-quarter, calculated by hand and rarely in a requirements document. Ask how many ran last year and who approved them; twenty ad-hoc incentives a year is a governance problem the system inherits. Adjacent modules press from another direction — territory and quota planning, non-sales bonus programmes and channel incentives are legitimate purchases, but none belongs in phase one.

Ownership Gaps and Buying the Wrong Tier

In most organisations one person knows the plans, the exceptions, the crediting precedents and each seller's history. That comp administrator is the single point of failure twice over: they are staffed at perhaps a fifth to the project while still running live payout cycles, so decisions queue behind their calendar; and if they leave, the requirements leave with them. Mitigation is unglamorous — make the written rule set the first deliverable, backfill their operational work, and authorise a second approver.

The second gap is between functions. Finance owns the accrual, the expense line, ASC 606 commission capitalisation and audit defensibility. RevOps owns plan mechanics, crediting, disputes and the seller experience. Neither owns the system by default, and the failure modes are symmetrical: RevOps buys for dispute reduction and Finance finds in month eight that GL export and accrual reporting do not survive close, or Finance buys for control and sellers never adopt. The fix: one accountable executive, Finance in the evaluation from the first demo, and decision rights in writing.

Buying the wrong tier

The last failure mode is a purchasing error. A full SPM suite bought when the pain was payout accuracy leaves five modules licensed and one implemented. A lightweight tracker bought for multi-entity, overlay-heavy crediting runs out of runway by the second quarter. Start from the pain, then pick the tier.

Be careful what you cite as evidence. There is no current Gartner Magic Quadrant for sales performance management: it was retired after roughly 2021 and replaced by a Market Guide that names representative vendors without ranking them, so a vendor citing Magic Quadrant leadership is citing history. The current comparative ranking is the Forrester Wave for SPM Solutions for Incentive Compensation, Q1 2025.

Vulki by Akeron is the SPM line of Akeron S.r.l. of Lucca, Italy, founded by people who previously built Tagetik. It is PE-backed by White Bridge Investments, has raised roughly 30 million euros including 12 million in July 2024, and is a representative vendor in Gartner's Market Guide for SPM, where Akeron has appeared four times. Its claim to a slot is coverage: one system of record for variable pay spanning sales commissions, non-sales MBO scorecards and channel and loyalty incentives, on a calculation-and-simulation engine configured no-code by comp administrators rather than engineers. Where a real share of variable pay sits outside the sales force, that span is a genuine differentiator.

Its agent layer, Akyba, is the other reason to look. Four agents — a compensation admin assistant, a dispute manager, an analyst and a coach — share a knowledge base, can be cloned and specialised, and run bring-your-own-LLM across GPT, Claude and Gemini rather than a vendor-locked model. The admin assistant drafts plan proposals for a human to review, approve and launch, and on our hands-on evaluation it is improving quickly. Treat it as leverage on setup time, not an answer to crediting.

The limitations are equally real. Third-party review coverage is thin — a handful of Capterra reviews, no meaningful G2 presence — so market consensus cannot do your diligence and reference calls matter more than usual. Enterprise scale is unproven relative to Varicent, Xactly and SAP, so stress-test calculation performance at your real payee volume. ASC 606 amortisation handling must be verified in product documentation rather than taken from marketing, and how capitalisation applies to your contracts is entity-specific and belongs with your auditors. Pricing is quote-only, with no free trial. Vulki suits buyers who want breadth and can accept being an earlier North American reference.

Two notes on the field. Restructuring signals around CaptivateIQ come from employee-review sentiment, not formal announcements, and are directional only. Performio's ownership is unconfirmed in our sources, so treat any stated owner sceptically.

The pre-implementation readiness test

Run this before you shortlist, not after you sign. Each item is pass or fail on evidence: a document, a query result or a named person — not a confident answer in a meeting.

1. You can produce a written crediting specification covering splits, overlays, roll-ups, manager credit and house accounts, and two people who did not write it agree with it.
2. You can state the exact number of active plan variants — region, segment, tenure, ramp, grandfathered — and produce a current document for each.
3. You can list every SPIF and contest run in the last twelve months, with who approved and calculated each.
4. You can recompute one historical period from source data alone, with no manual steps, within a defined tolerance of what you paid.
5. You can answer who covered a given account on any past date from a system, not an email thread.
6. Quota exists in one place, with effective dates, an approval trail and agreement with the signed plan letters.
7. Closed-won records are locked, or every post-close edit is logged with actor, timestamp and prior value.
8. Worker records reconcile to payroll as of a date — transfers, terminations, entity, currency — not just today.
9. One named executive is accountable for the system, and the split of decision rights between Finance and RevOps is written down.
10. The comp administrator's workload is backfilled, and a second person can approve crediting rules.

Eight or more of ten and you are buying software. Five to seven and you are buying software plus a remediation project to scope and fund separately. Below five and you are not procuring a system — you are procuring discovery, and you will get it either way: cheaply from your own team now, or expensively from a partner later.

Frequently Asked Questions