Master ASC 606 variable consideration. Guide covers estimation, constraints, & SaaS & agency examples for compliance & investor financials.
A lot of founders think the risky part of ASC 606 is choosing an estimate. It isn't. The dangerous part is booking that estimate as revenue before you've proven it won't reverse.
That's not a niche issue. A 2025 analysis of SaaS contracts found that 34% of revenue errors came from missing the re-constraint step after an upward re-estimate, while fewer than 12% of popular ASC 606 blog posts explained that two-step update process (BillingPlatform analysis). If you run SaaS, an agency, or a professional services firm with bonuses, rebates, credits, or usage billing, that gap can hit your board deck, your audit file, and your valuation story fast.
Variable consideration is the part of your contract price that isn't fixed on day one. It includes things like usage fees, performance bonuses, discounts, rebates, refunds, and credits. If you report revenue before handling that uncertainty correctly, your numbers stop being decision-grade. Investors lose trust. Auditors push back. Your close gets slower right when you need it faster.
If your reported revenue changes every time your controller revisits a contract, the problem usually isn't forecasting discipline alone. It's contract structure.
Many growing businesses sell work that has a fixed base price plus an uncertain layer. SaaS companies bill overages and usage. Agencies earn bonuses for hitting lead or performance targets. Professional services firms issue credits, discounts, or fee adjustments after delivery. That uncertain layer is variable consideration, and under ASC 606 you have to estimate it and account for it correctly from the start.
The business impact is immediate. Revenue that looks solid in your CRM can fail in your financial statements because accounting asks a different question. Not “What do you hope to bill?” but “What amount are you entitled to recognize without creating a significant reversal later?”
Three patterns show up over and over:
Practical rule: If a customer's final bill depends on something that hasn't happened yet, you need to stop treating that amount as clean revenue.
For founders, the takeaway is simple. Revenue quality matters as much as revenue growth. If your variable elements aren't identified and assessed upfront, your P&L won't stand up when an investor, lender, or auditor asks how you got the number.
A contract has variable consideration when part of the price can change after signing. That change can move up or down. The classic examples are performance bonuses, rebates, discounts, credits, refunds, and usage-based fees.
For non-accountants, the fastest test is this: if you can't point to one fixed amount that you're unquestionably entitled to on day one, you probably have variable consideration.

Under ASC 606, variable consideration is estimated using two distinct methods: the expected value method, which calculates a weighted average of all possible amounts, and the most likely amount method, which is appropriate when a contract has only two possible outcomes. The standard requires entities to select the method that best predicts the amount they are entitled to (HubiFi explanation of variable consideration under ASC 606).
That means this isn't a preference call. You don't pick the method that makes the revenue line smoother. You pick the method that fits the contract economics.
Here's the practical framing:
| Contract pattern | What it looks like in the real world | Better fit |
|---|---|---|
| Many possible outcomes | SaaS overages, tiered usage, variable credits across a portfolio | Expected value |
| One clear upside or downside | Agency bonus earned or not earned, single milestone payment | Most likely amount |
If you're still sorting out revenue labels across different reporting contexts, this expert guide on revenue and turnover is useful because it separates commercial language from accounting treatment.
The expected value method works best when you have several plausible outcomes and enough history to assign reasonable weights.
Example with worked numbers:
A SaaS company sells a contract with fixed platform access plus uncertain monthly overages. It expects one of three usage outcomes for the month:
| Possible overage revenue | Probability |
|---|---|
| 100 | 25% |
| 200 | 50% |
| 300 | 25% |
Expected value calculation:
Estimated variable consideration = 200
The most likely amount method works when the contract really has a yes-or-no structure.
Example with worked numbers:
A digital agency earns a 1,000 bonus if it delivers a defined lead target by quarter-end. There are two outcomes:
If the single most likely outcome is that the target will be achieved, the estimate under this method is 1,000 before you deal with the separate constraint analysis covered next.
For businesses with refunds, returns, or price adjustments, many operators lose track of revenue leakage. A tighter process for returns and allowances in accounting usually surfaces variable elements that were buried in billing workflows.
Most finance mistakes around variable consideration happen after the estimate, not before it.
You can build a perfectly reasonable model and still overstate revenue if you skip the next test. ASC 606 doesn't let you recognize variable consideration just because you estimated it. You may include it in the transaction price only to the extent that it is probable a significant reversal of cumulative revenue won't occur.
Start with the decision flow founders need to understand:

Under ASC 606, an entity may only include variable consideration in the transaction price to the extent that it is probable that a significant reversal of cumulative revenue will not occur. One practitioner summary notes that GAAP generally frames probable around 70% to 80% likelihood, and flags higher reversal risk when the amount is highly susceptible to external factors or when the company has limited historical experience (KatzAbosch overview of ASC 606 and variable consideration).
That's the part many founders underestimate. Your sales team can be confident. Your customer can be enthusiastic. None of that overrides the reversal test.
A useful analogy is deferred revenue. If you've already accepted that cash received early doesn't automatically equal earned revenue, the same logic applies here. Uncertain upside also doesn't automatically equal earned revenue. This explainer on what deferred revenue means in practice is the same discipline in a different wrapper.
Conservative revenue recognition doesn't make your business look weaker. It makes your numbers believable.
A short walk-through helps. Say your contract includes a 15% discount if annual spend exceeds 100K. If your history shows only 65% of customers hit that threshold, that amount likely fails the probable test and should be excluded from recognized revenue until the uncertainty reduces, based on the KatzAbosch example above.
Here's the video version if your team learns better visually:
Ask these questions at close:
Founders often object here. They say, “But we expect to earn it.” That misses the accounting question. ASC 606 asks whether you can recognize it now without creating a meaningful unwind later. That's a much stricter test.
At this stage, teams either operationalize ASC 606 or keep debating it in circles. You need calculations your bookkeeper, controller, and CFO can run every month.
Usage-based fees are explicitly classified as variable consideration under ASC 606, which means finance teams need to estimate, constrain, and true-up revenue each period for contracts like Snowflake credits or Twilio SMS where the final bill isn't known on day one (Lago guide to usage-based revenue recognition).
Assume a customer pays a fixed monthly platform fee of 1,000 plus variable overages based on product usage. Based on current contract activity, you estimate three possible overage outcomes:
| Overage outcome | Probability | Weighted amount |
|---|---|---|
| 100 | 25% | 25 |
| 200 | 50% | 100 |
| 300 | 25% | 75 |
Expected value estimate = 200
If your supportable conclusion is that recognizing 200 won't create a significant reversal, total revenue for the month is:
Sample entry at month-end:
| Account | Debit | Credit |
|---|---|---|
| Accounts Receivable or Unbilled Receivable | 1,200 | |
| Revenue | 1,200 |
If actual overages later settle at 300, you don't restate old months casually. You record the cumulative catch-up through the current period.
Additional true-up entry:
| Account | Debit | Credit |
|---|---|---|
| Accounts Receivable or Unbilled Receivable | 100 | |
| Revenue | 100 |
Assume your agency contract pays a fixed monthly retainer of 5,000 and a 1,000 bonus if the client's qualified lead target is reached by quarter-end. There are only two outcomes, so the most likely amount method fits cleanly.
Scenario A. You conclude the bonus is the most likely outcome and also passes the no-significant-reversal test.
Revenue recognized for the period tied to the service delivered:
Entry:
| Account | Debit | Credit |
|---|---|---|
| Accounts Receivable or Contract Asset | 6,000 | |
| Revenue | 6,000 |
Scenario B. The bonus is the most likely outcome, but the evidence still isn't strong enough to pass the constraint.
Then you recognize only the fixed portion:
That's the distinction founders miss. Estimation and recognition are not the same decision.
Operator's view: If the customer's bonus metric is still moving materially at month-end, book the retainer cleanly and leave the upside out until it clears the constraint.
Even though this article is aimed at SaaS and agencies, the logic matters for any business with post-sale adjustments.
Assume you sell goods and record 1,000 of gross sales in a period, but based on your current facts you expect some portion to reverse through refunds or credits. If your supportable estimate of the amount you'll keep is 800, that's the amount to recognize as revenue at that point.
Sample entry structure:
| Account | Debit | Credit |
|---|---|---|
| Accounts Receivable or Cash | 1,000 | |
| Revenue | 800 | |
| Refund Liability or Related Contra Account | 200 |
The exact account names can vary by system and policy, but the logic doesn't. Don't let gross billings masquerade as net earned revenue.
If your team needs a cleaner foundation for posting and reviewing these entries, this walkthrough of double-entry bookkeeping in accounting helps standardize the mechanics.
Variable consideration fails in ordinary monthly closes, not in technical accounting debates. SaaS and agency teams usually know there is an estimate involved. The miss happens because finance stops after the estimate and does not complete the second decision: how much of that estimate is safe to recognize now.

