Clause Forensics #1 A weekly teardown of one contract clause, how it breaks, and what it costs. Sponsored by AllCaps.ai
This is a composite scenario built from patterns across real enterprise software contracts. Every clause and finding reflects what we see repeatedly in practice.
The Contract
A mid-market enterprise running a business-critical cloud platform under a standard master services agreement. $1.2M annual contract value, $100,000 monthly subscription fee. First signed five years ago, renewed twice.
The Clause
Section 7.2, Service Availability Credits:
"Provider shall maintain System Availability of no less than 99.5% during each calendar month... Customer shall be eligible for a service credit, provided that Customer submits a credit request in writing to Provider's designated service management contact within twenty (20) business days following the end of the month in which the failure occurred. Credit requests must include: (i) dates and times of claimed unavailability; (ii) description of the impact to Customer's operations; and (iii) applicable log files or screenshots evidencing the outage."
Credits range from 2% to 15% of the monthly fee depending on severity, capped at 15%.
What It Entitles
If the vendor's system drops below 99.5% availability in any month, the customer can claim a credit of 2% to 15% of that month's fee. But only if they submit a formal written request with technical evidence within 20 business days.
How This Clause Decayed
In Year 1, the original agreement was self-executing. The vendor calculated downtime from their own monitoring and applied credits automatically to the next invoice. The availability target was 99.5%, the notice window was a reasonable 60 days, and the credit cap was 30% of the monthly fee. No log files required. No written requests. The clause worked as intended.
At the Year 3 renewal, the vendor introduced a revised SLA exhibit. The automatic credit was replaced with a manual claim process. The notice window compressed from 60 days to 20 business days. The cap dropped from 30% to 15%. And a new requirement appeared: the customer must now submit log files, screenshots, and an operational impact description. What had been a vendor obligation became a customer burden, buried in an exhibit that procurement signed without comparing to the original language.
By Year 5, the measurement methodology was removed from the contract entirely. In its place: a reference to provider.com/sla-methodology, which the vendor reserves the right to update at any time without notice. New exclusions appeared for transaction volume limits (defined in Exhibit B, a separate document), platform migrations, and new module provisioning. The vendor now initiates at least one "platform migration" annually, creating a rolling 90-day blackout window during which no credits can be claimed at all.
Today, the agreement exists as a stack of scanned PDF amendments and cover pages. The designated service management contact listed in the original Statement of Work left the vendor organization two years ago. The SLA methodology URL has been updated three times since the contract was signed. Nobody on the customer side has a single document that reflects the current state of what's owed.
The Failure Mechanism
The primary breakdown happens at the handoff between IT operations and procurement. IT logs outages in their ticketing system and focuses on restoring service. They have no visibility into the contract terms, the credit tiers, or the 20-day claim window. Procurement holds the contract but has no access to the monitoring tools. Accounts payable processes invoices automatically, unaware that a major outage occurred that should have reduced the payment. Three teams, zero coordination, and the window closes silently.
The evidence burden makes it worse. Gathering server logs, writing an operational impact statement, and identifying the correct vendor contact to submit to requires cross-departmental effort that nobody owns. For a $10,000 or $15,000 credit, IT managers routinely decide the administrative overhead isn't worth the disruption to their engineering team.
Business owners add a final layer of inaction. They're reluctant to file formal credit requests against a vendor they depend on for daily operations, viewing it as adversarial rather than contractual. The cumulative leakage across four incidents ($42,000) is invisible precisely because no single incident feels large enough to fight for.
The Recovery Math
Four incidents over 12 months, all documented in IT's incident management system, none claimed:
Month 2: Major platform outage. Availability dropped below 95%. Credit tier: 15%. $100,000 x 15% = $15,000.
Month 5: Database degradation. Availability fell to 96.5%. Credit tier: 10%. $100,000 x 10% = $10,000.
Month 8: Extended outage. Availability dropped below 95%. Credit tier: 15%. $100,000 x 15% = $15,000.
Month 11: Minor API disruption. Availability fell to 99.1%. Credit tier: 2%. $100,000 x 2% = $2,000.
Total unclaimed value: $42,000.
Identifying these four incidents required comparing internal IT incident logs and monitoring tickets against monthly vendor invoices and the executed SLA terms.
The Pattern
7 of every 10 contracts with manual SLA credit request mechanisms suffer from total value leakage. The combination of short notice windows, heavy evidence requirements, and organizational silos between IT and finance creates a structural default of non-enforcement that benefits the vendor.
For the downloadable PDF report with the full clause text and worked recovery math, email [email protected].
What You Can Do in 15 Minutes
Go look at your last three monthly invoices for your largest SaaS vendor. Search for "SLA credit" or "Service Credit." Then check whether your IT team documented any outages during those same months. If outages exist in the incident log but no credits appear on the invoices, your SLA clause is decorative and your organization is actively leaking contract value.
Analysis powered by allcaps.ai . Clause Forensics is a weekly series on procurement.news examining one contract clause, how it breaks, and what it costs.
This analysis is for informational purposes only and must be validated against the executed agreement, amendments, invoices, and operational records.
