Revenue Recognition (ASC 606)

Your auditor flagged $600K in revenue recognized before the performance obligations were met. The root cause: the old revenue policy was still running in the new billing system, and nobody had checked that the configuration matched the updated accounting standard. ASC 606, Revenue from Contracts with Customers, is the GAAP standard that governs when and how much revenue a company recognizes. Adopted by most public companies in 2018 and private companies by 2019, it replaced decades of industry-specific revenue guidance with a single five-step model that applies across all sectors. The core principle: revenue is recognized when performance obligations to customers are satisfied, in the amount of consideration the company expects to receive. For simple transactions, such as one-time product sales delivered immediately, ASC 606 often gives the same result as the older guidance. For subscription businesses, multi-element arrangements, and contracts with variable consideration, the difference can be material. The $600K finding above is a system misconfiguration: whoever implemented the billing system didn't update the recognition logic for ASC 606 treatment, and nobody caught it until the audit. Fixing it means correcting the system and also restating the periods in which revenue was recognized incorrectly.

How it works

Step 1 is identifying the contract with a customer: establishing that a contract exists, the parties have approved it, rights and payment terms are identifiable, and collection is probable. Most contracts are straightforward, but oral agreements, contracts implied by course of dealing, and contracts with collectability concerns all require Step 1 judgment. Step 2 is identifying performance obligations, the distinct goods or services promised in the contract. A bundled software, implementation, and support contract may have two or three distinct obligations, each recognized on its own schedule. Getting this wrong, by treating the bundle as one obligation when the parts are separate or splitting them when they should be combined, produces incorrect recognition timing. Step 3 is determining the transaction price, including any variable consideration (discounts, rebates, performance bonuses, right of returns). Variable consideration is estimated and included in revenue only to the extent it's highly probable a significant reversal won't occur. Step 4 allocates the transaction price to each performance obligation based on relative standalone selling prices. Step 5 is recognition when (or as) each obligation is satisfied. The risk at Step 5 is deciding whether satisfaction happens over time (ratably, like subscriptions) or at a point in time (like product delivery). Getting the over-time vs point-in-time call wrong is the most common ASC 606 error in technology companies.

Variable consideration, contract modifications

Variable consideration is any part of the contract price that isn't fixed: volume discounts, usage-based fees, performance bonuses, price concessions, and rights of return. Under ASC 606, companies estimate variable consideration using either the expected value method (probability-weighted average) or the most likely amount method, and include that estimate in the transaction price, subject to the constraint that it's highly probable no significant reversal will occur. That takes judgment, documentation, and consistency from one reporting period to the next. Contract modifications (upgrades, downgrades, scope changes) are treated differently under ASC 606 depending on whether the modification is a separate contract or a change to the existing one, and whether the remaining goods or services are distinct from those already delivered. A mid-period upgrade that adds distinct services is accounted for prospectively as a new contract. One that changes the original services may require a cumulative catch-up adjustment. Systems apply policy rules mechanically. If the policy isn't configured correctly, or the system can't handle contract modification accounting, the calculations will be consistently wrong even when the written policy is right. Companies using billing systems that weren't built for ASC 606 often find this gap during audit preparation.

How platforms handle it

Revenue recognition technology follows three broad models. The first is configurable recognition rules in a purpose-built platform (Zuora Revenue, Maxio, Salesforce Revenue Cloud): finance configures performance obligations, standalone selling prices, and recognition triggers, the system calculates schedules and posts entries automatically, and the platform keeps an audit trail from contract through recognition. The second is recognition embedded in an ERP (NetSuite ARM, SAP RAR): the recognition logic lives in the same system as the GL, which reduces integration risk but requires ERP-specific configuration expertise. The third is manual recognition in spreadsheets: finance keeps contract schedules in Excel, calculates monthly recognition by hand, and posts journal entries, which is accurate only when the spreadsheet is complete and correct. For SaaS companies at Series B and above, manual recognition usually isn't sustainable. The number of active contracts, the complexity of multi-element arrangements, and the audit documentation requirements exceed what a spreadsheet process can reliably handle. Configure a proper recognition platform before volume makes the manual process obviously unmanageable, not after the first audit finding.

Six questions to ask before your first ASC 606 audit

• Have we documented the performance obligation structure for each contract type, and has an external accountant or auditor reviewed that documentation for ASC 606 compliance?
• Does our billing or recognition platform allow us to configure standalone selling prices for each performance obligation, and does it automatically recalculate allocation when SSPs change?
• How does our system handle contract modifications (upgrades, downgrades, and cancellations), and can we show that each modification type is accounted for using the correct ASC 606 method?
• For variable consideration, what is our documented policy for estimation methodology, and how does the system capture and consistently apply those estimates?
• Can we produce a complete revenue waterfall (beginning deferred, additions, recognized, and ending deferred) for any period, reconciled to both the billing system and the GL?
• What is the audit trail for a recognition entry? Can we trace any revenue line item back to the specific contract, performance obligation, recognition schedule, and calculation?

Common mistakes

Applying pre-ASC 606 rules after adoption is more common than it should be. The most frequent version is recognizing all revenue at contract signing or invoice date, which was often acceptable under old industry guidance but breaks ASC 606's performance obligation framework for most subscription arrangements. Companies that moved to new billing systems during or after the ASC 606 transition sometimes carried the old recognition logic into the new system without realizing the configuration was non-compliant. The second failure is leaving recognition rules unconfigured in the billing system, so finance does the work by hand. Spreadsheet-based recognition is brittle: it depends on one person's knowledge, breaks as volume grows, and is hard to test and audit. When an auditor asks for the complete population of contracts with active recognition schedules, and evidence that every contract is included and current, a spreadsheet process usually can't provide that assurance. The audit finding then forces a system implementation that would have been cheaper to do properly at the start.

ASC 606 and IFRS 15

ASC 606 is the US GAAP standard issued by the FASB. IFRS 15 is the equivalent issued by the IASB, and the two were developed jointly, so the five-step model is the same in both. Differences remain in a handful of areas, including some licence and collectability guidance, which matters for groups that report under both. Both replaced the older industry-specific rules with one obligation-based model.

Comparing accounting software

The dividing line in this category is whether a tool owns the ledger or sits beside it running reconciliations and the close checklist. Once Revenue Recognition (ASC 606) is settled as a requirement, read the Accounting Software category guide for how the market splits, then weigh the BlackLine profile against the FloQast profile on that requirement rather than on the feature list. Our BlackLine pricing breakdown records what the vendor publishes and what is quote-based. The BlackLine against FloQast comparison sets two of them side by side on the same criteria. Before you book demos, put your own numbers through the accounting software ROI calculator so the business case is written down before a vendor writes it for you.

Revenue Recognition (ASC 606) questions

Related terms

Account Reconciliation, Accrual Accounting, and Audit Trail come up in the same workflow as Revenue Recognition (ASC 606), and the rest of the accounting software cluster is indexed in the finance operations glossary.