How to Do Revenue Recognition (Without Losing Your Mind): A CPA’s Field Guide for SaaS, Construction & Everything In Between

Last Updated on November 12, 2025 by Ewen Finser

I don’t know why, but tons of business owners, bank officers, investors, and other people who should know better simply don’t understand revenue recognition. It’s something that drives me up the wall as a CPA, because it can easily cause financials to be materially misstated. So today, let’s clear the air and see what tools can help us prevent from making these mistakes that can sink your business before you have an inkling that something is wrong.

Revenue recognition isn’t “when cash hits the bank.” It also isn’t when you send the client the invoice “because they’re okay with being billed on the 30th.”  

Revenue can be recognized when “control transfers or performance is satisfied,” and the devil is in the details. And trust me, there are plenty of details as we can’t forget about things like contract mods, variable consideration, data lineage, etc. If you nail your policies, your data model, and your workflows, you’ll get clean revenue, clean audits, and clean dashboards. I

f you don’t, you’ll be making critical decisions based off garbage information. Luckily, there are accounting platforms like Puzzle.io the help reduce these mistakes by automating the parts humans chronically mess up: schedules, allocations, usage metering, contract modifications, and disclosures.

The Bottom Line Up Front

Revenue recognition isn’t “when cash lands”, it’s “when control transfers,” and the five-step ASC 606 model only works if you nail POBs, variable consideration, and contract mods across messy realities like SaaS bundles and construction cost-to-complete. Encode those rules in your workflow and a revenue subledger to automate SSP allocations, usage/milestone schedules, and disclosures so close is clean, repeatable, and audit-proof.

The Five-Step Model: What Actually Matters

Step 1: Identify the Contract(s).

You need approved terms, commercial substance, and collectability that’s probable. Watch out for master agreements with rolling order forms, and bundled SOWs that look separate but aren’t.

Step 2: Identify Performance Obligations (This is When you get to Bill!).

This is where folks get in trouble. A “POB” is a distinct good or service that can be conveyed. In SaaS, common performance obligations includes access to the subscription itself, an implementation service (often distinct in the contract), training, and sometimes a term license with post-contract support. On the other hand, in construction for example, a single contract can be a single POB satisfied over time, but complex scopes, options, and significant customization can create multiple POBs.

Step 3: Determine the Transaction Price (TP).

 Include fixed fees plus variable considerations (things that can change the dollars like you receive like the amount of users, credits, rebates, discounts, etc). Constrain revenue if there’s significant reversal risk.

Step 4: Allocate Transaction Prices to Performance Obligations

Allocate based on stand-alone selling price (SSP). If you don’t have observable pricing, you can estimate on things like adjusted market assessment, expected cost plus margin, or a residual approach (in limited cases). This is core for SaaS bundles and hardware-plus-service deals.

Step 5: Recognize Revenue When/as you Satisfy POBs.

Over time if the customer controls the asset as it’s created, benefits as you perform, or if there’s no alternative use and you have an enforceable right to payment, you should record the revenue. Otherwise, bill in a point in time, based on an output method (milestones, units delivered) or input method (cost-to-complete, hours) that faithfully depicts transfer of control.

The Boring Stuff That Blows Up Financials

• Contract modifications: Are they separate contracts (distinct scope + price at standalone) or combined? Construction lives here; SaaS renewals with scope change do too.
• Variable consideration constraints: Over-recognition here is how you end up with an overbilling liability on your balance sheet. Constrain refunds/credits/SLAs until reversal is unlikely.
• Non-refundable upfront fees: In my experience, these are usually not revenue upon receipt, as they’re often deferred and recognized over time, unless they convey a separate POB.
• Costs to obtain a contract (ASC 340-40): Capitalize incremental costs (e.g., sales commissions tied to obtaining the contract) and amortize over the benefit period, which may exceed the initial term if renewals are expected without commissions.
• Material rights: Discounts on renewals/options below standalone sell price may create a separate performance obligation.

