Vendor Contract Expiry Radar: Stop Silent Auto-Renewals and Recover SLA Credits

A finance director at a 200-person SaaS company walked me through the damage last quarter. Eighty-three vendor contracts, all tracked in one shared Google Sheet. Six of them auto-renewed before anyone noticed. Forty-seven thousand dollars in unplanned spend. Zero negotiation leverage for the next twelve months. One of those renewals was a data enrichment tool that exactly three people used.

This is the default state. According to Concord's contract management research^[2], poor contract management leaks roughly 40% of contract value — actual figures vary by org size and portfolio complexity. For a company spending $1M to $3M annually on SaaS and infrastructure, that translates to hundreds of thousands of dollars in missed credits, accepted price escalations, and renewals negotiated from zero leverage.

It compounds. The Zylo 2025 SaaS Management Index^[6] puts average SaaS spend at $4,830 per employee — a 21.9% year-over-year increase — with 52.7% of purchased licenses sitting idle. For a 200-person company, that is roughly $500K in active SaaS spend, and likely $260K of it delivering no value. Contract slippage makes this worse: renewal without review means accepting whatever the vendor baked into auto-renewal terms, which in 2025 almost certainly includes a price escalation clause.

The radar is a structured agent pattern that monitors your contract master list continuously, extracts the dates and clauses that actually matter, and runs three parallel checks: renewal countdown, SLA drift detection, and supplier concentration risk. It turns a static document into a control surface.

Every growing company starts the same way. Someone opens a Google Sheet. Columns for vendor name, annual cost, renewal date, owner. It works until contract number forty. Then it stops.

The failure mode is structural, not cosmetic. Notice periods range from 30 to 120 days. Auto-renewal clauses fire silently with price escalation already baked in — industry data from 2024–2025 shows^[7] the average requested price hike at renewal is 11.5%, and 60% of vendors deliberately obscure rising prices by bundling AI features whether you use them or not. SLA credits have claim windows. AWS requires claims within roughly 30 days of the incident. Azure gives you 90 days. GCP manual claim windows vary by service. Miss the window, the money you were owed evaporates. None of these mechanisms care whether your spreadsheet is current.

The real cost is not the line items. It is the negotiation leverage. Discover a contract renewed three days ago and you have zero leverage for twelve months. Discover it ninety days out and you have time to benchmark, evaluate alternatives, and negotiate from a position where the vendor knows you can walk. Same contract, two different worlds, separated by who saw the date first.

The spreadsheet does not fail because it is a spreadsheet. It fails because it requires a human to check the right row on the right date, every week, for every contract, forever — and that behavioral assumption collapses under load.

The radar starts with a parser agent reading your master list — spreadsheet, Notion database, folder of PDF contracts, whatever you already have. It extracts structured fields: vendor name, contract start and end dates, notice period, auto-renewal clause, SLA commitments, service credit terms, annual contract value.

Three checks then run in parallel, every week:

Renewal Countdown scans for contracts entering the 90, 60, or 30-day windows before their notice deadline — not the renewal date itself. For each contract, it computes the notice deadline (expiry date minus notice period) and flags contracts where that window is closing.

SLA Drift Detector compares vendor-reported uptime or performance against the SLA thresholds extracted from each contract. When performance drops below threshold, it computes the credit owed, identifies the provider-specific claim window, and queues the claim with the deadline attached.

Concentration Risk Scorer aggregates spend by category and operational function. It flags categories where one vendor exceeds the risk threshold for spend or capability, and identifies functions where a vendor disappearing tomorrow would take a system with it.

The countdown math is trivial. The parsing is not. Vendor contracts are written by lawyers paid by the word, and auto-renewal clauses live inside paragraphs about "term and termination" with phrasing like "unless either party provides written notice of non-renewal no fewer than sixty (60) days prior to the expiration of the then-current term."

The parser has to handle that ambiguity — extract structured fields, attach a confidence score to each field, and escalate anything below threshold to human review. Below-threshold extractions never enter the alert pipeline unverified. A missed renewal caused by parser hallucination is worse than no automation at all.

Eight fields matter most. Miss any of them and the check that depends on it becomes either useless or dangerous:

Most contract trackers alert on the renewal date itself. That is the wrong date. With a 60-day notice period, an alert on the renewal date is two months late.

The countdown engine inverts this. The trigger date is the notice deadline — the last day you can act — and the alert timeline counts back from there. A contract renewing June 1 with a 60-day notice has a hard deadline of April 2. The 90-day alert fires January 2. The 60-day alert fires February 1. The 30-day alert fires March 3.

