In this article I try to view everything through the eyes of a CEO or CFO of a SaaS business. I analyze the problem, the principles implemented in order to tackle it, and how exactly we solve it in our case.
Most SaaS are paid in advance. You pay the monthly or annual service fee and you have the service available, for a month or year. That’s pretty straightforward and most SaaS have been built around this delivery model.
The issue is with your accounting. Let’s say you make an annual plan sale. You issue an invoice for that sale. And your sales go up. But you actually have not yet “earned” the subscription fee; you collected the payment but you will gradually earn this fee day by day, month by month, as you deliver your service to the customer. The fee you collected actually represents an obligation on your behalf; to deliver the service paid for.
How does that affect your books?
Since you have not “earned” the fee, your booked revenue must be reduced by the whole invoiced amount and get gradually increased as you deliver the service. And since the yet “unearned” amount represents a pending obligation on your behalf to deliver the service, it should be booked as a liability, gradually decreasing as you deliver the service. That’s the whole notion of deferred revenue.
As an example, let’s say that you sell a 12-month subscription for $1,095 on November 10th. That means you would “earn” $3 per day ($1,095/365). End of November, you would have earned 20 days x $3 = $60. The rest $1035 would be a liability. End of December, your total earned revenue from that sale would be $60 + 31 days x $3 = $153. And this goes on until all $1,095 is earned (or, like the accountant says, “recognized”).
Here’s what this looks like in a spreadsheet:
So, for a typical SaaS business, this means the following:
- When a purchase is made, you book the amount to a liabilities account, e.g. “Deferred Revenue”
- At the end of every month (or every day), you need to calculate what amount you have earned during that time, and debit (reduce) “Deferred Revenue” and credit (increase) your “Sales” account.
- To find the amount, you need to calculate for each customer what they have “used”. You usually find this by checking the subscription start date and end date, and the total amount paid. At least for the simple case.
This is easy to do if you do enterprise sales, and you have a few big customers. But what about doing this for thousands of small, self-serviced customers? What if you allow them to upgrade mid-term and you prorate their subscription? And what about downgrades and providing customers with a balance for their unused service?
But first, let’s see how this new way to look at sales affects the business.
Impact of deferring revenue to a SaaS business
Impact No.1: You have less revenue in your books.
If you only have monthly plans, deferring revenue won’t change much. But if you have annual plans spanning across fiscal years, then your annual revenue will be reduced. Since you earn revenue gradually, and you defer some of your revenue until next year, then your current year sales are lower when compared to sales without deferring revenue. This will impact your financial statements and make your SaaS less attractive when seeking financing (either equity or debt). But good VCs understand that anyway.
Impact No.2: If you are cash flow-positive and growing, then your taxable income is severely reduced.
Let’s assume that your SaaS is substantially cash flow-positive. That means that you invoice more than you spent. Deferring revenue into the next fiscal year means that the deferred revenue won’t contribute to this year’s profit calculation, not until next year that is. And this might severely reduce (or even eliminate) this year’s taxes.
You might think this is just a delay of the inevitable; but it is not. Especially if you are growing. You might end up with no taxes for your first 3-5 years, which can improve your cash reserves and allow you to invest more into your growth.
On the other hand, if next year your sales go down, you will have last year’s deferred revenue added to your revenue, so you might end up paying more taxes even if your inbound cash is low.
Impact No.3: You have a better view of your financial status.
Almost all SaaS companies quote the MRR (Monthly Recurring Revenue) and its growth as their core financial metric. By deferring revenue and “earning” it on a monthly basis, Revenue shown on your Income Statement (or P&L) is almost identical with the MRR. Same with the liabilities. Your deferred revenue shows what you “owe” to your customers.
This provides you with more insight into your current financial status and allows you to make informed decisions on when and where to invest, without being lured by bigger amounts invoiced.
Impact No.4: IASB/GAAP compliance is improved.
Starting Jan 1st, 2018, all companies, private and public, must comply with ASC-606. Sure it requires an overhaul of IT, management and accounting systems. But it means that all companies now play by the same set of rules. Prior to this change, different industries reported the same type of revenue in different ways in the US, while IFRS (International Financial Reporting Standards) didn’t provide standard guidelines. With ASC-606, you can be sure you’re reporting revenue correctly and meeting local and international accounting standards because there’s one directive.
Deferring over 1 fiscal year
As you can understand, you can’t defer income for too long. The law specifies that the invoiced revenue on one fiscal year must be recognized as earned revenue by next fiscal year’s end at the latest.
This complicates things for businesses that have multi-year contracts and not just 12-month contracts (i.e. Annual Plans for most SaaS businesses). In this article we focus only on SaaS with subscription plan durations of up to 12 months. If you have longer term plans, then things are a bit (but not much) more complex.
Our Approach in Deferring Revenue for our SaaS
An important note: There are solutions out there that allow you to do revenue recognition schedules by connecting to Stripe and your accounting SaaS (see footnotes below). But I felt these were out of my comfort zone as they would tamper with our bookkeeping in ways that I could not cross-check or control.
What you will read below sounds complicated, I know. But this is the best way we figured out that “self-recovers” from errors, and can be fully automated. And it works really well with Stripe; the only thing you need to do is replicate the prorating algorithm, which is something that’s easy to do.
For our SaaS, we prorate subscriptions when you:
- upgrade or downgrade plans – we have 3 feature plans you can choose from
- change subscription term – you can pay monthly or annually
- increase or decrease quantity – that is, the number of screens you manage
With prorating, customers can do a lot of ups and downs in terms of MRR. Imagine a customer buying an Annual Subscription for 100 screens (that’s our “quantity” in Yodeck, yours could be the number of users), and later reducing to 20 screens. Based on the prorated upgrade, this customer has paid enough fees to last him for almost 5 years with 20 screens. Things can get weird.
An important note: there are solutions out there that allow you to do revenue recognition schedules by connecting to Stripe and your accounting SaaS (see footnotes below). But I felt these were out of my comfort zone as they would tamper with our bookkeeping in ways that I could not cross-check or control.
The “hypothetical” balance
What we decided to do is look at is the “hypothetical” balance. At the end of each month, we look at the Customer and calculate the total balance in their account, as if they were to cancel their subscription (actually, downgrade to a free account — yep, we have that). This calculation essentially provides all of the deferred revenue for that Customer; the amount is all the already paid fee that we have not yet “earned”.
By monitoring changes in that calculated deferred revenue, we reduce or increase revenue accordingly. A new subscription will increase sales for that month. At the end of the month, the new calculated deferred revenue will reduce sales for that month. At the end of next month, the new calculated deferred revenue will be less than before, and sales will be increased by that difference. Gradually, all of the invoiced revenue will be recognized. All you need to do is do the calculation and keep the last calculated deferred revenue.
Here’s what this looks like in a spreadsheet:
As you can see, this works just fine for doing a mid-term upgrade (or downgrade for that matter).
The Special Case of “Dormant” Balance
There is a special case to be considered: Customers that have actually downgraded to a free plan and have a balance in their account, just waiting there, until they reactivate their subscription. Since they are not under an active contract, according to ASC-606, you can’t defer this revenue. You need to recognize it this fiscal year. At the end of each year, you need to check which accounts that are not on a paid plan have deferred revenue, and recognize this revenue now.
Keep in mind that there is no change in the calculated deferred revenue when you do this, so you also need to keep track of this recognized revenue to avoid recognizing it again; if the account stays on the free plan, the balance will be the same next year. Additionally, if the customer reactivates their subscription, they will be using the existing balance, and this is another reason to track it.
The Special Case of “Extending through Downgrading”
This approach leaves only one case pending to handle. Downgrades to a cheaper paid plan that the current balance is sufficient to cover for service over the next fiscal year. This rarely happens, so you could skip it. Revenue will be recognized, it will just be a bit later than it should be. If you want to also cover this case, then, at the end of the year, you need to calculate the MRR of the subscription, use it to calculate the exact date that the balance (deferred revenue) is sufficient for, and recognize today the part that goes over the next fiscal year.
Tracking this can be quite complex. You would need to keep track of this recognized, but unused, deferred revenue separately because this refers to a specified period in time, while the deferred revenue coming from balance on a free account is not bound to a specific period.
This rarely happens in Yodeck, so we decided to skip handling this case of recognizing revenue earlier. My guess would be that this stands for all SaaS with Annual Plans only. Keep in mind that revenue will be eventually recognized using the rest of the approach detailed above.
First, we had already integrated our platform with Stripe and Xero, to provide full automation and perfect bookkeeping.
Remember that we should already have a “Deferred Revenue” liability account in Xero; if not, you need to create one. All Sale invoices are normally booked under your normal Revenue accounts when issued.
We run the deferring revenue batch code at the end of each month and at the end of each fiscal year (for us, that’s Dec 31st). For each account, we keep two values:
- “Deferred_Revenue”, the last calculated hypothetical total balance, initially set to zero, and
- “Recognized_Unearned_Revenue”, the revenue not bound by period that has not been earned yet (i.e. balance on a Free account), but has already been recognized
At the end of each month
- we calculate the new hypothetical balance, which is the new deferred revenue amount for this account
- we subtract this amount from the stored Deferred_Revenue stored for this account – the result is the revenue recognized
- if the recognized revenue calculated is positive, then:
- we reduce this amount by the Recognized_Unearned_Revenue (but not getting it less than zero)
- if the result is still positive (that is, non-zero), then we create a manual journal in Xero debiting the “Deferred Revenue” Xero account and crediting the Sales account by the final amount
- we update Recognized_Unearned_Revenue with the new value (if modified)
- if the calculated amount is negative, then:
- we create a manual journal in Xero crediting the “Deferred Revenue” Xero account and debiting the Sales account by the amount
- we update the Deferred_Revenue value with the hypothetical balance calculated in the first step
At the end of each year
…right after running the above monthly batch calculation for Dec 31st,
- we take the customers that are on the free plan and have balance in their accounts
- for each account, if the balance is higher than the Recognized_Unearned_Revenue, then
- we create a manual journal in Xero debiting the “Deferred Revenue” Xero account and crediting the Sales account by that difference
- we update the Recognized_Unearned_Revenue value with the new (increased) value
- if the balance is lower than the Recognized_Unearned_Revenue, then we do nothing
Does it work?
This process works perfectly, no matter when you start using this method, and despite anything customers do in terms of upgrading, downgrading or in any way altering their subscriptions.
Our exact implementation includes a small difference: we do not reduce/increase the Sales account that all invoices are booked to. Instead, we do this on a “contra” (adjusting) Sales account. This way we get to see both invoiced revenue and recognized revenue by just changing sums in our Income Statement layout within Xero.
What does it all mean?
Despite any complications implementation of ASC-606 causes, this FASB (US) and IASB (International) joint guideline means everyone reports revenue in the same way. It also increases transparency and disclosure rules for users of financial statements, makes it easier to compare revenue between companies, eliminates any inconsistencies in reporting standards and helps you make revenue-based strategic decisions [see footnote 2]. ASC-606 means you are sure you’re complying with domestic and international accounting standards just by following one single directive. And you get a clearer picture of your revenue and the financial health of your company. All in all, the extra effort is worth it.
 SaaS that do Xero/Stripe deferred revenue calculations: