Variable consideration in revenue recognition: how to estimate it and when to constrain it
Discounts, rebates, and usage fees are variable consideration under ASC 606. How to estimate them, apply the constraint, and keep the audit trail.
Part of the revenue recognition guide.
Variable consideration is any part of a contract's price that can change based on future events: discounts, rebates, refunds, credits, price concessions, performance bonuses, penalties, and usage-based fees. Under ASC 606, you estimate it at contract inception using either the expected value method or the most likely amount method. Then you apply the constraint: you include only the amount for which it is probable that a significant reversal of cumulative revenue will not occur.
That sentence carries most of the work. The rest is choosing the right method, documenting the judgment, and updating the estimate every reporting period. This guide explains variable consideration in revenue recognition with two worked examples, one for each method, and shows the journal entries that follow.
Key takeaways
• Variable consideration is part of the transaction price in step three of ASC 606, estimated upfront rather than recognized only when it becomes certain.
• Use the expected value method for large portfolios with many possible outcomes, and the most likely amount method for binary outcomes such as a bonus that is either earned or not.
• The constraint limits the estimate to the amount for which a significant reversal of cumulative revenue is not probable (ASC 606-10-32-11).
• Estimates must be reassessed at every reporting date, and changes are recorded as cumulative catch-up adjustments.
• Many usage-based SaaS fees never need an estimate, because the variable amount can be allocated to the period in which the usage occurs.
• Loopfour, the deterministic finance workflow automation platform, recalculates constrained estimates from approved inputs every close and routes changes above a threshold to a named approver.
What is variable consideration in revenue recognition?
Variable consideration is the portion of a contract's transaction price that depends on the occurrence or non-occurrence of a future event. ASC 606-10-32-6 lists the common forms: discounts, rebates, refunds, credits, price concessions, incentives, performance bonuses, and penalties. Consideration is also variable when your right to it depends on a future event, such as a product sold with a right of return.
Variable consideration lives in step three of the five-step model. If you need the full model first, see what ASC 606 is and how the five steps work. Under ASC 606, you do not wait for the variable amount to become fixed. You estimate it, constrain it, and include it in the transaction price from contract inception.
Variable consideration is not always written into the contract. An implied price concession counts too, such as a customary practice of accepting less than the invoiced amount from a class of customers. If your team routinely grants credits that the contract never mentions, those credits are variable consideration.
| Common source | SaaS or services example | Usually estimated with |
|---|---|---|
| Service-level credits | Credits when uptime falls below a threshold | Expected value, across a portfolio |
| Volume rebates | Retroactive price reduction above a spend tier | Most likely amount or expected value, depending on the range of outcomes |
| Performance bonuses | Bonus for go-live by a fixed date | Most likely amount |
| Price concessions | Customary write-downs for a customer class | Expected value |
| Usage-based fees | Per-API-call or per-seat overage fees | Often allocated to the period of usage instead of estimated |
How do you estimate variable consideration?
ASC 606-10-32-8 allows two methods: the expected value and the most likely amount, and you use whichever better predicts the amount you will be entitled to. The choice is not a free policy election. It depends on the shape of the possible outcomes.
• Expected value: the probability-weighted sum of a range of possible amounts. It fits when you have a large number of contracts with similar characteristics and many possible outcomes.
• Most likely amount: the single most likely amount in a range of possible amounts. It fits when the contract has only two possible outcomes, such as a bonus that is either earned or not.
ASC 606-10-32-9 requires you to apply one method consistently throughout the contract for a given uncertainty. Different uncertainties in the same contract can use different methods, for example, expected value for SLA credits and most likely amount for a go-live bonus. Estimates should use all reasonably available information (historical, current, and forecast) that is consistent with the data you use elsewhere, such as in pricing and bid decisions.
Worked example 1: the expected value method for SLA credits
Expected value works best when you have a portfolio of similar contracts and several possible outcomes. Suppose you sell a 12-month platform subscription for $120,000, billed $10,000 monthly. The contract grants service-level credits: 5% of the annual fee if uptime falls below 99.9%, and 10% if it falls below 99.5%.
Your history across several hundred similar contracts shows the following outcomes.
| Uptime outcome | Credit | Historical probability | Probability-weighted credit |
|---|---|---|---|
| 99.9% or higher | $0 | 85% | $0 |
| 99.5% to 99.9% | $6,000 | 10% | $600 |
| Below 99.5% | $12,000 | 5% | $600 |
| Expected credit | 100% | $1,200 |
The expected value of the transaction price is $120,000 − $1,200 = $118,800. The most likely amount method would have given $120,000, which ignores a known 15% chance of paying a credit. With a large, stable portfolio, the expected value better predicts what you will collect.
Applying the constraint
Next, ask whether it is probable that including $118,800 will not cause a significant reversal of cumulative revenue. The worst outcome, a $12,000 credit, would reverse $10,800 against $118,800 of recognized revenue, roughly 9% of the contract. Your data is deep and stable, the uncertainty resolves within the year, and your uptime record has not changed. Your team concludes the constraint does not bite, and $118,800 stands.
If the product were new, the answer would change. With limited experience and a shifting infrastructure, the ASC 606-10-32-12 factors point toward a larger constraint. A team could reasonably constrain the price to $108,000, the amount assuming the maximum credit, until it has data.
Journal entries for the SLA example
Each month, you bill $10,000 but recognize $9,900, and the $100 difference builds a refund liability. ASC 606-10-32-10 requires a refund liability for consideration you expect to return to the customer.
| Date | Account | Debit | Credit |
|---|---|---|---|
| Each month-end (x12) | Accounts receivable | $10,000 | |
| Subscription revenue | $9,900 | ||
| Refund liability, SLA credits | $100 | ||
| Year-end, if the 5% credit is earned | Refund liability, SLA credits | $1,200 | |
| Subscription revenue | $4,800 | ||
| Accounts receivable (credit memo) | $6,000 |
After the year-end entry, cumulative revenue is $118,800 − $4,800 = $114,000, which equals the $120,000 fee less the $6,000 credit. If no credit is earned, you instead debit the refund liability and credit revenue for $1,200, bringing cumulative revenue to $120,000.
Worked example 2: the most likely amount method for a performance bonus
Most likely amount works best when there are only two outcomes. Suppose a services contract has a fixed fee of $200,000 for an implementation, plus a $30,000 bonus if the customer goes live by March 31. The implementation is one performance obligation, satisfied over time and measured by cost-to-cost progress.
Your team has delivered many similar projects and hits the date on about four out of five. The most likely amount is $30,000, so the transaction price is $230,000. The expected value method would include a $24,000 bonus, an amount the contract can never actually pay, which is why it is the wrong method for a binary outcome.
The constraint still applies. Your team's track record is strong, the project is standard, and the date is within your control. Your team concludes a significant reversal is not probable, so the $30,000 stays in. Had the project depended on a customer data migration you have never done before, constraining the bonus to zero until the risk resolves would be the defensible answer.
| Month | Cumulative progress | Transaction price used | Cumulative revenue | Revenue this month |
|---|---|---|---|---|
| January | 40% | $230,000 | $92,000 | $92,000 |
| February | 70% | $230,000 | $161,000 | $69,000 |
| March (bonus missed) | 100% | $200,000 | $200,000 | $39,000 |
When the bonus is missed, the change is a cumulative catch-up. March revenue is $200,000 − $161,000 = $39,000. That equals March's 30% of the work at the $200,000 price ($60,000), less the $21,000 of bonus revenue recognized in January and February. Had the bonus been earned, March revenue would have been $69,000.
When does the constraint apply?
The constraint applies whenever including an estimate creates a risk that a significant amount of cumulative revenue will later be reversed. Under ASC 606-10-32-11, you include variable consideration only to the extent it is probable that a significant reversal will not occur when the uncertainty resolves.
ASC 606-10-32-12 lists factors that increase the likelihood or magnitude of a reversal:
• The amount is highly susceptible to factors outside your influence, such as market volatility, third-party judgment, weather, or obsolescence.
• The uncertainty will not be resolved for a long time.
• Your experience with similar contracts is limited, or has limited predictive value.
• You have a practice of offering a broad range of price concessions or changing payment terms in similar circumstances.
• The contract has a large number and broad range of possible outcomes.
The constraint is assessed on both likelihood and magnitude. A reversal that is likely but small relative to cumulative revenue does not trigger it. A reversal that is unlikely but large still needs a documented assessment.
Special cases: usage fees and royalties
Two situations often let you skip estimating variable consideration altogether. Both matter for SaaS and AI companies.
• Allocating variable consideration to a period. When a SaaS subscription is a series of distinct service periods, usage fees that relate specifically to one period can be allocated entirely to that period (ASC 606-10-32-39 to 32-40). You recognize them when the usage occurs. See revenue recognition for usage-based billing for the full treatment.
• Sales- or usage-based royalties on licenses of IP. Revenue is recognized at the later of the subsequent sale or usage and the satisfaction of the related performance obligation (ASC 606-10-55-65). You do not estimate the royalty upfront.
Minimum commitments, tiered pricing, and retroactive rebates can break these shortcuts. A retroactive volume discount, for example, changes the price of units already delivered, so it usually needs an estimate.
Reassessing and documenting the estimate
You must update the estimate of variable consideration at the end of each reporting period (ASC 606-10-32-14), and record changes as a cumulative catch-up. That makes variable consideration a recurring close task, not a one-time contract review.
Auditors will ask for three things: the method and why it fits, the data behind the probabilities, and the constraint assessment. Keep a dated record of each estimate, its inputs, and the approver. Our guide on how auditors test revenue recognition covers what they sample.
→ Collect inputs: uptime logs, rebate tier progress, project milestones, historical credit rates.
→ Recalculate: apply the approved method to current inputs.
→ Compare: measure the change against the prior estimate.
→ Escalate: route changes above a set threshold to the controller for approval.
→ Post: book the cumulative catch-up and file the evidence.
Book a workflow review to see how this reassessment runs on your stack each close.
How to choose a process for variable consideration
Choose a process that makes the estimate reproducible: the same inputs should always produce the same number, and every change should be traceable to an approver. That rules out estimates that live only in someone's head or in an unversioned spreadsheet.
A horizontal automation platform can pull uptime data or rebate progress into a sheet, and that flexibility is useful. It will not tell you when a change is large enough to need approval, and it will not keep the evidence together. An AI agent can summarize a contract's rebate terms, but it should not choose your constraint at runtime.
Loopfour runs predefined, programmatic steps instead. The Contract Agent extracts variable terms (SLA thresholds, rebate tiers, bonus dates) from the signed contract under a confidence threshold, with low-confidence fields routed to a reviewer. Every step after that is deterministic: recalculate with the approved method, compare, route material changes to Slack for approval, and post the entry. The execution tree records each input and approver, so the audit file builds itself as the close runs.
Frequently asked questions
What is variable consideration under ASC 606? Variable consideration is any amount in a contract's price that can change because of a future event, such as discounts, rebates, refunds, credits, price concessions, performance bonuses, penalties, or usage-based fees. Under ASC 606, you estimate it at contract inception and include it in the transaction price, subject to the constraint.
What is the difference between expected value and most likely amount? The expected value method probability-weights a range of outcomes and suits large portfolios with many possible results. The most likely amount method picks the single most likely outcome and suits binary situations, such as a bonus that is either earned or not. ASC 606 requires the method that better predicts the amount you will receive.
What is the variable consideration constraint? The constraint limits variable consideration to the amount for which it is probable that a significant reversal of cumulative revenue will not occur when the uncertainty resolves. It considers both the likelihood and the magnitude of a possible reversal. It is set out in ASC 606-10-32-11 and 32-12.
Are SLA credits variable consideration? SLA credits paid or credited to the customer are generally treated as variable consideration, because they reduce the amount you are entitled to based on a future event. You estimate them, usually with the expected value method across a portfolio, and record a refund liability for amounts you expect to credit.
How often do you update variable consideration estimates? ASC 606 requires you to update estimates of variable consideration, including the constraint assessment, at the end of each reporting period. Changes are recorded as cumulative catch-up adjustments to revenue in the period of the change.
Conclusion
Variable consideration in revenue recognition is where ASC 606 asks for judgment most often. Pick the method that fits the shape of the outcomes, constrain it honestly, and update it every period with evidence attached. The judgment is yours. The recalculation, the comparison, and the paper trail should run the same way every close.
Tell us the one workflow your team dreads. We will show it running: deterministic, permissioned, and auditable.
Book a demo.
Sources
• Deloitte DART, Revenue Roadmap, 6.3 Variable consideration
• FASB, ASU 2014-09, Revenue from Contracts with Customers (Topic 606)
Related reading
• How to recognize revenue on a contract with multiple performance obligations
• How to automate ASC 606 revenue recognition without losing the audit trail
• How to build a deferred revenue waterfall schedule
• Audit trails for automated finance
Sources
- Financial Accounting Standards Board, ASU 2014-09, Revenue from Contracts with Customers (Topic 606) (opens in a new tab).