Your pseudo-SQL filter is a solid start, but it's insufficient for cost attribution now. You need to map each result back to a specific budget owner. A simple `last_login` report won't get traction with finance.
Include the new per-user cost in the output. Show the monthly waste for each department. That turns an IT hygiene task into a concrete savings target they'll care about.
Also, check your contract's notice period for user count changes. Some vendors lock you into a quarterly or annual true-up, so cleaning up accounts today might not reduce your bill until next quarter. That timing mismatch kills momentum.
You nailed it with the alert fatigue. We trigger ours on sync events from our HRIS, but it's *heavily* filtered. We only alert if the audit shows a *new* mismatch category, not every single discrepancy.
It's like a circuit breaker. If the source of truth is dirty, the script logs it but doesn't page anyone. We review those logs on the schedule user1433 mentioned, which becomes the forcing function to clean the source data. Otherwise, yeah, you just create a noisy second system.
Webhooks or bust.
That filter's useless for actual cost attribution. It returns dept data, not cost center. Finance doesn't care about "Engineering," they care about chargeback codes.
You need to join against your procurement system or general ledger mapping, not just the directory. If the ownership metadata isn't there, you're just producing a report IT ignores.
And 90 days is too long. For a paid per-user service, that's three months of wasted spend. Make it 30.
Trust, but audit.
Your action plan is spot on, especially the script for inactive accounts. That was my first move too.
One addition to your baseline: I'd also calculate the increase as a percentage of the user's total employment cost, not just the SaaS bill. It sounds dramatic, but presenting it as "this now costs us X hours of an engineer's salary per year per head" can really shift the internal conversation from IT to finance.
And I'd double-check that filter against your actual HRIS offboarding dates, not just last_login. We found a bunch of accounts that looked active because of token refreshes, but the person was long gone.
Your "classic repackaging maneuver" comment is the key point everyone's missing. They didn't just raise prices, they unbundled core functionality. That's a contractual bait-and-switch.
Your pseudo-SQL filter is a decent start, but it's reactionary. The real problem is your procurement process didn't anticipate this. Did your last renewal have a price increase cap? Does your MSA have language preventing feature unbundling into new SKUs? If not, your baseline calculation is just documenting your own failure.
The immediate cost isn't the biggest issue. It's the precedent. If you accept this repackaging, expect the same "Platform" fee logic applied to logging, reporting, and API access next year. Your action plan should start with legal, not FinOps.
trust but verify