Variable Consideration in SaaS Contracts: A Practitioner's Guide to ASC 606-32-05

What is variable consideration, really?

Variable consideration is any portion of a contract where the consideration you'll receive isn't fixed at contract signing.

If a customer signs a $24,000 annual subscription with no usage fees, no credits, no refunds, no overages — there's no variable consideration. The transaction price is $24,000. Done.

If the same customer signs a $24,000 base subscription PLUS $0.10 per API call above 10,000/month — you have variable consideration. You don't know in advance how many API calls they'll make. The total transaction price could be $24,000 or $30,000 or $50,000 depending on usage.

ASC 606 (specifically 606-10-32-5 through 32-13) tells you how to estimate that variable amount, when to recognize it, and how to update your estimate as you learn more.

---

The two estimation methods

ASC 606 gives you two methods for estimating variable consideration:

Method 1: Expected value

The probability-weighted average across all possible outcomes. Best when you have many possible outcomes and historical data.

Example: A customer's usage might be anywhere from 5,000 to 50,000 API calls/month. Based on similar customers, you estimate:

• 20% chance of <10,000 calls (no overage, $0 variable)
• 40% chance of 10,000-15,000 calls ($500 variable)
• 30% chance of 15,000-25,000 calls ($1,500 variable)
• 10% chance of >25,000 calls ($3,500 variable)

Expected value = (0.20 × $0) + (0.40 × $500) + (0.30 × $1,500) + (0.10 × $3,500) = $1,000

Method 2: Most likely amount

