{"id":"concept:price-increase-detection","kind":"concept","label":"Price Increase Detection","synonyms":["subscription price-hike detection"],"definition":"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.","summary":"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.","explanation":["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."],"commonMistakes":["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."],"category":"analysis","questions":[{"question":"Why didn't price increase detection catch my subscription that clearly went up?","answer":"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."},{"question":"Is an empty result proof no prices increased?","answer":"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."}],"url":"/glossary/price-increase-detection","relatedTo":[{"id":"concept:anomaly-detection","relationship":"related","weight":0.9,"api":"/api/knowledge/concept%3Aanomaly-detection"},{"id":"concept:duplicate-transaction","relationship":"related","weight":0.9,"api":"/api/knowledge/concept%3Aduplicate-transaction"},{"id":"concept:spending-summary","relationship":"related","weight":0.9,"api":"/api/knowledge/concept%3Aspending-summary"},{"id":"concept:vendor","relationship":"related","weight":0.9,"api":"/api/knowledge/concept%3Avendor"},{"id":"tool:find_anomalies","relationship":"references","weight":0.7,"api":"/api/knowledge/tool%3Afind_anomalies"}],"referencedBy":[{"id":"concept:anomaly-detection","label":"Anomaly Detection","url":"/glossary/anomaly-detection"}],"license":"https://creativecommons.org/licenses/by/4.0/","attribution":"BalanceMCP — https://balancemcp.com"}