A founder will feel these errors before an auditor writes them up. Revenue comes in high one quarter, gets reversed later, and suddenly the board is asking why forecasting, billing, and GAAP revenue do not line up. Investors treat that as a finance control issue, not a harmless timing difference.
Use a simple red-flag test. If your memo explains how you estimated the variable amount but does not explain why that amount is recognizable this period without a significant reversal, the memo is incomplete.
This is the point many non-accountant guides miss, and it matters. If you revise variable consideration upward, you do not get to carry forward the old constraint conclusion automatically. You must test the higher amount again.
That matters most in SaaS and agency models because upside often arrives in steps. A customer exceeds usage in month two. A campaign bonus looks likely in the last week of the month. An expansion discussion feels close. Finance updates the estimate, books the increase, and forgets to ask whether the new total is still supportable under ASC 606.
That is where avoidable reversals start.
As noted earlier, one industry analysis highlighted how often teams miss this re-constraint step after increasing an estimate. The practical takeaway is simple: every upward revision needs a fresh constraint assessment. If your policy only says "update the estimate monthly," it is not enough. The policy also needs to say "re-apply the constraint to every upward change before recognizing more revenue."
For a broader baseline on the rule set, this ASC 606 revenue recognition overview for founders and operators is a useful reference. If someone on your team still needs the plain-English foundation, send them this no-nonsense revenue recognition guide.
Common objections sound reasonable. They still fail in review.
| Objection | Why it fails |
|---|---|
| “The customer always expands later.” | Past patterns help your estimate, but they do not eliminate the current-period reversal risk. |
| “We already applied the constraint last month.” | A new estimate means a new recognition decision. |
| “Sales is confident the bonus will hit.” | Sales confidence is not evidence you can defend in the close file. |
| “We can true it up next quarter.” | That approach puts avoidable reversals into reported results and raises questions from lenders, investors, and auditors. |
The clean operating standard is boring on purpose. Estimate the variable amount. Apply the constraint to that amount. Revisit both at each close. If the estimate goes up, run the constraint again before revenue goes up with it.
Get this wrong and your revenue gets restated, your board loses confidence, and audit work gets slower and more expensive.
A workable ASC 606 process is not an accounting exercise for later. It is part of the monthly close. For SaaS and agency businesses, the primary failure point is usually not the first estimate. It is the upward revision that gets pushed into revenue without re-applying the constraint. That mistake creates avoidable reversals and raises questions from investors, lenders, and auditors.
List every contract term that can change the final price
Review current SaaS agreements, agency SOWs, order forms, and renewal terms. Flag usage fees, performance bonuses, service credits, rebates, refunds, retroactive discounts, and any clause that can change what you expect to bill or keep.
Set one estimation method for each contract family
Use expected value when you have a portfolio with several possible outcomes. Use most likely amount when the result is basically yes or no. Apply the method consistently so your close does not turn into a contract-by-contract debate every month.
Write the constraint memo as a separate decision
The estimate answers what you think will happen. The constraint answers how much of that estimate is safe to recognize now. Keep those steps separate in your file, or reviewers will assume the team blended optimism into revenue.
Re-run the analysis at every close, especially when estimates increase
This is the control many teams miss. If the estimate goes up, re-apply the constraint to the new, higher amount before you record more revenue. “We already constrained it last month” will not hold up in a review once facts have changed.
Book the cumulative catch-up entry and keep clean support
Your entry should tie back to the revised estimate, the updated constraint conclusion, and the approval trail. If someone asks why revenue moved, finance should be able to answer in two minutes with documents, not memory.
If your team needs the broader rule set behind this workflow, this guide to what ASC 606 revenue recognition means for growing businesses is a useful reference. If a newer manager still needs the plain-English foundation, send them this no-nonsense revenue recognition guide.
Start where variable consideration is already creating noise in the close. For many companies, that means usage-based SaaS contracts, agency retainers with performance fees, and customer deals with recurring credits or refund exposure.
Build a short policy memo for each contract family. Then connect that memo to the actual close steps: data pull, estimate update, constraint review, journal entry, and approval. The control to test first is simple. When a forecast increases, does someone explicitly re-apply the constraint before revenue increases too?
If you want outside help implementing the workflow, one option is Jumpstart Partners. The firm provides outsourced controller and bookkeeping support for SaaS, agencies, and other growing businesses, including ASC 606 workflows, month-end close support, and investor-ready reporting.
If your contracts include bonuses, usage fees, discounts, refunds, or credits, your revenue process needs more than a spreadsheet and a gut check. Jumpstart Partners helps growing companies build ASC 606 workflows, close faster, and produce financials that stand up to investor and audit scrutiny.