> [!FOUNDER]
> "Every SaaS founder has lived the same board-meeting moment: cash in the bank says the quarter was great, the accountant says most of it is not revenue yet, and both are right. Cash is a fact about the bank. Revenue is a fact about promises kept. ASC 606 exists because founders kept confusing the two, and investors kept paying for the confusion." — Enow A. Jovial, Founder & Chief Executive Officer
The core principle, before the five steps
FASB issued ASC 606 through ASU 2014-09 in May 2014, jointly with the IASB's IFRS 15, replacing a patchwork of industry-specific revenue rules with one principle-based model. The core principle is that an entity recognizes revenue to depict the transfer of promised goods or services to customers in an amount that reflects the consideration to which the entity expects to be entitled in exchange for those goods or services. Two words do the work: transfer and expects. Revenue follows the transfer of control, not the invoice date, and it is measured at expected entitlement, not at the largest number in the order form.
The standard applies to contracts with customers, with scope exceptions that matter for a SaaS company reading its own chart of accounts: lease contracts, insurance contracts, and financial instruments sit outside Topic 606, as do guarantees and certain nonmonetary exchanges. A SaaS subscription, an implementation project, a support plan, and a usage-based overage are all squarely inside it.
> [!KEY TAKEAWAY]
> Book revenue when a promise is satisfied, in the amount allocated to that promise. Everything else — the invoice, the cash, the signed order form — is evidence about the contract, not revenue itself.
Step 1: identify the contract
A contract exists when five conditions are met: both parties have approved it, in writing, orally, or through customary business practice, and are committed to their obligations; each party's rights regarding the goods or services can be identified; the payment terms can be identified; the contract has commercial substance, meaning it will change the risk, timing, or amount of the entity's future cash flows; and it is probable the entity will collect the consideration to which it will be entitled. The last condition is the one SaaS companies most often skip: a signed order form from a customer with no ability or intent to pay is not a contract for ASC 606 purposes, however good it looks in the CRM.
Contract combination and modification rules sit in the same step. Two contracts entered into at or near the same time with the same customer are combined when they were negotiated as a package with a single commercial objective, when the price of one depends on the other, or when the goods or services are a single performance obligation. A mid-term upgrade, a scope expansion, or a price change is a modification, accounted for prospectively, cumulatively, or as a separate contract depending on whether the added services are distinct and priced at standalone selling price. Our editorial analysis is blunt here: most SaaS revenue errors are modification errors, because sales treats an amendment as a new deal while accounting must treat it as a change to an old one.
Step 2: identify the performance obligations
A performance obligation is a promise to transfer a distinct good or service. Distinct has two tests, and both must pass: the customer can benefit from the good or service on its own, or together with readily available resources; and the promise is separately identifiable from other promises in the contract, meaning it is not significantly integrated with, interdependent on, or interrelated with them.
Apply that to a typical SaaS bundle:
| Bundle element | Distinct? | Reasoning |
| :--- | :--- | :--- |
| 12-month hosted subscription | Yes | Customer benefits from access alone; it is the core promise |
| Implementation that configures the customer's own workflows | Often yes, if usable without further custom work | Benefit is standalone once delivered |
| Deep customisation that rewrites the product for one customer | Often no | The customisation and the subscription are interdependent; the combined output is the promise |
| Onboarding and data migration that only enables access | Often no | A setup activity, not a transferred service; the fee joins the subscription price |
| Premium support with its own SLA | Yes | Separately identifiable, with its own benefit and price |
| Usage overage | Variable consideration on the subscription, not a separate obligation | Same service, more of it |
| Authority | ASC 606-10-25, distinct criteria | IFRS 15 carries the identical distinct test |
The implementation row is where money moves. Call a genuine implementation "setup" and its fee gets spread over the subscription term; call mere setup "implementation" and revenue is pulled forward into month one. Auditors test this distinction against the statement of work, not the invoice label, so the statement of work should describe what is actually delivered, in deliverable terms, before the contract is signed.
Step 3: determine the transaction price
The transaction price is the amount of consideration the entity expects to be entitled to in exchange for transferring the promised goods or services. It includes fixed amounts, variable amounts, noncash consideration, and consideration payable to the customer, adjusted for the time value of money where a significant financing component exists — a one-year prepayment at a normal commercial rate is generally not a financing component, but a multi-year prepayment with a steep discount can be.
Variable consideration is the SaaS trap. Usage overage, performance bonuses, SLA credits, and volume rebates are all variable. The entity estimates variable consideration by expected value or most likely amount, whichever better predicts the outcome, and then applies the constraint: include variable consideration only to the extent it is probable that a significant reversal in cumulative revenue recognized will not occur when the uncertainty is resolved. An SLA credit that history says will be claimed 20% of the time is not a rounding difference; it is a reduction of the transaction price from day one.
Step 4: allocate by relative standalone selling price
For a contract with more than one performance obligation, the transaction price is allocated to each obligation in an amount that depicts the consideration the entity expects to be entitled to for satisfying it. The allocation basis is relative standalone selling price (SSP): what the entity would charge if it sold that good or service separately.
$
ext{Allocated to Obligation} = rac{ ext{SSP of Obligation}}{ ext{Total SSP of All Obligations}} imes ext{Transaction Price}
$
Worked example. A customer signs a $250,000 contract: a 12-month subscription with an SSP of $240,000 and an implementation with an SSP of $30,000. Total SSP is $270,000, so the $20,000 discount is spread proportionally:
$
ext{Subscription Allocation} = rac{$240{,}000}{$270{,}000} imes $250{,}000 = $222{,}222.22
$
$
ext{Implementation Allocation} = rac{$30{,}000}{$270{,}000} imes $250{,}000 = $27{,}777.78
$
$
ext{Monthly Subscription Revenue} = rac{$222{,}222.22}{12} = $18{,}518.52
$
If the customer pays the full $250,000 upfront and implementation is delivered in month one, month-one revenue is $27,777.78 plus one month of subscription, $18,518.52, for $46,296.30 — and the remaining contract liability is $203,703.70, recognized at $18,518.52 per month for the remaining eleven months. A company that books $250,000 in month one overstates that month by $203,703.70 and understates the next eleven months by $18,518.52 each. That is not a presentation choice; it is the schedule the standard produces.
Estimating SSP is itself a discipline. Observable prices come first: the price charged to similar customers in similar circumstances. Where the service is never sold alone, the entity estimates SSP by an adjusted-market approach, an expected-cost-plus-margin approach, or, only where prices are highly variable, a residual approach. Whatever method is chosen, it must be documented, applied consistently, and revisited when pricing changes — because an SSP schedule that still reflects last year's price list misallocates this year's bundles.
Step 5: recognize as each obligation is satisfied
An entity recognizes revenue when or as it satisfies a performance obligation by transferring control of the promised good or service. Satisfaction is over time when one of three conditions holds: the customer simultaneously receives and consumes the benefits as the entity performs; the entity's performance creates or enhances an asset the customer controls; or the entity's performance does not create an asset with an alternative use and the entity has an enforceable right to payment for performance completed to date. A hosted subscription meets the first condition plainly — the customer consumes access day by day — so it is recognized ratably over the term. If none of the three conditions holds, recognition is at a point in time, when control transfers: delivery, acceptance, or the customer's ability to direct the use of and obtain substantially all remaining benefits from the asset.
Contract balances follow mechanically from the schedule. A contract liability is an obligation to transfer goods or services for which consideration has been received or is due — the deferred-revenue balance every SaaS board deck already shows. The deferred revenue SaaS balance-sheet playbook runs the full waterfall, the section 451(c) tax election, and the churn math on that balance. A contract asset is a right to consideration for goods or services already transferred, conditional on something other than the passage of time, such as a milestone. A receivable is an unconditional right to consideration, conditional only on time passing. Keeping those three labels distinct is what makes the balance sheet reconcile to the revenue schedule instead of merely resembling it.
The decision table: billing events vs revenue events
| Event | Cash? | Revenue? | Balance-sheet effect | Authority |
| :--- | :--- | :--- | :--- | :--- |
| Annual invoice issued, unpaid | No | No | Receivable and contract liability, if invoicing precedes satisfaction | ASC 606-10-25, contract balances |
| Annual payment received upfront | Yes | Only the satisfied slice | Contract liability for the unsatisfied balance | ASC 606-10-45 |
| Month of subscription consumed | No | Yes, one month's allocation | Contract liability decreases | ASC 606-10-25, over time |
| Implementation accepted | Depends on billing | Yes, full allocated amount at the point in time | Contract liability or receivable moves accordingly | ASC 606-10-25, point in time |
| Usage overage, constrained estimate | No, until billed | Yes, constrained amount | Contract asset or receivable as billed | ASC 606-10-32, variable consideration constraint |
| SLA credit claimed | Refund or credit | Reduction of transaction price | Cumulative catch-up adjustment | ASC 606-10-32, changes in transaction price |
Changes in estimate are cumulative catch-ups, not restatements of history: when the transaction price changes, the entity adjusts cumulative revenue in the period of change, as if the new price had applied from the start, and discloses the effect. A company that revises its overage estimate every month without a documented constraint methodology will produce a revenue line that wobbles for reasons no investor can follow.
> [!WARNING]
> The two findings that draw auditor attention fastest are a discount assigned entirely to the subscription so implementation revenue looks larger, and an onboarding fee recognized upfront although the onboarding transfers nothing distinct. Both accelerate revenue into the signing month, both reverse in later months, and both are visible in a single allocation schedule. If the schedule cannot be produced, the revenue number cannot be defended.
Who this is for, and who should not shortcut it
This model fits any SaaS company with bundled contracts, annual prepayments, implementation, or usage pricing — which is to say, nearly every B2B SaaS company past its first ten customers. It fits finance teams building a revenue schedule before the audit, not during it, and founders who want a board metric — recognized revenue, deferred revenue, and remaining performance obligations — that ties to cash without confusing the two.
It does not fit a company that wants revenue to track billings for simplicity. Billings are a sales metric; recognized revenue is the accounting answer, and the gap between them is the deferred-revenue balance, which is also the clearest single indicator of future revenue already sold. A company that refuses the schedule is not simplifying; it is discarding its best forward indicator.
> [!TIP]
> Build the schedule before the contract template, not after the first audit finding. One spreadsheet per contract type, with columns for each performance obligation, its SSP, its allocation, and its recognition pattern, turns every new deal into a row instead of a judgment call. When the auditor asks how revenue was determined, the answer is the schedule, and the schedule is the same document sales, finance, and the board already use.
Execution checklist
Related reading on this site: the cash vs accrual accounting guide, which sets the accounting basis ASC 606 operates on; the master chart of accounts for SaaS and agencies, for the accounts the schedule posts into; and the Section 174 software capitalization guide, because the same engineering payroll that builds the product is capitalised for tax under a different rulebook. Recognised revenue is still not cash until the receivable clears: see the cash conversion cycle and DSO reduction playbook for the DIO, DSO, and DPO math that turns a revenue schedule into a cash schedule. To model a bundle before signing it, run the price points through the pricing calculator and the invoice terms through the invoice generator.