Vendor & Contract Expiry Radar: The $400K Surprise Preventer

A finance director at a 200-person SaaS company told me a story last quarter that still stings. They had 83 vendor contracts tracked in a shared Google Sheet. Six of those contracts auto-renewed before anyone noticed — costing $47,000 in unplanned spend and zero negotiation leverage. One of them was a data enrichment tool that exactly three people used.

This is not unusual. According to Concord's contract management research^[2], poor contract management is estimated to cause roughly 40% of contract value leakage — though the actual figure varies widely by organization size and contract complexity. For a company spending $1M–$3M annually on SaaS and infrastructure vendors, that leakage can translate to hundreds of thousands of dollars in missed savings, unclaimed credits, and unfavorable renewals.

The vendor contract expiry radar is a structured agent pattern that continuously monitors your contract master list, extracts critical dates and clauses, and runs three parallel checks — renewal countdown, SLA drift detection, and supplier concentration risk. It turns a static spreadsheet into a living early-warning system.

Every growing company starts tracking vendor contracts the same way: someone creates a spreadsheet with columns for vendor name, annual cost, renewal date, and owner. It works until it doesn't — and it stops working around contract number 40.

The failure mode is not the format. It is the assumption that humans will reliably check a static document at the right time. Notice periods vary from 30 to 120 days. Auto-renewal clauses can trigger silently with price escalation baked in — contracts that renew automatically at a 20% increase are disturbingly common. And SLA credits have claim windows that expire, meaning the money you were owed for last month's outage evaporates if nobody files a ticket.

The real cost is not the sum of individual missed renewals. It is the negotiation leverage you lose. When you discover a contract renewed three days ago, you have zero leverage for the next 12 months. When you discover it 90 days before renewal, you have time to benchmark pricing, evaluate alternatives, and negotiate from a position of strength.

The radar starts with a contract parser agent that reads your master list — whether that is a spreadsheet, a Notion database, or a folder of PDF contracts. The parser extracts structured fields: vendor name, contract start/end dates, notice period, auto-renewal clause (yes/no/conditional), SLA commitments, service credit terms, and annual contract value.

From there, three checks run in parallel every week:

Renewal Countdown scans for contracts entering the 90-day, 60-day, or 30-day window before expiry. For each, it calculates the notice deadline (expiry date minus notice period) and flags contracts where the notice window is closing.

SLA Drift Detector compares vendor-reported uptime or performance against contractual SLA commitments. When performance dips below the SLA threshold, it calculates the credit owed and queues a claim.

Concentration Risk Scorer aggregates vendor spend by category and function, flags categories where a single vendor accounts for more than 60% of spend, and identifies functions where a vendor departure would create operational disruption.

The hardest part of building a contract expiry radar is not the countdown math — it is the parsing. Vendor contracts are written by lawyers who get paid by the word. Auto-renewal clauses hide 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 prompt needs to handle this ambiguity. You feed it the raw contract text and ask it to extract five specific fields with structured output. Here is the approach that works consistently across messy PDF language:

Most contract trackers alert on the renewal date itself. That is almost always too late. If your contract has a 60-day notice period and you get an alert on the renewal date, you missed your window two months ago.

The countdown engine flips this. It calculates the notice deadline — the last date you can act — and builds the alert timeline from there. A contract renewing on June 1 with a 60-day notice period has a hard deadline of April 2. The 90-day alert fires on January 2, the 60-day alert on February 1, and the 30-day alert on March 3.

At each tier, the alert includes different context. The 90-day alert says "this is coming — start benchmarking alternatives." The 60-day alert says "decision needed this month." The 30-day alert says "notice must be submitted within 30 days or the contract auto-renews."

Here is something most ops teams do not realize: SLA credits are a contractual right, not a favor. When your cloud provider promises 99.95% uptime and delivers 99.8%, you are owed a credit — typically 10-25% of the monthly fee for that service, though exact terms vary by vendor contract. According to outage impact survey data^[4], a significant portion of organizations — roughly half in some surveys — never claim credits after serious outages.

The SLA drift detector runs monthly. It pulls uptime or performance data from your monitoring stack (Datadog, Grafana, CloudWatch — whatever you use), compares it against the SLA thresholds extracted from each contract, and generates a credit claim queue.

For a company spending $500K annually on cloud infrastructure, unclaimed SLA credits can add up meaningfully — some estimates suggest $15K-$30K per year is plausible, depending on vendor uptime performance and contract terms. That is money already owed to you by contractual obligation. The agent does not file the claims automatically — it produces a prioritized list with the vendor name, the SLA miss details, the credit amount owed, and the claim window deadline.

Supplier concentration risk is the danger you cannot see on a line-item budget. It shows up when you look at vendors by function rather than by name. You might have 30 vendors, but if one of them handles your authentication, your email infrastructure, and your logging pipeline, you have a single point of failure that touches three critical systems.

The concentration risk scorer categorizes each vendor by the functions they serve (authentication, payments, monitoring, communication, storage, etc.) and calculates concentration percentages. Any category where a single vendor exceeds 60% of spend or capability triggers a review flag.

It also runs a disruption scenario: if this vendor disappeared tomorrow, which systems break? How long until you could migrate? What is the cost of emergency procurement? These are uncomfortable questions, but answering them before a crisis is vastly cheaper than answering them during one.