By Shawn Elliott, CFO | High Rock Accounting
I get some version of the same call a few times a year, and it usually starts with something like: “Hey Shawn, my revenue is down but my cash is up — what is going on?” And I have to smile a little bit, because I know exactly what happened. Nobody explained deferred revenue to them before they signed their first annual contract, and now their balance sheet looks like it is telling a completely different story than their bank account. So let me try to fix that.
Just to give you some idea of where I am coming from here: I work with SaaS founders at all different stages, from early pre-revenue raises all the way through companies doing $50M+ in ARR, and the deferred revenue question comes up constantly. It does not matter how sharp the founders are or how solid their product is. The accounting around subscription contracts is genuinely counterintuitive if no one has walked you through it. And when investors start asking questions about your balance sheet, you want to have clean answers, not scramble for an explanation.
What Deferred Revenue Actually Is
All right, so here is the core of it. Under ASC 606, which is the revenue recognition standard that governs how SaaS companies book their income, you can only recognize revenue when you have actually delivered the service. *1 That means when a customer pays you upfront for a year of software, you do not get to call that whole amount revenue on day one. You earned the January portion in January, the February portion in February, and so on.
So what happens to that cash you already collected? It sits on your balance sheet as a liability called deferred revenue. Think of it as a promise you still owe. The customer gave you $120,000 in January for a full year, and you have got twelve months of service delivery ahead of you before you have earned all of that. Until you deliver, it is not yours to call revenue.
I walked through this exact scenario with a client recently, and I put it to them this way: imagine someone pays you $120,000 for an annual contract on January 1. In January you recognize $10,000 as revenue and carry $110,000 as deferred. In February you recognize another $10,000 and carry $100,000. And so on, month by month, until the contract is fully earned by December 31. It is mechanistic, but it is also totally logical once you see it laid out. *2
Why Your Balance Sheet Looks Weird
Here is where founders get tripped up. Deferred revenue is classified as a current liability on your balance sheet, which means it lives right alongside accounts payable and accrued expenses. And if you have had a strong sales year and collected a lot of annual contracts upfront, that number can get pretty large. *3
So you look at your balance sheet and you see this giant liability, and your gut says something is wrong. “I have all this cash, how can I have a huge liability?” But deferred revenue is actually a healthy sign. It means customers are paying you upfront, which is good for cash flow, and it means you have contracted revenue you have not yet had to earn. When an investor or an acquirer looks at your books, a growing deferred revenue balance is often read as a positive signal because it represents future revenue that is essentially already locked in.
The confusion usually compounds when founders are also looking at their income statement. They had a phenomenal sales month, collected a ton of cash, and then wonder why revenue looks modest. Cash accounting would have shown a spike. Accrual accounting under ASC 606 smooths it out over the contract term. Both pictures are real, they are just answering different questions.
The ASC 606 Five-Step Framework (Without the Jargon)
I want to give you a practical gut check on this without turning it into an accounting lecture. ASC 606 essentially asks you to work through five questions for every contract you sign. *4
First, you identify the contract with the customer, meaning you have a real agreement with real terms. Second, you identify what you are actually obligated to deliver, which in SaaS is usually ongoing software access and maybe some implementation or support services bundled in. Third, you figure out what the transaction price is, so the total amount you are going to collect. Fourth, you allocate that price across all the distinct performance obligations if there are more than one. And fifth, you recognize revenue as each obligation is satisfied.
For most pure-play SaaS businesses with simple subscription contracts, steps one through four are pretty straightforward and step five is where all the action happens. You are delivering software access over time, so revenue is recognized ratably over the contract term. Month by month, dollar by dollar, as you perform.
Where it gets more interesting is when you layer in things like one-time setup fees, professional services, or prepaid credit models. I have got clients using a credit-based model where you defer revenue until the customer actually burns through their credits, and then you recognize it at the point of usage. That adds complexity but the underlying logic is the same: you recognize when you have delivered, not when you have collected.
What Investors Expect to See
If you are venture-backed or heading toward a fundraise, your investors are going to look at your deferred revenue balance and your revenue recognition policy very carefully. Here is what I tell founders to be ready for.
First, they want to see that you are applying ASC 606 consistently. If you have been recognizing revenue at the time of invoicing instead of over the contract term, and then you try to switch to GAAP-compliant treatment before a raise, you are going to have a rough period where historical revenue gets restated or shifted, and it looks terrible on paper even if the underlying business is strong. I have seen this happen and I will be honest, it is a painful conversation to have with a board. *5
Second, they want a clear deferred revenue roll-forward schedule. This is just a schedule that shows your opening balance, what got recognized in the period, what new contracts added to the balance, and your ending balance. It sounds simple but a lot of early-stage companies do not have this on a silver platter and end up scrambling when someone asks for it. We build these as part of our standard monthly close package for SaaS clients because it is one of the first things a sophisticated investor will request.
Third, if you have multiple revenue streams, they want to see each one clearly segmented. Subscription revenue recognized ratably, usage-based revenue recognized on consumption, professional services recognized on delivery or completion, things of that nature. Lumping it all together and calling it “revenue” is not going to fly when someone is doing serious diligence.
The tools that make this manageable are worth mentioning here. Platforms like Maxio (formerly SaaSOptics and Chargify) or Tabs are built specifically to automate the revenue recognition waterfall for SaaS companies. They pull contract data, apply your recognition policy, and generate the roll-forward schedules automatically. *6 We use those in combination with Xero for the GL and Brex or Ramp for spend management, and the month-end close on deferred revenue becomes a lot more of a sanity check than a manual exercise.
Common Mistakes That Will Cost You Later
I want to be upfront about the mistakes I see most often so you can avoid them.
The first one is recognizing revenue at invoicing instead of over the contract term. It feels intuitive, you billed someone, you earned it, right? But if you ever need GAAP financials for a raise or an audit, you are going to have to restate, and that shifts revenue between periods in ways that look alarming at first glance. It is much easier to do it right from the beginning.
The second one is not separating the performance obligations in a bundled contract. If you sell a subscription plus a one-time onboarding service as a single contract, you need to allocate the transaction price between them and recognize each piece separately. Treating it all as subscription revenue recognized ratably would overstate your deferred balance and misrepresent when you earned the services component.
The third one is not maintaining a clean deferred revenue schedule at all. I cannot tell you how many times I have come into a new engagement and the deferred revenue balance on the balance sheet is essentially a black box. Nobody can explain how it got there, what contracts it represents, or when it will convert to recognized revenue. That is not a situation you want to be in when an investor is doing diligence or when an auditor comes knocking.
A Quick Word on Prepaid Credits and Usage-Based Models
The SaaS revenue recognition conversation has gotten more complicated as more companies move away from simple flat-rate subscriptions and toward usage-based or credit-based pricing. I want to touch on this because it comes up a lot.
If your customers buy a block of prepaid credits, you typically defer the entire amount at the time of purchase and recognize revenue as the credits are consumed. *7 This means your deferred revenue balance can be quite high relative to your recognized revenue if customers are slow to activate or use their credits. Investors who are used to ratable subscription revenue models sometimes misread this, so it is worth being proactive in explaining your recognition policy upfront rather than letting them draw their own conclusions.
The same logic applies to usage-based pricing where customers pay in arrears based on consumption. Here you often do not have deferred revenue at all because you recognize as they use, but you do need to be careful about accruing revenue for usage that has occurred but not yet been invoiced at period end.
How to Get Your Books in Order Before a Raise
If you are getting ready for a fundraise and you know your revenue recognition has been loose, the time to fix it is not after the term sheet. Here is the game plan I walk clients through.
Start with a full contract review. Pull every active subscription contract and figure out what the recognition policy should be for each one based on the contract terms and ASC 606. If you have bundled obligations, identify them and figure out the allocation. Do not make assumptions; go back to the actual contracts.
Then build or clean up your deferred revenue schedule. You want a roll-forward that a sophisticated investor can follow without asking you to explain it. Opening balance, new deferrals in the period, amounts recognized in the period, ending balance. If the ending balance does not tie to your balance sheet, you have got a reconciliation problem to sort out.
Get a revenue recognition tool in place if you do not have one. Trying to manage a growing SaaS revenue recognition waterfall in spreadsheets is the kind of thing that limps along for a while and then falls apart at the worst possible moment. Maxio and Tabs are the tools I point people toward in this space. They integrate with your GL and do the heavy lifting.
And finally, talk to your accountant before you talk to investors about this. I am just a Slack message away on this stuff, and honestly, I would rather spend an hour walking through your recognition policy with you than have you walk into a diligence conversation and get caught off guard by a question you did not expect. Investors who know their stuff will absolutely test this.
The Bottom Line
Deferred revenue is one of those accounting concepts that feels confusing right up until the moment it clicks, and then it is completely logical. You collect cash, you owe service, and you recognize revenue as you deliver. That is it. The balance sheet looks a little weird because you are carrying a liability that represents future work, but a growing deferred revenue balance in a SaaS business is generally a healthy sign, not a red flag.
The problems come when the books have not been set up to handle it correctly from the start, or when the recognition policy has not been consistently applied. If you are heading into a raise or getting close to the kind of ARR that will bring auditors and sophisticated investors to the table, it is worth doing a sanity check on where your deferred revenue lives, how it is calculated, and whether your roll-forward schedule is ready to hand over on a silver platter.
That is the kind of thing that separates companies that move quickly through diligence from companies that get stuck. And I have seen both sides of that more times than I can count.
Sources
*1 Financial Accounting Standards Board. ASC 606, Revenue from Contracts with Customers. fasb.org.
*2 PricewaterhouseCoopers. Revenue from Contracts with Customers: ASC 606 Guide, 2024 edition. pwc.com.
*3 Deloitte. A Roadmap to Applying the New Revenue Recognition Standard. deloitte.com.
*4 KPMG. Revenue: Issues In-Depth, ASC 606. kpmg.com.
*5 BDO USA. Revenue Recognition Implementation Issues for SaaS Companies. bdo.com.
*6 Maxio (formerly SaaSOptics). Revenue Recognition Automation for SaaS. maxio.com.
*7 EY. Applying ASC 606: Considerations for Technology Companies. ey.com.
Enjoyed this article? Consider Sharing
Author
