ASC 606 revenue recognition, explained for small software and services businesses

Why cash in is not revenue earned

A customer pays $12,000 in January for a 12-month subscription. Your bank account says +$12,000; the accounting answer is that you earned $1,000 in January and owe the customer eleven more months of service. The other $11,000 is deferred revenue — a liability, because you still have to deliver it.

ASC 606 is the standard that formalizes this. It matters earlier than most founders expect: lenders, acquirers, and serious investors all restate your numbers this way during diligence, and a board that sees recognition-basis revenue makes better decisions than one watching lumpy cash.

The five steps, without the jargon

• 1. Identify the contract. What did you and the customer actually agree to? A signed order form, an accepted quote, a subscription checkout — anything enforceable.
• 2. Identify the performance obligations. The distinct things you owe: twelve months of software access; a website build; onboarding services. One contract can carry several.
• 3. Determine the transaction price. What you will actually collect — after discounts, credits, and variable pieces.
• 4. Allocate the price across the obligations. If the $12,000 covers software plus a $2,000-value onboarding, each obligation gets its share.
• 5. Recognize revenue as each obligation is satisfied. Ratably each month for the subscription; at completion for the onboarding; by milestone or percentage-of-completion for project work.

The four patterns small companies actually use

Subscription (ratable): recognize evenly across the service period. A $12,000 annual plan is $1,000 a month, no matter when the cash landed. Milestone: project revenue recognized as defined deliverables complete — common for agencies and implementers. Usage: recognized as consumed — metered APIs, per-transaction pricing. Percentage-of-completion: long projects recognized by the share of work done, common in construction-adjacent services.

What this looks like operationally

In practice you need three artifacts: a recognition schedule per contract (what gets recognized in which month), a deferred revenue balance that ties to the ledger, and journal entries that move deferred to recognized each period. Growing teams usually start in a spreadsheet, and the spreadsheet usually survives until the first month it silently disagrees with the ledger.

This is a place where tooling genuinely helps: recognition schedules generated from the deal, deferred revenue tracked as a running waterfall, and the monthly journal entries produced automatically into QuickBooks. Tormano ships this natively — schedules per deal or product, milestone and usage methods, and audit-ready rollforwards — because retrofitting recognition after the fact is far harder than running it from day one.

This guide is general information, not tax, legal, or accounting advice. Rules change and situations differ — confirm specifics with your CPA or advisor.