Credits, Claims and Clauses: Turning Hosting SLAs into a Line Item Finance Can Defend

There is a persistent assumption in UK procurement that a service level agreement is a financial instrument: breach it, and the bill falls. The assumption survives because it is comforting and because the clause is rarely tested. When it is tested, the mechanism turns out to be narrower than almost anyone in the finance function expected.

Service credits are usually a discount on future invoices, awarded on request, calculated against the monthly fee for the affected service, capped at a modest percentage, and subject to a claim window that passes quickly. They are not compensation, and they are not a refund. Treating them as either produces two predictable outcomes: the credits go unclaimed, and the hosting line in the budget stays exactly where it was.

The practical response is to stop reading the SLA as reassurance and start reconciling it as a commercial instrument. The following points explain why the money is so often left behind, and what a workable routine looks like.

1. Nobody owns the claim

In most organisations, IT notices the incident and finance receives the invoice, and no role sits between them. The claim window closes while the incident is still being investigated. Assigning a named owner, with a diary reminder tied to the contractual deadline, resolves more lost value than any renegotiation.

2. The deadline is shorter than the memory

Claim periods of thirty days from the end of the month are common. That is shorter than a typical root cause analysis. A standing incident register, opened the same day an issue is detected, is the only reliable defence.

3. Exclusions absorb the common causes

Scheduled maintenance, customer-side faults, force majeure, third-party network failures, and issues arising from applications the customer controls are routinely excluded. Many real incidents land, legitimately or otherwise, inside one of those categories. Knowing which exclusions your provider invokes most often is useful intelligence at renewal.

4. The measurement point is not yours

The provider measures availability at its own boundary. Your users experience it at the application. Where a service is reachable but unusable, the provider may record availability and the customer may record an outage. A clause that names the measurement point, and permits customer evidence, narrows the gap.

5. The credit is smaller than the expectation

Credits are frequently calculated on the monthly recurring charge for the affected service alone, not on the total contract, and capped at a stated percentage. Where an application spans several services, the affected service may be a small fraction of the bill. Finance teams are often surprised by the arithmetic, and should model it before renewal rather than after the first breach.

6. Partial degradation is not an outage

A platform performing at half speed for a fortnight may never register as unavailable. If the agreement contains no service level for performance, there is no breach to claim and no credit to recover, regardless of the operational cost.

7. The renewal conversation starts too late

By the time the contract is under review, the leverage has usually gone. Credits are not retroactive, and a provider is unlikely to reopen a closed period. The evidence gathered throughout the year is what makes the renewal discussion substantive.

Building a reconciliation routine

A defensible process is not elaborate, but it must connect three records that normally live apart.

The first is an incident log with timestamps, affected services, user impact, and the evidence captured at the time: monitoring output, support ticket references, and correspondence. The second is the contract schedule of service levels, reduced to the handful of commitments that matter operationally. The third is the monthly invoice, annotated with the services it covers.

Once a month, the three are compared. Any incident that plausibly engages a service level is checked against the exclusions and the claim window, and a claim is submitted or the reason for not submitting is recorded. Quarterly, the pattern is reviewed: which services breach most often, which exclusions are relied upon, and whether credits recovered bear any relation to the operational disruption caused. Annually, that pattern becomes the agenda for renewal.

This is a finance-friendly discipline as much as a technical one. It converts an IT complaint into a documented commercial history, and it gives the budget holder something more persuasive than dissatisfaction.

What to renegotiate

At renewal, four changes are worth pursuing. First, extend the claim window to at least sixty days and permit submission through the account manager rather than a portal that resets each period. Second, narrow the broadest exclusions where the provider genuinely controls the element in question. Third, introduce a performance service level alongside availability, even a modest one, so that sustained degradation is recognised in the agreement. Fourth, state the calculation method explicitly, including which fees are included and what the cap is, so that the number can be forecast rather than discovered.

None of this turns hosting into an insurance policy. A credit will not recover a lost trading day, and any organisation relying on one to do so is misreading the instrument. What it does is put the agreement on the same footing as any other commercial term: measured, reconciled, and used as evidence when the contract comes up for review.