Detect stealth subscription creep with behavioral baselining and scoring

The subscriptions that kill your budget aren't the ones you forgot to cancel. Those are easy — you spot a $99 charge for software nobody uses, you cancel it, done. The dangerous ones are the subscriptions you actively use and need, that slowly change underneath you. A seat price goes from $12 to $14. A tool bumps you from "Pro" to "Pro Plus" after an auto-upgrade. A usage-based tool creeps from $340 a month to $520 over five billing cycles because your team grew.

None of those charges will ever look wrong on a single statement. They look normal because they are normal — just slightly different from last month. And "slightly different from last month" is exactly what manual review is worst at catching.

If you've already got a cancellation routine going (the monthly audit and cancellation playbook covers that side well), this is the next layer: catching the vendors you're keeping that are quietly charging you more. A sharper eyeball won't fix this. A behavioral baseline and a deviation score will.

Why human review misses creep but catches cancellations

Think about how someone actually reviews recurring charges. They open the statement, scan for unfamiliar names, flag the obvious waste, and move on. That process is tuned to catch presence — "should this vendor be here at all?" It's terrible at catching magnitude — "is this the right amount for this vendor?"

A typical example: a 14-person agency pays for a project management tool at around $280/month. One month it's $294. The reviewer sees the familiar vendor name, recognizes it as legitimate, and approves it. They're not wrong that the vendor belongs there. They just never compared $294 to the $280 trend, because holding twelve months of per-vendor history in your head while scanning fifty line items isn't something humans actually do.

Creep tends to hide in three specific patterns:

1. 1
   Per-unit price increases (seat price goes up, quantity stays flat)
2. 2
   Quantity drift (price per seat is unchanged, but seat count crept up and nobody deprovisioned)
3. 3
   Tier/plan changes (vendor moves you to a higher plan, often after a "free trial" of premium features)

Each of these produces a different signature in your data. A baseline that only watches total charge will miss two of the three. So the useful version of subscription anomaly detection tracks the components, not just the final dollar amount.

The core idea: a baseline per recurring charge, not per vendor

The most common mistake when first trying this is building one baseline per vendor. But a single vendor can have several distinct recurring charges — a base platform fee, per-seat charges, usage overages — all landing as separate or bundled lines. Average them together and you blur exactly the signal you're trying to catch.

The unit you baseline is the recurring charge, identified by a stable key. If you've already worked through discovering recurring patterns and mapping them, you have the raw material: matched recurring series with a consistent vendor + descriptor + cadence fingerprint.

For each recurring charge, track:

Use the median, not the mean, for the expected amount. Means get dragged around by a single annual charge or a credit, leaving your baseline wrong for months. Median shrugs those off.

Here's a simple diagram of the baseline-to-queue workflow.

For each recurring charge, the system recomputes the baseline every cycle and compares the new charge to that baseline to produce the deviation components described below.

Deviation scoring that a small team can actually reason about

You don't need a machine-learning model for this. For most SMBs, you probably shouldn't start with one — it's harder to trust and harder to explain when someone asks "why did this get flagged?" A transparent additive score works better in practice because your finance person can look at it and immediately understand why something surfaced.

Here's a scoring approach that holds up well:

1. Amount deviation (0–40 points) Compare the new charge to the baseline median, scaled by the charge's own volatility.

1. 1
   Within normal spread → 0 points
2. 2
   5–10% above baseline → 15 points
3. 3
   10–20% above baseline → 25 points
4. 4
   Over 20% above baseline → 40 points

The reason to scale by the charge's own history: a tool that's always been exactly $500 jumping to $540 is more suspicious than a usage-based tool that normally swings between $400–$600 landing at $540. Same dollar change, very different meaning.

2. Cadence anomaly (0–20 points)

1. 1
   Charge arrived on expected schedule → 0 points
2. 2
   Extra charge inside one cycle (possible double-bill or new line) → 20 points
3. 3
   Cadence shifted but amount normal → 5 points

3. Unit price change (0–25 points) Only applies when you can derive a per-unit price.

1. 1
   Flat → 0
2. 2
   Per-unit up but quantity also up (growth, not creep) → 10 points
3. 3
   Per-unit up with flat quantity (an actual price hike) → 25 points

4. Descriptor / tier change (0–15 points)

1. 1
   Identical descriptor → 0
2. 2
   Materially changed plan text → 15 points

Add them up. A charge scoring 50+ goes into the investigation queue. 25–49 gets logged and watched — not escalated, but if it scores again next cycle it moves up. Under 25 clears automatically.

These thresholds aren't fixed rules. Start conservative (lower the escalation bar to around 40) for the first couple months while you learn what normal noise looks like, then tighten. Early on you'll flag things that turn out to be legitimate — that's expected, and every cleared flag teaches the baseline something.

A worked example

Take a small e-commerce operation running around 20 recurring tools. Their email/SMS platform has billed like this over six cycles:

$410, $418, $405, $422, $430 — then the new charge lands at $511.

1. 1
   Baseline median ≈ $418, with normal swings of roughly ±$15.
2. 2
   New charge is about 22% over baseline → 40 points.
3. 3
   Cadence normal → 0.
4. 4
   Descriptor changed from "Growth" to "Growth — advanced automation" → 15 points.
5. 5
   No per-unit data available → skip that component.

Score: 55. Into the queue it goes.

Investigation takes maybe ten minutes: the vendor auto-enrolled them in a higher tier after they crossed a contact threshold. Not fraud, not exactly a mistake — but a change nobody agreed to, worth around $1,100/year if left alone. Multiply that across two or three vendors doing something similar and you're looking at real money that would've passed through every monthly review without a second glance.

The prioritized investigation queue

A score alone doesn't help if everything lands in one undifferentiated pile. The queue needs ordering and context so whoever works it can clear items quickly.

Order by annualized dollar impact of the deviation, not by raw score. A 40-point flag on a $12/month tool matters far less than a 30-point flag on an $800/month contract. Annualizing the delta — not the whole charge — puts attention where the money actually is.

Each queue item should carry:

1. 1
   The charge, its baseline, and the deviation in both % and annualized dollars
2. 2
   A simple list of the last 6–12 cycles so the reviewer sees the trend at a glance
3. 3
   The specific component(s) that triggered the score (so they're not hunting)
4. 4
   A one-click way to mark it Accepted (updates baseline), Investigate (assign + due date), or Dispute (route to vendor)

“

Prioritize items by annualized delta, not raw score, to surface high-impact small-percentage increases first.

That last part matters more than it sounds. Creep detection programs don't die because the detection is bad — they die because clearing flags becomes tedious, the queue backs up, and people stop looking. If accepting a legitimate change takes three clicks and auto-updates the baseline so it never re-flags, the whole system stays alive.

Remediation playbooks (so flags actually get resolved)

A flag without a predefined next move just sits there. Keep these short and tied to the trigger:

1. 1
   Silent tier change (descriptor + amount up)

   Pull the vendor's plan page and your account settings. Confirm whether you were auto-upgraded. Decide: keep, downgrade, or negotiate. Set a calendar reminder for the renewal date.

2. 2
   Per-unit price hike (unit up, quantity flat)

   Check your contract for price-lock terms. Many annual agreements cap increases — a mid-term hike may be a billing error you can dispute.

3. 3
   Quantity drift (seats crept up)

   Audit active users. Deprovision anyone who left or never fully onboarded. This is the most common one and usually the easiest win.

4. 4
   Extra charge in-cycle (cadence anomaly)

   Verify it's not a double-bill before anything else. If it is, that's a dispute — and duplicate-payment signals you may already track will usually confirm it quickly.

5. 5
   Accepted change

   Document why it's accepted and update the baseline so the system learns the new normal.

The step most teams skip is #5. If you investigate a legitimate increase, clear it, but don't update the baseline, the same charge flags again next month and your reviewer's trust in the entire queue starts to erode.

Where software earns its keep here

The detection math is genuinely simple. The hard part is doing it every cycle, per charge, without forgetting — and that's exactly where AI-assisted expense platforms pull their weight. Tools that maintain recurring-charge baselines automatically can recompute medians, score each new charge against its own history, surface descriptor changes you'd never eyeball manually, and feed a ranked queue. Your team spends time deciding, not detecting.

That's the honest division of labor: automation handles the continuous comparison work; a human decides what each deviation means and what to do about it. Wiring these flags into broader monitoring — the kind of thresholds you'd track on an expense KPI dashboard — turns one-off catches into a standing control rather than a quarterly scramble.

When this is worth building — and when it isn't

It makes sense when:

1. 1
   You run more than roughly 15 recurring vendors
2. 2
   You have usage-based or per-seat tools where amounts legitimately move
3. 3
   Multiple people can trigger upgrades (the classic creep source)

It's overkill when:

1. 1
   You have a handful of fixed-price subscriptions that never change — a quarterly eyeball is fine
2. 2
   Your recurring spend is small relative to total expenses
3. 3
   You don't yet have clean recurring-charge matching; build that foundation first, or your baselines will be meaningless

Very early, very lean operations with under ten flat subscriptions can skip the scoring layer entirely. The monthly cancellation audit alone catches almost everything at that scale. Add baselining when your vendor count and variable charges grow past what one person can reasonably track.

The takeaway

Cancellation playbooks solve the "why are we still paying for this" problem. Behavioral baselining solves the quieter, more expensive one: "why are we paying more for this." The difference is between watching whether a vendor appears on your statement and watching whether its behavior changed.

Build the baseline per recurring charge, score the components separately, rank the queue by annualized dollar impact, and give every flag a defined next move. Do that, and the $14 seat price that used to be $12 — the kind of change no monthly scan ever catches — stops being invisible.