The content of each alert is different on purpose. The 90-day alert says: this is coming, start benchmarking alternatives. The 60-day says: decision needed this month, start the negotiation. The 30-day says: notice must go out within thirty days or this contract auto-renews on the vendor's terms.

One detail gets skipped in most implementations: the alert must specify the notice deadline, not just the renewal date. A Slack message that says "Contract renews June 1" tells the owner nothing actionable. A message that says "Notice deadline April 2 — 23 days remaining" is an action item.

Most ops teams treat SLA credits as goodwill. They are not. They are a contractual obligation with a hard claim deadline — and the deadline is the mechanism vendors rely on to avoid paying.

The numbers are specific. AWS requires you to file within approximately 30 days of the incident by opening a case in Support Center with uptime logs and availability data for each 5-minute interval of the outage.^[9] Azure gives you 90 days. GCP claim windows vary by service. Miss any of these windows and the credit is gone — not delayed, gone.

For Google Cloud specifically, analysis of commitment reviews^[4] estimates 60 to 80 percent of eligible credits go unclaimed because the manual filing requirement creates friction that nobody prioritizes. This is by design. The credits exist; the process for claiming them exists; the window closes; the credit expires. The drift detector exists to interrupt that sequence.

The detector runs monthly. It pulls uptime and performance data from your existing monitoring stack — Datadog, Grafana, CloudWatch, whatever — compares it against the SLA thresholds extracted from each contract, and generates a credit claim queue. Each item in the queue includes the vendor name, the SLA miss details, the credit amount owed, the provider-specific claim deadline, and a pre-drafted email with contract clause references.

Filing becomes a five-minute task instead of a research project. The agent does not file claims automatically — that needs human sign-off because of legal and relationship implications — but it eliminates the friction that makes most teams never file at all.

Concentration risk is invisible on a line-item budget. It surfaces only when you map vendors by function rather than by name. Thirty vendors looks like diversification. If one of them runs your authentication, your transactional email, and your logging pipeline, you have one dependency and a wishful spreadsheet.

Procurement risk literature flags a single supplier controlling more than 30% of spend in a category as a concern worth tracking.^[10] But the spend threshold is a proxy, not the actual risk. The actual risk is operational criticality: what breaks and how fast if the vendor disappears tomorrow.

The scorer runs two dimensions separately:

Spend concentration — what percentage of a category's budget flows through one vendor. Anything over 30% gets a flag. Over 60% gets a review action.

Operational criticality — which functions break if the vendor is unavailable for 24 hours, 48 hours, one week. Low-spend, high-criticality vendors are the most dangerous. A $4,200/year log aggregation tool that every service depends on for debugging is more operationally critical than an $800K productivity suite where a week of disruption is annoying but survivable.

The disruption scenario forces the right question: if this vendor disappeared tomorrow, how long until you have an alternative running? Emergency procurement and rushed migration under incident conditions is expensive. Answering that question during normal operations, with time to build contingency plans, costs almost nothing.

One pattern surfaces consistently when teams actually do the mapping: the most dangerous concentration is rarely the highest-spend category. It is almost always a low-visibility infrastructure tool that became load-bearing before anyone noticed.

Scenario 1: The silent uplift. A $180K/year cloud security tool auto-renews with a 12% price increase baked into the clause. The 90-day alert fires four months out. The team runs a benchmark, discovers two comparable tools at 20% lower cost, and uses the competitive quote to negotiate the increase down to 3%. Total save: $16K. Time invested: three conversations over six weeks, none of them urgent.

Scenario 2: The unclaimed credit. A payment processor SLA commits to 99.95% uptime. Actual uptime that month: 99.71%. The drift detector flags the miss and calculates the credit owed under the contract's 10%-of-monthly-fee clause. AWS-style claim requirement: file within 30 days with uptime logs. The team files on day 12. The credit posts the following billing cycle. This would have expired unclaimed — the incident was logged in Datadog but nobody connected it to the SLA clause.

Scenario 3: The invisible dependency. Concentration scoring maps the logging function: three tools, but 94% of log volume runs through one. The tool costs $4,200/year — below any procurement review threshold. The scorer flags it as Critical: high criticality, no backup, no migration plan. The team pre-qualifies an alternative vendor over the following month, adds it as a warm standby. Two months later, the primary vendor raises prices 40%. The team switches in two weeks instead of two months. The rushed migration cost is avoided entirely.

The contracts you have right now contain dates your team does not know, clauses that will fire without warning, and credits that will expire unclaimed. None of that requires sophisticated AI to fix. It requires a weekly scan, three checks, and a brief that lands where decisions are made. The spreadsheet was never the tool for this job.