Variable Consideration Under ASC 606: How to Apply the Constraint

Most finance teams know the phrase “variable consideration.” Fewer know exactly when the constraint kicks in or why getting it wrong compounds quietly into catch-up adjustments and audit questions at the worst possible time.

The standard’s guidance on variable consideration is one of its more prescriptive sections. The problem isn’t ambiguity. The problem is that the constraint requires a judgment call about probability, and probability judgments are uncomfortable to document. So, teams either ignore the constraint altogether or apply it so conservatively that recognized revenue understates actual performance. Neither is defensible.

This blog uncovers what ASC 606 requires, where the judgment calls live, and how to make them in a way that holds up under audit.

What Counts as Variable Consideration

Variable consideration is any amount that depends on something uncertain at contract inception. The list is longer than most people expect:

• Usage-based fees: the customer pays based on what they consume
• Performance bonuses: additional amounts if specified targets are hit
• Discounts, rebates, and refunds: amounts subject to adjustment after the fact Penalties and clawbacks: reductions triggered by failure to meet SLAs or milestones
• Price concessions: informal adjustments that become expected even when not contractual
• Most-favored-nation clauses: though these often raise contract modification questions as much as variable consideration questions, and the classification matters for how you account for the adjustment

The challenge with usage-based pricing specifically is that the variability isn’t just in the total contract amount, it’s in every billing period. Revenue is earned as usage occurs, but the total obligation at any point in time is genuinely uncertain. That creates a re-estimation requirement at every close, not just at contract inception.

One important distinction:

Sales- or usage-based royalties on licenses of *intellectual property* have their own exception under ASC 606-10-55-65. For those arrangements, where the fee is a royalty tied to the customer’s use or sale of licensed IP, such as a software license priced per deployment, you don’t estimate and constrain at contract inception. You recognize revenue only when the usage actually occurs. The exception applies to *sales- or usage-based royalties on licenses of IP* specifically (ASC 606-10-55-65). Service contracts with API access, compute time, data processing where the vendor provides a service rather than licensing the underlying IP all follow variable consideration rules.

The estimate-and-constrain framework described in this article applies to all other variable consideration: performance bonuses, rebates, tiered pricing above a committed base, and similar structures.

If your contracts involve a software license with usage-based fees, confirm with your auditor whether the royalty exception applies before setting up your recognition methodology.

The Two Estimation Methods

ASC 606 gives companies two ways to estimate variable amounts: the *expected value* method and the *most likely amount* method. The standard doesn’t say which one to use, it says to use whichever one better predicts the amount of consideration the company expects to receive.

Expected value works when there’s a range of possible outcomes. You take the probability-weighted sum of those outcomes. Let’s say a contract has a $1M base fee plus a bonus structure: 20% chance of a $500K bonus, 50% chance of a $200K bonus, 30% chance of no bonus. The expected value of the variable portion is ($500K × 20%) + ($200K × 50%) + ($0 × 30%) = $200K. That’s your starting estimate before applying the constraint.

Most likely, the amount works when there are really only two outcomes: you either hit the threshold or you don’t. A sales performance bonus that triggers at 120% of quota is a binary outcome: it pays or it doesn’t. In that case, picking the most probable single outcome is more predictive than probability-weighting across a range.

In practice, usage-based contracts almost always call for expected value because actual consumption is distributed across a range. Binary bonus structures call for most likely amount. The method needs to be applied consistently, documented at contract inception and updated as new information develops.

The Constraint — The Part That Actually Gets Missed

Estimating variable consideration is only half the work. Before any variable amount can be included in the transaction price, it must pass the constraint test. The constraint says: include variable consideration only to the extent that it is *probable* there will not be a *significant* reversal of cumulative revenue when the uncertainty resolves. Both words do work here, and most constraint arguments with auditors happen on the second one, not the first.

“Probable” under US GAAP means likely to occur, and that’s a high bar on its own. But “significant” requires a separate judgment about magnitude. A 4% revenue reversal might not be significant in absolute terms. That same 4% reversal could be highly significant if it pushes you below a debt covenant threshold, flips a profitable quarter to a loss, or affects a metric that’s central to your investor guidance. Significance is evaluated in context, not just as a percentage of total revenue. This is where auditor conversations get specific — and where you want the analysis documented before the quarter closes, not after.

5 Factors That Lead to a Revenue Reversal

ASC 606-10-32-12 identifies five factors that increase the likelihood of a revenue reversal. These aren’t independent tests to check off, they are indicators for a totality-of-circumstances judgment. A contract might hit three of them and still support a reasonable estimate; another might trigger only one, but that one factor dominates everything else. The question is always: based on all available information, is it probable that including this amount won’t result in a significant reversal?

• The consideration is highly susceptible to factors outside the entity’s influence (market volatility, third-party performance, weather)
• The uncertainty about the amount isn’t expected to resolve for a long time
• The company doesn’t have much experience with similar contracts
• The contract has a broad range of possible consideration amounts
• There’s a history of broad price concessions in similar arrangements

These factors are considered in totality, not as a checklist (ASC 606-10-32-12).

The constraint doesn’t mean you have to recognize zero until every variable is resolved. It means you can’t include amounts where a reversal is probable. A company with three years of usage data on similar customers can make a supported estimate. A company in its first year with a new pricing model, selling to customers with no usage history, has a weaker basis for the same estimate.

A Common mistake in Variable Consideration Under ASC 606

Applying the constraint as an all-or-nothing rule — either including the full estimated variable amount or recognizing zero. The standard allows for constrained estimates: include the portion where it is probable no significant reversal will occur, and exclude the rest. A variable bonus that you estimate at $200K but can only support $120K of as probable under the constraint test should show $120K in the transaction price, not $0 and not $200K.

Re-estimation at Every Reporting Period

This is where variable consideration becomes an ongoing operational problem, not just an accounting policy decision.

Under ASC 606, the transaction price — including constrained variable amounts — must be updated at each reporting period to reflect new information. That update happens in two distinct steps.

• First, you re-estimate: update your expected value or most likely amount using current data, revised probabilities, and actual performance to date.
• Second, you re-constrain: apply the constraint test to your *new* estimate, not to the prior-period number. A company that re-estimates upward but skips re-applying the constraint has only done half the work — and risks recognizing revenue that still fails the probable-no-significant-reversal test. If actual usage comes in higher and the constraint is still satisfied, you recognize the catch-up in the current period. If a performance bonus you had included now looks less probable, you reverse the portion that fails the constraint. Either way, the adjustment flows through current-period revenue.

For companies with large volumes of usage-based contracts, that re-estimation process can be enormous. Thousands of contracts, each with a current estimate and an updated actual, all needing comparison at close. The companies that do this manually, in spreadsheets or via periodic reconciliation between billing and accounting, are accepting a level of close risk that compounds with portfolio growth.

The re-estimation also has to be documented. Your auditors will ask what changed from last quarter’s estimate and why. “Actuals came in higher” is not an audit-ready answer without the underlying data trail showing the original estimate, the methodology, the updated actuals, and the resulting catch-up. That documentation must exist at the contract level, not just in the aggregate P&L.

Where This Goes Wrong in Practice

The most common variable consideration failure isn’t a technical accounting error, it’s a documentation and process failure. The accounting judgment is made once at contract inception, written into a memo, and then never revisited until the auditors ask about a catch-up adjustment three quarters later.

Three patterns show up repeatedly:

1) Optimistic initial estimates, no re-estimation cadence.

A team estimates variable amounts aggressively at contract inception because the constraint analysis is done quickly and without sufficient data. Revenue gets recognized based on that estimate for two quarters. Actual performance resolves lower. The catch-up is material. This is avoidable with a disciplined quarterly re-estimation process, it’s not optional under the standard.

2) Treating the constraint as a one-time policy decision.

The initial documentation says, “we applied the constraint and included $X.” Fine for period one. But if the same $X goes unreviewed for six quarters, that’s not a constraint application — it’s an accounting error waiting to be discovered. The standard requires the estimate to reflect current information.

3) Disconnected billing and rev rec data.

When billing captures usage and the rev rec team is working from a separate system or a periodic export, the re-estimation process requires a reconciliation step that introduces lag and error. Updated actuals land in billing; the accounting team doesn’t see them until after close has started. The adjustment goes in late or gets deferred to next quarter. Neither is right.

What Your System Needs to Handle

Variable consideration re-estimation at scale requires system support. The accounting judgment is a human decision, but the data collection, comparison, and catch-up calculation can’t be a manual spreadsheet exercise when you have hundreds or thousands of contracts in play.

At minimum, the system needs to:

• Hold the original transaction price estimate at the contract level, with the variable component clearly separated from fixed fees
• Capture updated usage actuals as they occur, in the same system, not via export, so the re-estimation inputs are always current
• Calculate the catch-up adjustment automatically when actuals deviate from estimates, with the delta flowing to current-period revenue
• Maintain a complete audit trail at the contract level: original estimate, methodology, each quarter’s updated estimate, and the resulting revenue recognized
• Flag contracts where the variable component exceeds a threshold, or where the estimate changed materially period-over-period, for controller review before close

The companies that handle variable consideration well are the ones where re-estimation is an automated comparison, not a manual project. The accounting team reviews exceptions, approves the catch-up amounts, and documents the judgment calls. The system does the calculation.

The bottom line

Apply the constraint based on your actual data and experience with similar contracts, not conservatively by default (and not aggressively because the number is appealing). Document the methodology at contract inception. Re-estimate at every reporting period and document what changed. If your current system makes that re-estimation process a quarterly fire drill, that’s the problem to fix first.

Frequently Asked Questions

What is variable consideration under ASC 606?

Variable consideration is any amount in a contract that depends on an uncertain future event: usage, performance targets, market outcomes, or customer behavior. Common examples include usage-based fees, performance bonuses, volume discounts, rebates, refunds, penalties, and price concessions. The full definition appears in ASC 606-10-32-5 through 32-9. Not all variable consideration is recognized immediately; the constraint test determines how much can be included in the transaction price.

What is the constraint on variable consideration?

The constraint (ASC 606-10-32-11) says variable consideration can only be included in the transaction price to the extent it is *probable* that doing so will not result in a *significant* reversal of cumulative revenue when the uncertainty resolves. Both prongs must be satisfied. “Probable” is the likelihood threshold; “significant” is the magnitude threshold. A reversal that is likely but small may pass. A reversal that is unlikely but would be material to earnings may not. Significance is evaluated in context, relative to contracts of similar size, debt covenants, and investor guidance, not just as a percentage of total revenue.

What are the two methods for estimating variable consideration?

ASC 606 allows two estimation methods. The *expected value* method takes the probability-weighted sum of all possible outcomes and works best when there is a range of possible amounts, which is typical for usage-based contracts. The *most likely amount* method selects the single most probable outcome and works best when there are effectively only two outcomes, such as a binary performance bonus. Companies must use whichever method better predicts the entitled amount, apply it consistently within a contract, and document the basis at inception.

How often must variable consideration be re-estimated?

At every reporting period. Under ASC 606-10-32-14, the transaction price including constrained variable amounts, must be updated to reflect new information available at the reporting date. This involves two sequential steps: first, updating the estimate using current data (revised expected value or most likely amount); second, re-applying the constraint to the new estimate. The catch-up adjustment flows through current-period revenue. Documentation of what changed and why is required and will be reviewed in an audit.

Does the constraint mean no variable revenue can be recognized until uncertainty resolves?

No. The constraint is not an all-or-nothing rule. It permits recognition of variable amounts where you can support the probable-no-significant-reversal standard and excludes only the portion where that test fails. A company with three years of usage data on similar customer profiles can typically support a constrained estimate well above zero. A company in its first year of a new pricing model with no comparable data has a weaker basis. The constraint requires judgment calibrated to your actual data — not automatic deferral.

What is the usage-based royalty exception under ASC 606?

ASC 606-10-55-65 provides an exception for sales- or usage-based royalties on licenses of *intellectual property*. For these arrangements, a company does not estimate and constrain at contract inception. Instead, it recognizes revenue only when subsequent sale or usage occurs. The exception is narrow: it applies specifically to IP licenses, not to all usage-based pricing. A SaaS contract that grants a software license may qualify; a services contract billed at a per-usage rate generally does not. Confirm with your auditor whether the exception applies before building your recognition methodology.

What makes a revenue reversal “significant” for constraint purposes?

Significance is not defined by a percentage threshold in ASC 606. It is a judgment that considers the magnitude of the potential reversal relative to circumstances — the size of the contract, the company’s financial position, applicable debt covenants, and any metrics central to investor guidance. A 4% reversal might be insignificant in isolation and highly significant if it moves a reported quarter from profitable to breakeven or triggers a covenant breach. This is why the constraint analysis should be documented with specific reference to these contextual factors, not just with a generic probability statement.

For the full revenue recognition framework, see the Enterprise Revenue Recognition Guide. For the mechanics of how contract modifications interact with variable consideration estimates, see Contract Modifications and Revenue Recognition.