Price Increase Detection
Price increase detection flags a recurring charge whose amount went up compared to its own history, but only when every earlier charge in that history matched exactly in both amount and description.
In short
Deliberately conservative, on purpose. A subscription billed as "NETFLIX.COM" one month and "NETFLIX*STREAMING" the next won't be recognized as the same recurring charge at all — nor will one that varied by even a cent before the increase. An empty result means nothing matched the strict pattern, not that no price increased.
Also called: subscription price-hike detection
Price increase detection looks for one specific pattern: a recurring charge, from the same vendor, whose amount rose compared to every prior instance of that same charge. It's part of the broader anomaly-detection scan, but it's the one most worth understanding on its own, because its design trades recall for precision in a way that shapes how a clean result should be read.
The check only fires when every earlier charge in the sequence matched exactly — the same amount and the same description, not approximately. This is deliberately strict: it fails closed rather than risk a false alarm, which means it will genuinely miss real price increases whenever the underlying data isn't perfectly consistent.
Concretely, a subscription billed as "NETFLIX.COM" one month and "NETFLIX*STREAMING" the next won't be recognized as the same recurring charge at all, since the descriptions don't match. A charge that varied by even a single cent between instances before the actual increase also won't register as a clean enough pattern to compare against. Both are common, ordinary things that happen with real billing data.
The practical consequence is worth internalizing plainly: an empty result from this specific check is not the same as "no price increases happened." It means nothing matched the narrow, exact-match pattern this detector is built to catch — a real increase can be sitting there entirely undetected simply because the vendor changed how a charge was described.
What people get wrong
- Treating an empty price-increase result as proof nothing went up — it means nothing matched the strict exact-match pattern, which real billing data often doesn't satisfy.
- Expecting the check to recognize a subscription across a changed description — even a minor formatting difference breaks the exact-match requirement.
- Assuming the check tolerates small variation in amount before an increase — even a one-cent difference in prior charges breaks the pattern it looks for.
Common questions
- Why didn't price increase detection catch my subscription that clearly went up?
- Likely because the description changed slightly between charges, or an earlier charge in the sequence varied by even a cent — the check requires an exact match beforehand to be confident it's the same recurring charge.
- Is an empty result proof no prices increased?
- No — it only means nothing matched this check's deliberately strict, exact-match pattern. A real increase can go undetected if the underlying charges weren't perfectly consistent beforehand.
Machine-readable: /api/knowledge/concept:price-increase-detection