Commission as Code

You know how Terraform turned servers into code? Commission as code does the same for sales pay. A plan is a JSON file. You change a tier, save the file, ship it. CompCode is the first programmable commission platform built around this idea. Read it, test it, diff it, roll it back. The same loop you already use for every other system in your stack.

What is commission as code?

Commission as code is the practice of expressing sales commission plans as structured, versioned data that lives behind a REST API instead of inside a vendor's proprietary user interface. A plan becomes a JSON config that you can read, diff, review in a pull request, store in Git, deploy via CI/CD, and roll back instantly. Every operation that exists in the dashboard also exists as an API endpoint.

A minimal commission-as-code plan looks like this:

{
  "name": "Q2 2026 AE Plan",
  "version": 1,
  "effectiveStart": "2026-04-01",
  "rules": [{
    "name": "ACV Commission",
    "measure": "closed_won_revenue",
    "attainmentPeriod": "quarterly",
    "tierBy": "attainment",
    "tierMode": "full_rate",
    "tiers": [
      { "tierIndex": 0, "minThreshold": 0,   "rate": 0.10 },
      { "tierIndex": 1, "minThreshold": 1.0, "rate": 0.15 },
      { "tierIndex": 2, "minThreshold": 1.2, "rate": 0.20 }
    ]
  }]
}

That JSON is the entire plan. POST it to /api/plans and the plan is live. PATCH it and a new immutable version is created. There is no separate "click around the UI" step.

Why this matters now

Three trends made commission as code inevitable in 2026. RevOps work moved into AI coding environments where every tool that does not expose a programmatic surface becomes invisible. Plan velocity expectations moved from yearly resets to monthly SPIFs and quarterly restructures. And the cost of getting commission wrong rose as rep distrust became the top reported reason sales people leave companies.

The legacy commission stack was built when plans changed once a year, one comp analyst owned the spreadsheet, and the engineering team had no opinion. That world is gone. The teams now adopting commission as code use Claude Code or Cursor as a primary interface, ship dbt models in PRs, and want comp logic to live next to the rest of their data infrastructure. The vendor UI that worked in 2019 became an organ rejection event in 2026.

What it replaces

Commission as code replaces UI-first commission management. The dominant pattern in the category since the early 2010s was: log into a proprietary application, navigate to Plans, click through a configurator, save, hope the change took effect on the right date, and have no record of who changed what. That pattern survived because the buyers were finance teams and the integration with engineering was nonexistent.

A commission-as-code platform replaces the UI-only model on three axes:

• Audit trail. Every plan change creates an immutable version with timestamp, author, and change message. You can diff version 3 against version 7 the same way you read a Git log.
• Testability. A dry-run simulation runs the new plan against historical deals before any commission events hit the ledger. The numbers are deterministic, not "let's see what payroll says next month."
• Bulk operations. New fiscal year, twenty plans, five entities? It is a script, not a click marathon. The marginal cost of an additional plan drops to near zero.

For a side-by-side feature comparison against the legacy stack, see CompCode vs CaptivateIQ, vs Spiff, vs Xactly, and vs QuotaPath.

What commission as code looks like in practice

In practice it looks like a developer experience. You connect your CRM (Attio or HubSpot today) via OAuth. You write a plan as JSON. You POST it to /api/plans. You assign reps via POST /api/assignments and set quotas via POST /api/quotas. Webhooks from your CRM trigger commission calculation. Results land in an immutable ledger that you query via GET /api/commissions?repId=....

A plan change is a PATCH:

curl -X PATCH https://app.compcode.ai/api/plans/plan_abc123 \
  -H "Authorization: Bearer $COMPCODE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "changeMessage": "Increase accelerator to 18% for Q3 per VP Sales",
    "rules": [{
      "name": "ACV Commission",
      "measure": "closed_won_revenue",
      "tiers": [
        { "tierIndex": 0, "minThreshold": 0,   "rate": 0.10 },
        { "tierIndex": 1, "minThreshold": 1.0, "rate": 0.18 }
      ]
    }]
  }'

That request creates a new plan version. The old version stays in the ledger. The change message is searchable. Three months from now when a rep asks why their commission changed, you GET /api/plans/plan_abc123 and read the version log.

For a deeper tour of the engine, see API-First Commission Management and the canonical Commission as Code Explained post.

Who is adopting it

The first adopters are RevOps practitioners who already work primarily from Claude Code, Cursor, or the terminal. They expect every tool they touch to be addressable from inside their AI coding environment, and they stop using SaaS dashboards the moment a CLI or REST equivalent exists. This is a behavioral segment, not a demographic one. Title is usually RevOps Manager / Director, Sales Ops Engineer, or Head of GTM Systems.

The bowling-alley segments behind them are RevOps Managers at the same companies who do not personally use Claude Code but are influenced by the practitioner who does, plus Sales Ops engineers who script around Salesforce or HubSpot with Apex, Workato, or n8n and would script around commissions the same way if they could.

The segments deliberately not addressed by commission-as-code platforms today are Fortune 500 enterprises that need SOC 2 Type II, SSO, and ASC 606 reporting on day one (Xactly and CaptivateIQ still own this), and SMB teams under 10 reps where a spreadsheet still works.

How to evaluate a commission-as-code platform

There is exactly one platform offering full commission-as-code today, but the evaluation criteria below will hold even as the category fills out. Ask any commission vendor these five questions, in order:

1. Can I create a plan via API? If the answer involves a sales call or "API is read-only," it is not commission as code.
2. Can I modify an existing plan via API? Many vendors offer plan-creation API as a one-off and require the UI for every subsequent edit.
3. Does each plan change create an immutable version? Activity logs are not versions. You need the ability to diff arbitrary historical states.
4. Is there a dry-run simulation that runs against real historical deals? Without it, every plan change is a leap of faith.
5. Does the API surface every operation the dashboard exposes? If reps can only be assigned via the UI but plans via the API, the platform is not API-first; it is UI-first with an API attached.

CompCode answers yes to all five. Every other vendor in the category answers no to at least three.

Where to start

The fastest path through commission as code depends on where you are coming from. Most teams self-select into one of three onboarding paths: the technical practitioner who wants to evaluate the API immediately, the RevOps lead replacing an existing UI-based tool, and the engineering leader making a build-vs-buy decision. Pick the path that matches your context and skip the other two.

• You are a Claude Code / Cursor user evaluating the workflow. Start with the API quickstart and try creating a plan via curl. Free up to 10 reps. No credit card.
• You are a RevOps lead evaluating tools to replace Spiff, CaptivateIQ, QuotaPath, or Xactly. Start with the comparison pages and the migration guide from Spiff.
• You are an engineering leader exploring whether your team should build vs. buy. Read API-First Commission Management for the architecture, then How to Calculate Sales Commissions Automatically for the engine internals.

Pricing is public at /pricing. Free tier covers 10 reps with the full engine.