Your Contract Spreadsheet Is the Reason Renewals Cost You

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 hemorrhaging through missed credits, accepted price escalations, and renewals negotiated from zero leverage.

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 — 20% annual increases are common and almost never challenged because nobody saw them coming. SLA credits have claim windows. Miss the window, the money you were owed evaporates. None of these mechanisms care whether your spreadsheet is up to date.

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 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 expiry. For each contract it computes the notice deadline — expiry date minus notice period — and flags contracts where the window is closing.

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

Concentration Risk Scorer aggregates spend by category and function. It flags categories where one vendor exceeds 60% of 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 prompt has to handle this ambiguity directly — extract structured fields, attach a confidence score, 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:

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.

Most ops teams treat SLA credits as goodwill. They are not. They are a contractual obligation. When a cloud provider commits to 99.95% uptime and ships 99.8%, you are owed a credit — typically 10 to 25% of the monthly fee for that service, exact terms vary by contract. According to outage impact survey data^[4], roughly half of organizations never file after serious outages. The money was already on the table. Nobody picked it up.

The drift 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.

For a $500K cloud spend, unclaimed credits in the $15K to $30K range per year are plausible depending on vendor uptime and contract terms. That is not theoretical money. It is money already owed by contractual obligation, sitting unclaimed because nobody owns the claim process. The agent does not file claims automatically — that needs human sign-off — but it produces a prioritized queue with the vendor name, the SLA miss details, the credit amount owed, and the claim-window deadline. Filing becomes a five-minute task instead of a research project.

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.

The scorer categorizes each vendor by the functions they serve — authentication, payments, monitoring, communication, storage — and computes concentration percentages. Any category where one vendor exceeds 60% of spend or capability gets a review flag.

It also runs the disruption scenario explicitly: if this vendor disappears tomorrow, what breaks, how long until you migrate, what does emergency procurement cost. Uncomfortable questions. Cheaper to answer them now than in the middle of an incident.

One pattern that surfaces consistently when you actually do the mapping: the most dangerous concentration is rarely the highest-spend category. At a 120-person engineering org we mapped, the critical single point of failure was a $4,200/year log aggregation tool — not the $800K cloud contract everyone watched obsessively. Criticality does not scale with price. It scales with what breaks when the vendor is gone.