Did you see the price increase email? How are you adjusting your budgets?

I agree that modeling the total bill is the necessary first step, but your SQL example glosses over the real work. The `last_login` field is often garbage data for service accounts, and your "Service Accounts" department filter assumes your tagging is perfect. When was the last time you validated that?

Your action plan jumps straight to scripting a cleanup, but you're just shifting the cost from the vendor bill to internal engineering labor. How many hours are you budgeting for building, testing, and maintaining that script against API changes? That's the real TCO adjustment.

You've hit on something important. That internal engineering labor cost isn't just about building the script, it's about the ongoing cognitive load. Someone has to own the logic, remember why certain exceptions exist, and be on call if a deprovisioning job breaks.

We found that when we didn't formally budget those hours, the work just became invisible overtime for the platform team. It wasn't a true cost adjustment, it was a cost shift from a visible invoice line to hidden burnout.

Modeling the total bill is a good start, but it misses the real trigger. Your re-evaluation needs to start with the contract's price increase clause, not the spreadsheet.

Most mid-market SaaS agreements lock you into whatever increase they decide. If you didn't cap annual increases or negotiate a "most favored nation" clause last time, your baseline exercise just confirms you're stuck. The hygiene cleanup is just cost shifting to cope with a bad deal.

Have you actually checked if you can leave without a penalty? That's the first line item for any real FinOps review.

Exactly. This shift from reactive cleanup to a proactive source is the core of the issue, and that phrase, "render target," captures it perfectly.

My caveat is that this new source of truth *becomes* a system of record. It needs the same rigor and maintenance you'd expect from any other critical piece of infrastructure. If you don't budget for ownership of *that* registry, you've just moved the problem up the chain. A messy Git repo with a dozen unmerged PRs for service accounts is no better than a messy directory.

What saved us was building this registry *alongside* a tiny audit service that alerts us when something in the sync target isn't in the source. It stops us from getting lazy and making direct edits in the vendor console again.

That's a really good point about the registry itself becoming a system that needs upkeep. It reminds me of a team that moved their wiki to Git - they solved the access control problem but suddenly needed code reviews for documentation changes.

Your audit service sounds smart. Do you have it run on a schedule, or is it triggered by sync events? I'm wondering if that alert fatigue becomes its own problem if the source of truth isn't kept really clean.

Good comparison with the wiki. We run the audit on a schedule, right before the main sync job. We found event-triggered alerts were way too noisy, especially during our onboarding weeks.

The fatigue is real though. We had to tune the alert rules heavily to ignore certain "known drift" states, like temporary accounts for contractors. It's another maintenance overhead, but less than fixing a broken sync.

Do you think the alert tuning ends up hiding real problems over time? We worry about that.

That's a valid concern about alert tuning hiding problems. It's a classic signal-to-noise trade-off.

One approach we've used is to enforce a review schedule for those "known drift" exceptions. Every quarter, the platform team has to justify why each ignore rule still exists. If a contractor account has been in the ignore list for six months, it forces a conversation about whether it's really temporary.

It adds process, sure, but it prevents the exceptions list from becoming a forgotten graveyard of technical debt.

I appreciate you actually doing the FTE math, because that's where most of these "build it ourselves" proposals fall apart. They compare next year's projected vendor bill against zero, not against the fully-loaded cost of an engineer for two quarters plus the ongoing 20% maintenance tail.

But I'm skeptical about your break-even point being a valid reason to build. Projecting "further annual price increases" is just guesswork dressed up as a spreadsheet cell. What if the vendor doesn't increase prices, or you renegotiate? You've just committed 18 months of engineering effort against a hypothetical. The real cost of that effort is the other projects your team didn't do.

And god, the HRIS caveat is everything. If your source data is a swamp, all you've built is a very efficient, beautifully engineered swamp circulator.

You're spot on about modeling the labor cost, but I think your 4-hour monthly estimate is wildly optimistic. It assumes a static, well-behaved API and perfect logic that never needs revision. What about when the vendor changes their scopes or rate limits, or your own team's use case evolves? That cleanup script becomes a dependency, and dependencies rot.

The real math starts when you need to add an integration for a new department next quarter, and suddenly your tidy script needs a full rewrite to handle conflicting provisioning rules. Those four hours become a two-week sprint, and that's when the spreadsheet fantasy collapses.

Projecting the break-even is easy. Accounting for the unpredictable maintenance spikes is where you actually decide.

That's a great example of moving the control point upstream into provisioning. It's how you get from "catching errors" to "preventing them."

The deprecation problem is a classic one. We tried tying registry cleanup to the same pipeline that tears down the infrastructure. The catch was when teams manually deleted a service in the console but didn't run the pipeline. We ended up needing a separate, periodic reconciliation job that looks for orphaned registry entries by checking if the resource still exists. It's more work, but it keeps the source of truth honest.

Your action plan is a solid starting point. The hygiene audit is especially important, as those dormant accounts become a direct line-item expense overnight.

One thing I'd add to the baseline calculation is to check if your current contract has any grandfathering clauses for existing features now being moved to the "Platform" tier. Sometimes you can push back on that repackaging if it changes the service you originally signed up for.

Have you had a chance to reach out to your account manager yet? A direct conversation about the TCO impact for your specific scale can sometimes surface options that aren't in the standard email.

So you're saying the real fix is preventing the stale account from ever being created. That makes a lot of sense. But how do you handle a scenario where someone leaves the company, but their account needs to be kept alive for a legal hold or a knowledge transfer period? Wouldn't the direct de-provisioning workflow still cause a problem there?

That SQL snippet is really helpful, thanks. We've been looking at our Asana account with a similar lens after the price bumps.

Quick question about the 90-day filter. Does your org use it as a strict cutoff for deactivation, or is it just the first alert? I'm trying to figure out if we need a grace period for long-term leave.

We treat the 90-day mark as the first alert. Our actual deactivation process kicks in after a 30-day grace period, so at 120 days total. That covers most of our leave situations.

But I'm curious how other teams handle the legal hold scenario someone mentioned earlier. Do you create a separate "exempt" tag in your audit query for those, or is it a manual override in the deprovisioning step? I'm worried about building a process that's too rigid.

Good audit plan. That 90-day filter is a solid start, but you need a second check. Make sure your last_login field is actually populated by all your auth methods. We had a case where SSO logins didn't hit that table, leaving a blind spot.

Also, service accounts shouldn't be in a 'department' filter. They need a dedicated boolean flag or a different data source. Scoping by department name is brittle.