There's one question in ASC 606 that determines more about your revenue recognition than almost anything else: does your customer take possession of the software?
Answer yes and you're in license territory, with revenue recognized at a point in time. Answer no and it's SaaS, with revenue recognized over time. Same product, same price, completely different financial statements.
This isn't academic. Getting the SaaS vs. software license classification wrong means revenue landing in the wrong periods. Auditors catch it. Investors notice the restatement. And unwinding the mistake across multiple quarters is exactly as painful as it sounds.
We dug through KPMG's Revenue for Software and SaaS handbook, which dedicates entire chapters to this single question, and pulled out what actually matters.
Under ASC 606, software arrangements fall into two categories based on one thing: whether the customer can take possession of the software and run it on their own infrastructure.
The customer gets a copy of the code. They can install it on their own servers, run it in their own environment, and operate it without the vendor's ongoing involvement. Under 606, this is a "right to use" the intellectual property as it exists at the point the license is granted. Revenue is recognized when the customer obtains control, typically at delivery or the start of the license term.
The customer accesses a hosted application over the internet. They never take possession of the underlying software. They can't run it independently. What they're paying for is ongoing access to a service. Revenue is recognized ratably over the subscription period as the customer receives and consumes the benefit.
The distinction isn't about what you call it in your marketing. You can label something a "subscription" all day. If the customer downloads and installs the software, it's a license from an accounting perspective. Form doesn't override substance.
The downstream impact is dramatic. Here's a concrete example:
A $120,000 annual software license
Revenue recognized at the point the customer obtains control. If that's day one, you could book $120,000 of revenue in month one. Big number upfront, nothing after.
The same $120,000 as a SaaS subscription
Revenue recognized ratably: $10,000 per month across twelve months. Smoother curve, but it takes the full year to recognize the same amount.
Same deal. Same customer. Same functionality. Completely different revenue curve. For a company preparing financial statements, whether for investors, auditors, or a potential acquisition, this classification drives the numbers that people see.
When you need to determine whether a deal is SaaS or a license, work through these questions in order:
Do they have the contractual right to download, install, and run it on their own infrastructure, or hire a third party to host it? If the answer is clearly no, it's SaaS. Stop here.
If the software only functions while connected to your servers or requires your continuous operation, the customer doesn't have meaningful control. That points toward SaaS even if they technically have a copy of the code.
Under 606, you ask whether the customer can benefit from the license without your hosting, because they could host it themselves or use a third party. If yes, the license and hosting may be separate performance obligations. If the two are deeply intertwined, it's more likely one combined SaaS obligation.
Multi-tenant SaaS where every customer accesses the same codebase through your servers: no separate license exists. The customer benefits exclusively through your provision of the hosted service.
Consistent answers pointing one direction? Clean classification. Mixed answers? Document your judgment carefully. This is where auditors spend their time.
Clean SaaS and clean licenses are easy. Most modern software deals aren't clean.
"Deploy in our cloud or install on your servers, your choice." Common offering. Complicated accounting. If the customer has the contractual right to take possession and run the software independently, even if they never exercise that right, the arrangement may contain a software license. The accounting follows the rights granted, not the deployment the customer picks.
A three-year term license with annual payments looks like a SaaS subscription from a cash flow perspective. Monthly invoices, annual renewals, predictable revenue. But if the customer downloads and runs the software locally, it's still a license. Revenue recognition could be entirely upfront rather than spread across three years. The payment schedule doesn't change the classification.
Customer contracts for a hosted solution, but the vendor significantly customizes the underlying code for them. Is it SaaS access? Or is it effectively a custom-built software product that happens to be hosted? The answer depends on whether the customization creates something the customer could theoretically take possession of and run independently.
Software embedded in hardware or devices adds another layer. The customer takes possession of the physical product, but do they take possession of the software in a way that gives them the right to use it independently? Often no, which means the software component is part of the overall product obligation, not a separate license.
The pattern across all of these: substance over form. The classification follows the nature of the rights granted, not the deal structure, payment schedule, or marketing terminology.
The SaaS-vs-license classification doesn't just change when revenue hits. It ripples through several other accounting areas:
Performance obligation count. SaaS is typically one obligation (a series of distinct service periods). A license bundled with PCS, implementation, and hosting could be three or four. More obligations means more SSP estimation, more allocation math, and more documentation.
Usage-based fee treatment. Usage fees tied to a software license fall under the sales/usage-based royalty exception: recognized only as usage occurs, never estimated upfront. Usage fees in a pure SaaS arrangement are variable consideration instead, with different rules, different timing, and potential for upfront recognition.
Contract modification accounting. Customer switching from license to SaaS? Two acceptable approaches exist (return approach vs. prospective). KPMG flags this as an area of "diversity in practice." Even the Big Four don't fully agree.
Commission amortization. Sales commissions under ASC 340-40 are amortized consistent with the pattern of transfer. Point-in-time license delivery means a larger portion amortized upfront. Over-time SaaS means straight-line amortization over the service period.
Disclosure requirements. Revenue from licenses and SaaS may need to be disaggregated separately in your financial statement disclosures, depending on the significance of each stream.
Companies that sold on-premise licenses for years are increasingly migrating customers to cloud subscriptions. Customer cancels the license, gives up the right to run locally, starts a SaaS subscription.
The accounting for this is genuinely unresolved. The FASB added it to their technical agenda, studied it, then removed it without issuing guidance. Two approaches exist and both are considered acceptable:
Return approach: Reverse the revenue originally recognized for the license (the customer is giving back those rights), then recognize SaaS revenue going forward.
Prospective approach: Don't reverse anything. Treat it as termination of the old contract and creation of a new one. Allocate remaining consideration forward.
The choice between these materially affects reported revenue. And if you do these conversions repeatedly, the pattern creates "implied rights," meaning you may need to build the conversion option into your accounting for all license contracts from day one, not just the ones that actually convert.
This is not a judgment call to make alone. Get your auditor involved early.
Most billing tools were built for one model. Legacy software billing handles licenses. Modern subscription platforms handle SaaS. Neither handles both, and neither handles the transition between them.
JustPaid was built for how software companies actually sell: SaaS subscriptions, term licenses, usage-based pricing, hybrid arrangements. AI Contract Extraction reads the terms of each deal and identifies the right classification. Revenue schedules generate for both over-time and point-in-time patterns. When a customer converts from license to SaaS, the modification accounting follows automatically.
One platform. Both models. No manual reclassification.
Not sure how your deals should be classified? Schedule a demo to see how JustPaid handles SaaS, licenses, and hybrid arrangements automatically.
Automate invoicing, streamline accounts receivable, and accelerate revenue with JustPaid.
SaaS and software licenses follow completely different revenue recognition rules under ASC 606. Here's how the distinction works and why it matters for your financials.
Usage-based billing creates unique revenue recognition challenges under ASC 606 — variable consideration, royalty exceptions, and the as-invoiced expedient explained.
ASC 606 revenue recognition for SaaS companies — the 5-step model broken down with real examples. Learn when and how to recognize your revenue correctly.
JustPaid and Attio now sync billing data into your CRM in real time — so your team sees payment health, MRR, and churn risk where they already work.
Sending invoices is supposed to be the easy part. But tax accuracy—sales tax, VAT, GST—is creating compliance liability. Here's how the JustPaid and Numeral integration fixes it.
Everyone wants AI agents—but most companies freeze when it's time to let an agent actually act. Why the trust gap isn't a technology problem, and how to get past it.
Stay updated with the latest insights on AI-powered billing automation and financial operations.
Combinator (W23)