A Clean, Reusable Policy Stack You Can Actually Operate

1. Scoping memo: Which revenue streams need special attention? Is it based on contract archetypes? Who owns documentation?
2. Performance obligation catalog: Enumerate each POB per product line with recognition method, measure of progress, and the typical stand alone selling price.
3. Pricing/Discount governance: How SSP (stand alone sells price going forward) is derived, updated cadence, and documentation expectations. This way, you can understand what costs are baked into your delivered SSP and can recognize revenue overtime as you put your costs into delivering the product or service.
4. Variable-consideration rules: What’s estimated vs what revenue is constrained; what evidence is needed to release constraints.
5. Close checklist: Waterfall tie-outs, deferral roll-forward, contract-liability roll-forward, disclosure packages are all things that need to be examined monthly to ensure nothing is overlooked MoM.

Where Puzzle leans in: Puzzle isn’t like traditional accounting platforms. It was made with revenue recognition automation in mind, so I’m going to focus on it as a platform for today since we’re discussing a complex and technical accounting topic.

Puzzle sits as a finance-grade subledger that ingests data from bank feeds and platforms like Stripe, builds revenue schedules, and tracks alongside waterfalls and deferred revenue rollforwards without spreadsheet acrobatics. You get immutable audit trails, contract-mod handling, and a tight link from operational events to GL entries.

SaaS: The Greatest Hits (And Misses)

Common POBs:

• Subscription access: Is it over time, straight-line or ratable over service period?
• Implementation/Onboarding: Is it distinct? This is often recognized over service period if it doesn’t transfer a discrete good; otherwise point-in-time when delivered.
• Training: This one is usually pretty easy, it’s a point in time, and distinct.
• Term license + Post Contract Support license may be point-in-time if right-to-use; PCS is usually recognized over time.
• Usage-based fees: Typically recognized as the usage occurs; estimate future usage only if highly predictable and low reversal risk

How to Treat Discounts & Bundles:

Allocate a portion of the bundle price to each performance obligation based on their standalone sell prices. If you gave a “free” implementation to land the deal, it still gets in allocation, lowering subscription revenue recognized each period.

How to Treat Upfront Fees:

Most onboarding fees are not a separate POB; they’re setup activities. Defer and recognize them over the related service period.

How to Treat Variable Consideration:

• Usage: Recognize revenue as incurred, but base it off consistently available and measurable metrics.
• Credits/SLAs: Constrain until the service fails and credit becomes probable.
• Refunds: Hold a refund liability where appropriate.

Commissions (These Are Tricky!)

Capitalize new commissions and amortize over expected customer life if renewals don’t pay a commensurate commission. Renewal commissions often amortize over the renewal term only.

Construction & Long-Term Projects: Over-Time Recognition With Real-World Mess

Construction typically recognizes revenue over time under the input method (cost-to-complete) when the customer controls the asset as it’s created or there’s no alternative use plus enforceable right to payment.

Key Mechanics

• Measure of progress: Percentage-of-completion = Incurred costs / Total estimated costs.
• Cumulative revenue: % complete × contract price.
• Contract assets/liabilities: If revenue recognized exceeds billings, you should record an asset on the balance sheet as an underbilling. If billings > revenue recognized, you’ll record a liability on your balance sheet.

Change Orders (Mods):

• If added goods/services are distinct and priced at SSP, treat as a separate contract and record.
• Otherwise, treat as a modification of the existing contract, often with a cumulative catch-up to revenue if the total expected consideration changes.

Variable consideration: Claims, incentives, liquidated damages. Estimate using expected value or most likely amount, then constrain.

How Puzzle.io helps: In my opinion, Puzzle is much more equipped to handle revenue recognition for software as a service companies that need to implement workflows through Stripe. However, the close checklist that is baked right into Puzzle can help with ensuring all month end contracts for construction projects are reviewed, and that nothing is missed, for example.  

Professional Services & Milestones