The single most likely outcome. Best when there are only a few possible outcomes (e.g., a performance bonus that's either earned or not).

Example: A customer gets a $5,000 refund if you miss a milestone. You think there's a 70% chance you'll hit the milestone. The most likely amount is $0 refund.

Pick the method that better predicts the amount you'll receive. Use the same method consistently for similar situations within your business.

---

The constraint (this is the most important concept)

You don't include all of your estimated variable consideration in the transaction price. You apply a constraint.

ASC 606-10-32-11 says: include variable consideration in transaction price only to the extent that it's probable that a significant reversal will not occur.

Translation: only recognize the variable amount you're highly confident you'll actually keep.

What this looks like in practice

Imagine you estimate $10,000 of variable consideration. But you've only had 3 months of usage data on this customer, and similar customers' usage has been volatile. You might apply a constraint of $4,000, meaning you only include $6,000 in your transaction price. The $4,000 sits "constrained" — you'll release it as you get more data.

Factors that increase the constraint (i.e., reduce how much you recognize)

• Limited history of similar contracts
• High variability in similar customers' behavior
• External factors outside your control (market conditions, regulatory changes)
• Long forecast horizon (predicting 12 months out is harder than 3 months)
• Customer's right to refund or terminate

Factors that decrease the constraint (i.e., increase how much you recognize)

• Strong historical data showing consistent patterns
• Short forecast horizon
• Customer commitment / minimum guarantees
• Variable amount is small relative to total contract

The constraint is the most subjective part of ASC 606. Auditors will probe heavily. Document your reasoning.

---

The practical expedient (the SaaS founder's best friend)

For most SaaS usage-based pricing, you don't have to estimate variable consideration upfront. There's a practical expedient under ASC 606-10-32-40 that says: if the variable consideration relates to a series of distinct services and is allocated to a specific period, you can recognize it as that period of service is delivered.

In English: if you sell usage-based pricing, you can recognize the variable usage revenue in the period the usage happens, instead of estimating upfront.

This is huge. It means a SaaS company with $0.10/API call pricing doesn't have to forecast a year of API calls at contract signing. You just recognize $0.10 every time an API call happens.

This expedient applies when:

1. You have a stand-ready obligation (you're providing access to a service)
2. The variable consideration is tied to specific periods of use (usage in March = revenue in March)
3. The variable consideration is for distinct services that are part of a series (each API call is a distinct service in a series)

Most SaaS usage models qualify. Document the application of the expedient in your rev rec policy.

---

The five common SaaS variable consideration scenarios

Scenario 1: Pure usage-based pricing

Contract: Customer pays $0.10/SMS sent. No subscription, no commit.

Analysis:

• Performance obligation: stand-ready to deliver SMS API services (a series of distinct services per 606-10-25-15)
• Variable consideration: every SMS billed at $0.10
• Practical expedient (606-10-32-40) applies
• Recognition: revenue recognized in the period of delivery

Treatment: No upfront estimation needed. Recognize $0.10 every time an SMS sends.

Scenario 2: Subscription + usage overage

Contract: $36,000 annual subscription. Includes 50,000 envelopes/year. Overage at $0.50/envelope.

Analysis:

• Performance obligation: subscription with envelope capacity (stand-ready obligation)
• Fixed consideration: $36,000
• Variable consideration: envelope overage (variable amount per envelope above 50,000)
• Practical expedient applies for the overage portion
• Recognition: $3,000/month for subscription. Plus overage recognized when used.

Treatment: Don't try to predict the overage at contract signing. Apply expedient. Recognize overage in the period it's incurred.

Scenario 3: SLA service credits

Contract: $60,000 annual subscription. SLA: 99.5% uptime. If uptime drops below 99.5% in any month, customer gets a 5% credit ($250) for that month.

Analysis:

• This is variable consideration in the form of potential refund/credit (606-10-32-7)
• Estimate using "expected value" or "most likely amount" based on your historical uptime
• Apply constraint per 606-10-32-11
• If historical uptime is >99.7% consistently, estimate $0 in credits and recognize full $60,000 ratably
• When an SLA event actually occurs, recognize the credit as a reduction of revenue in that period

Treatment: Initial estimate based on history. Adjust when actual SLA events occur.

Scenario 4: Volume discount tiers

Contract: $0.20/API call up to 1M calls/year. $0.15/call from 1M-5M. $0.10/call above 5M.

Analysis:

• Each tier is a price point for the same stand-ready obligation
• Variable consideration in the form of pricing tiers
• Estimate using customer's expected usage
• If customer historically uses 3M calls, expected price is $0.15/call
• Apply expedient if uncertainty about tier remains throughout the year

Treatment: Estimate based on customer's likely tier. If usage straddles tiers, you may need to true-up at year-end.

Scenario 5: Performance bonuses / refunds / rights

Contract: $50,000 annual subscription. $10,000 bonus if customer achieves >90% adoption by month 6. $5,000 refund if customer cancels before month 3.

Analysis:

• Two pieces of variable consideration: the bonus and the refund
• Bonus: most likely amount method. If you historically achieve >90% adoption 60% of the time, most likely amount is $10,000 (60% > 50%)
• Apply constraint: if 60% probability isn't "probable that significant reversal will not occur," constrain to $0 until milestone is achieved
• Refund: most likely amount. If <5% of customers cancel before month 3, most likely amount is $0

Treatment: Often constrain heavily upfront. Release when milestone achieved or refund period expires.

---

How to document your estimates

For every contract with variable consideration, your workpaper should answer:

1. What's the source of variability? Usage, credits, refunds, bonuses, discounts?
2. Which estimation method? Expected value or most likely amount?
3. What data did you use? Historical patterns, contract terms, customer behavior?
4. What's your estimate? Specific dollar amount.
5. What constraint did you apply? Specific dollar amount.
6. What's the basis for the constraint? Why are you not recognizing more?
7. When will you re-evaluate? Quarterly review? Trigger events?

Without this documentation, auditors will treat your numbers as guesses. With it, they're defensible judgments.

---

Year-end true-ups

When actual variable consideration is known (after the period ends), you compare to your estimate and book a true-up.

Example: You estimated $5,000 in usage overage for a customer in Q1. Actual was $7,200. Book a $2,200 true-up in Q1's prior period (if material) or in current period (if immaterial).

The true-up adjustment shows in your revenue line. Material true-ups can be flagged to investors as "true-up adjustments" in your MD&A.

Done well, true-ups are small (within 5% of estimates). Done poorly, they're huge — and a flag that your estimation methodology needs work.

---

The most common founder mistakes

Mistake 1: Treating usage as a separate performance obligation

The overage in your $36K + overage contract isn't a separate PO. It's variable consideration on the same stand-ready obligation. Recognizing it as a separate PO leads to wrong allocation.

Mistake 2: Not applying the constraint

Founders sometimes recognize 100% of their estimated variable consideration without constraint analysis. Auditor will reduce it.

Mistake 3: Recognizing SLA credits when the SLA is breached, not when probable

If you have a history of breaching SLAs and issuing credits, you should be reducing revenue upfront with an estimated credit reserve — not waiting for each breach.

Mistake 4: Forgetting to update estimates

Variable consideration estimates need re-evaluation each quarter (at minimum). If you set the estimate at contract signing and never look at it again, you'll be way off by year-end.

Mistake 5: Misapplying the practical expedient

The 606-10-32-40 expedient only applies to series of distinct services. If you try to use it for non-series variable consideration (e.g., one-time performance bonuses), your auditor will reject the treatment.

---

A quick decision tree

When you encounter variable consideration in a contract, work through this:

1. Is it a series of distinct services? (e.g., usage-based pricing)
   • Yes → Apply 606-10-32-40 expedient. Recognize as consumed. Skip the rest of this tree.
   • No → Continue to step 2.
2. Which method better predicts the outcome?
   • Many possible outcomes with data → Expected value
   • Few possible outcomes → Most likely amount
3. What's your estimate?
4. What's the probability of significant reversal?
   • Low (you're confident in the estimate) → Constrain minimally
   • Medium → Constrain moderately
   • High → Constrain heavily (sometimes to zero)
5. Document the reasoning.
6. Re-evaluate quarterly.

---

Frequently asked questions

How often do I need to update variable consideration estimates?

At minimum quarterly. Trigger events (large contract modifications, significant changes in customer behavior, regulatory changes) should prompt immediate re-evaluation.

Can I just recognize variable consideration as billed?

Sometimes yes (practical expedient), sometimes no. Pure usage-based with the series characteristics: yes. Performance bonuses, volume discounts spanning periods, SLA credits: no.

What's the difference between "expected value" and "most likely amount"?

Expected value is the probability-weighted average across all outcomes. Most likely amount is the single most probable outcome. Use whichever better predicts what you'll receive.

What if my estimate is wrong?

You true it up in the next reporting period. Material true-ups (>5% of estimate) may need to be disclosed to investors.

Does the constraint apply to refundable amounts?

Yes. Anything refundable to the customer should be constrained out of revenue until the refund period passes.

What's the most common variable consideration scenario for SaaS?

Usage-based pricing on top of a subscription. Roughly 60% of B2B SaaS now has some form of hybrid pricing.

Do I need to disclose variable consideration in my financial statements?

For public companies, yes (under ASC 606's disclosure requirements). For private companies, the disclosures are less detailed but still required if material.

How does variable consideration interact with contract modifications?

A modification can change the variable consideration estimate (e.g., new SLA terms, new pricing tiers). You re-estimate at modification date and adjust accordingly.

What about prepayments for usage credits?

Prepayments create a contract liability (deferred revenue). As credits are consumed, recognize revenue. Unused credits at expiration may be recognized as breakage (606-10-55-46/49).

Can I just ignore small variable consideration?

Materiality matters. If variable consideration is <1-2% of total revenue and immaterial to financial statements, you can simplify treatment. Document your materiality threshold.

---

The bottom line

Variable consideration is the hardest part of ASC 606. The framework gives you tools (estimation methods, constraint, practical expedient), but applying them requires judgment that compounds across hundreds of contracts.

Done in a spreadsheet, it's nearly impossible to maintain consistency. Each contract gets a slightly different treatment. Auditors find the inconsistencies.

Done in a real tool, the methodology is centralized and consistent. Estimates auto-update with actual data. True-ups happen monthly. Documentation is automatic.

If you have usage-based pricing, SLA credits, refundable contracts, or volume discount tiers, try RevRec Engine. The variable consideration logic is built in, applied consistently, and documented in your audit workpaper automatically.

---

About the author: Chris is a CPA and founder of RevRec Engine. He spent years working in SaaS finance teams where variable consideration was the #1 source of audit findings.

Related reading:

• ASC 606 for SaaS Founders: A Plain-English Guide
• Contract modifications and ASC 606: when to treat as separate vs. cumulative
• ASC 606 for AI startups: usage-based pricing, model fees, and inference revenue