Your status page showed red for four hours last Tuesday. By Friday you had issued service credits to every affected customer — 10 percent of a month's fee here, 25 percent there — and your bookkeeper recorded them the way most small SaaS companies do: as a support cost, or a marketing concession, somewhere below the revenue line. Your revenue for the month is now overstated, your net revenue retention is wrong, and if a lender or acquirer ever opens your books, the first question will be the one you cannot answer: how much of the revenue you reported were you ever actually entitled to keep?
This is not a corner case. The average outage now takes 196 minutes to resolve, and small and mid-size businesses put the cost of an hour of downtime at around $8,000 — before a single credit is issued. Every credit you grant after an outage is a reduction of the price your customer agreed to pay, and under ASC 606 that makes it variable consideration: an amount that shrinks your revenue, not an expense that sits beneath it. This post explains what your SLA commits you to financially, how the standard wants you to book it, and what to fix at your next month-end close.
What your SLA actually promises — in dollars, not nines
Most SaaS contracts quote uptime as "nines": 99.9 percent (about 43 minutes of downtime a month), 99.95 percent, 99.99 percent (about 4 minutes). The number that matters for your books is not the nines but the credit schedule attached to them. A typical enterprise SLA reads something like this: uptime below 99.9 percent earns the customer a 10 percent service credit; below 99.0 percent, 25 percent; below 95.0 percent, a full month free. Some contracts escalate further, offering termination rights if uptime misses the target several months in a row.
Three features of that schedule shape the accounting:
Credits are a contractual price adjustment, not a goodwill gesture. The customer does not pay full price and then receive a gift. The contract says the price for a bad month is a lower price. That distinction — price reduction versus expense — is the entire accounting question, and the contract answers it before your bookkeeper ever opens the ledger.
Credits are usually capped and claimed, not automatic. Many SLAs require the customer to request the credit within 30 days, and cap total credits at 30 to 100 percent of one month's fee. That means your exposure on any given outage is bounded and estimable: you know the schedule, you know which customers were affected, and you know your historical claim rate.
Cash timing and revenue timing diverge. A credit issued in February for a January outage usually appears as a credit memo against a future invoice. The cash effect lands whenever the invoice is paid, but the revenue effect belongs to January — the period when you failed to deliver what you promised. Booking the credit in the month you issue it, against that month's revenue, misstates two periods at once.
Why ASC 606 calls an outage credit variable consideration
ASC 606's core idea is simple: recognize revenue at the amount of consideration you expect to be entitled to in exchange for delivering what you promised. Step 3 of the five-step model — determining the transaction price — is where your SLA enters the picture. The transaction price is not the sticker price on the order form. It is the sticker price minus everything that could come back: refunds, rebates, discounts, performance bonuses — and service credits for missed uptime.
PwC's revenue guide puts SLA credits squarely in this bucket. Variable consideration must be estimated at contract inception and updated every reporting period, using one of two methods:
- Expected value — the probability-weighted average across possible outcomes. This fits a portfolio of customers well: if history says 3 percent of monthly billings typically come back as SLA credits, your expected credit on $100,000 of monthly billings is $3,000.
- Most likely amount — the single most likely outcome. This fits a binary situation: one large customer whose contract either triggers a $20,000 credit this month or triggers nothing.
Then comes the constraint, the part founders most often skip. You may include variable consideration in the transaction price — that is, recognize the revenue — only to the extent it is probable that a significant reversal will not occur when the uncertainty resolves. In plain terms: if there is a real chance you will owe the credit back, do not count that slice as revenue yet. Record it as a refund liability instead, and true it up when the month's uptime is known.
Note what the constraint implies for a SaaS business with a meaningful outage history. If your service missed its SLA in four of the last twelve months, "we expect to owe nothing" is not a defensible estimate. Your own status page is the auditor's Exhibit A.
The journal entries: a month with an outage
Suppose one customer pays $10,000 a month, and your 99.9 percent SLA grants a 10 percent credit for any month uptime falls below the target. January's uptime comes in at 99.4 percent. Here is the full cycle.
At invoicing, the billed amount is deferred revenue as usual — cash received (or receivable booked) for service not yet delivered:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Receivable:Customer USD
2026-01-01 open Income:SaaS:Subscription USD
2026-01-01 open Liabilities:Deferred-Revenue:SaaS USD
2026-01-01 open Liabilities:Refund:SLA-Credits USD
2026-01-01 * "Customer" "January invoice — 10,000 monthly subscription"
Assets:Receivable:Customer 10000.00 USD
Liabilities:Deferred-Revenue:SaaS -10000.00 USD
2026-01-31 * "Month-end" "Recognize January revenue net of 500 expected SLA credits"
Liabilities:Deferred-Revenue:SaaS 10000.00 USD
Liabilities:Refund:SLA-Credits -500.00 USD
Income:SaaS:Subscription -9500.00 USD
2026-02-05 * "Customer" "Outage credit issued — January uptime 99.4 percent vs 99.9 SLA"
Liabilities:Refund:SLA-Credits 500.00 USD
Assets:Receivable:Customer -500.00 USDWalk through what happened. At month-end, you recognized $9,500 of revenue and parked $500 in a refund liability — your estimate of the credit January's outage will trigger. When the actual credit memo goes out in February, it debits the liability, not revenue and not an expense account. January's revenue was right the first time, and February's revenue is untouched by January's outage.
If the estimate and the actual differ, the difference adjusts revenue in the period the uncertainty resolves. Estimated $500 but issued $1,000 because two customers claimed instead of one? The extra $500 reduces revenue when you learn about it. Estimated $500 and nobody claimed? Release the $500 to revenue. The liability account is the shock absorber; revenue is never restated for a routine true-up.
Two details worth getting right. First, the refund liability is separate from deferred revenue: deferred revenue is for service you have not delivered yet, while the refund liability is for delivered service you may have to give back. Netting them together hides both stories. Second, if a credit relates to a future period — a free month granted as an apology rather than a contractual credit for a past failure — that is a different analysis, closer to a contract modification or a material right, and it adjusts future revenue rather than past.
The three mistakes SaaS founders make with SLA credits
Mistake 1: Booking the credit as an expense. This is the most common error and the most damaging. Recording a $10,000 outage credit as a debit to "customer support expense" or "marketing concessions" leaves revenue overstated by $10,000 and invents $10,000 of expense that never occurred. Gross margin, revenue growth, and every ratio built on revenue all read too high. Under ASC 606, amounts payable to the customer that are not for a distinct good or service received in return reduce the transaction price. A credit for your own outage buys you nothing distinct — it reduces revenue, full stop.
Mistake 2: Recognizing full revenue now and fixing it later. Some companies book the full $10,000 as January revenue, then record the $1,000 credit against February revenue when the credit memo goes out. Both months are now wrong: January too high, February too low. Worse, the error compounds in your metrics — January's net revenue retention looks great, February's looks soft, and neither reflects reality. The refund-liability pattern above exists precisely to keep each period honest.
Mistake 3: Estimating zero because the outage "won't happen again." The constraint runs on probability, not optimism. If your infrastructure had three SLA-triggering months last year, an estimate of zero expected credits is not conservative or aggressive — it is unsupported. Auditors test this estimate against your incident history, and acquirers in diligence will do the same. A small standing reserve, sized from trailing claim rates and trued up monthly, is both more accurate and far easier to defend than a confident zero that your status page contradicts.
What this does to the metrics buyers and lenders read
Getting SLA credits above the revenue line versus below it changes every number a SaaS company is valued on:
- MRR and ARR should be net of expected credits. If 2 percent of billings historically come back as SLA credits, a $1 million ARR headline is really $980,000 of expected revenue. Reporting the gross number is how founders end up explaining a "churn problem" in diligence that was actually a credit problem all along.
- Net revenue retention absorbs credits as contraction. A customer who paid $120,000 last year and $114,000 this year after outage credits retained at 95 percent, not 100 percent — even if they never downgraded a seat.
- Gross margin rises when you fix the error, paradoxically. Moving credits out of support expense and into contra-revenue shrinks both revenue and cost of revenue, and since the credit exceeds any associated cost, margin percentage improves while revenue falls. Expect the question, and have the restated history ready.
If you use plain-text accounting, the fix is structural rather than procedural: a dedicated Liabilities:Refund:SLA-Credits account, a month-end entry that recognizes subscription revenue net of the expected credit, and a true-up entry when credit memos go out. The beancount documentation on revenue recognition patterns covers the general shape of deferred-revenue accounting that this builds on, and the balance-sheet history of the refund account doubles as your audit trail for the estimate.
A month-end checklist that takes twenty minutes
- Pull uptime per customer tier. Your monitoring already computes this; ask for the monthly number against each SLA threshold, not just the fleet average.
- List triggered credits. For each customer below threshold, compute the contractual credit from the schedule — before checking who has actually claimed.
- Apply your claim-rate history. If roughly 60 percent of triggered credits are historically claimed, your expected value is 60 percent of the triggered total. Document the rate and revisit it quarterly.
- Book revenue net of the estimate. Recognize subscription revenue with the expected credit parked in the refund liability, as in the example above.
- True up last month's estimate. Compare last month's reserve to the credit memos actually issued; release or top up the difference through current-period revenue.
- Reconcile the liability balance. The refund account should hold only unresolved estimates. Anything older than your claim window (usually 30 to 60 days) should have been released already — a growing stale balance means true-ups are being skipped.
Start this month, not next quarter. Pull last month's uptime report, compute the credits your SLA schedule says you owe, and compare that number to what your books show as a revenue reduction. If the books show zero — and for most early-stage SaaS companies, they show zero — you have found your first true-up entry, and your revenue has been overstated by exactly that amount every month like it.