If services are stand-ready or a series of distinct days that are substantially the same, recognize over time on a time-elapsed basis. If delivery is milestone-based and output is best depicted by hitting those gates, recognize on completion of each milestone (be cautious about front-loading).

Common Pitfalls:

• Treating non-cancellable retainers as revenue on receipt (they’re usually contract liabilities).
• Not constraining milestone bonuses tied to client acceptance.

E-Commerce, Marketplaces & Hardware + Service

• Returns: Create a refund liability and an asset for the right to recover products.
• Hardware + subscription: Separate POBs with stand alone sales price allocation. Hardware typically point-in-time (usually when delivered); subscription over time.
• Warranties: Assurance-type (cost accrual) vs service-type (separate POB).

Variable Consideration: Estimation Without Fantasy

Disclosures: What Your Auditors Will Ask For

• Disaggregation of revenue by type, geography, timing. They want to see where all of your revenue is stemming from, that way they can sift through what’s revenue, and what’s actually a liability.
• Contract balances (opening/closing) and roll-forwards of deferred revenue, contract assets/liabilities.
• Unsatisfied performance obligations and expected timing.
• Significant judgments: what are your revenue recognition methods, inputs, constraints, and SSP approach.

A revenue subledger like Puzzle can help manage these all in one place as worksheets can be tied to journal entries for things like waterfalls, aging of contract liabilities, and backlog timing.

Industry Playbooks for Recognizing Revenue (Where All This Jargon Starts To Make Sense)

SaaS Checklist

• What are my POBs that will allow me to recognize revenue: subscriptions, implementation, training, term license, PCS.
• How to recognize: ratable for subscription; point-in-time vs over-time for licenses/PCS.
• Variables: usage, service agreements, refunds and what do I need to constrain.
• Commissions: capitalize and amortize over customer life if applicable.
• Mods: expansions, downgrades, mid-term price changes, handle with separate vs combined logic.

Construction Checklist

• Contract clearly defines: enforceable rights, qhat the POBS are, and right to payment on a defined schedule.
• Input method: (cost-to-complete) with robust forecast discipline.
• Mods/change orders: documented; cumulative catch-ups booked timely.
• Claims/LDs: estimated and constrained.
• Work in Progress: ties to GL; contract assets/liabilities reconciled.

Professional Services Checklist

• Series guidance: for recurring services; time-elapsed recognition.
• Milestones: only if they faithfully depict progress.
• Material rights from discounted contracted extensions.

How To Deploy This In Reality (It’s Complicated, But It Doesn’t Have to Be)

1. Inventory revenue streams and write a one-page policy per stream that outlines where it’s coming from, costs that are associated with it, what add ons can be associated with it, etc.
2. Define POB catalog and the Stand Alone Sells Price table with documentation of method and ranges.
3. Digitize your logic (decision tree) so no one freelances in spreadsheets.
4. Stand up a revenue subledger (this is where Puzzle.io earns its keep). Connect CRM, billing, product usage, your GL, and platforms like Stripe.
5. Backfill open contracts and generate day-one schedules and roll-forwards.
6. Lock your close sequence: reconciliations, approvals, and disclosure exports.

Final Word (From a CPA Who’s Cleaned Up Too Many Schedules)

Revenue recognition isn’t about being conservative or aggressive. It’s about telling the truth systematically. 

Does what’s occurring in the business operations actually match what is in the financials? 

The ASC 606 Standard gives you the rules for revenue recognition; it’s your job to encode it in policies and systems that scale with messy real life: discounts, usage spikes, scope creep, and cash timing curves. Do that, and your revenue story stops changing every meeting.

If you’re still copy-pasting schedules and praying your allocation tabs don’t break, that’s your sign to move the logic into a subledger built for this era. Puzzle.io is one of the few tools I’ve seen that treats revenue like a first-class workflow  for things like allocations, mods, variable consideration, commissions, and disclosures, so finance can finally get out of the spreadsheet mines and into decision support where we belong.