Cash is NOT Revenue; why aren't more of you fretting about revenue recognition ?
OK, so IH always has threads about monthly vs annual subscriptions. About getting the money today vs tomorrow. Today was another one with https://www.indiehackers.com/forum/saas-product-what-type-of-billing-is-good-monthly-or-yearly-9119f48475
But cash flow and revenue recognition are entirely different things. Let's say you have a product that is $100/month or $1000/year. You collect the $1000 up front. And then you are celebrating, and saying you just went up $1000. No you didn't. You may have $1000 more in the bank (minus fees) but now you have an obligation on the books to deliver 12 months of service. You can recognize 1/12 of it in your first month. The other 11/12 is deferred revenue.
At least, that's how its SUPPOSED to be done when accountants get involved. Especially with things like ASC 606 looming over our heads.
So here is my question... do IHers even care? How are you managing, tracking and reporting your revenue recognition monthly? How are you reporting the liabilities you have on your books when you take an annual subscription?
I'm not against annual contracts. But I am not sure when people are recommending that to new startups that they have considered the obligations it comes with. Especially for those that may not be around in a year... and still have liabilities on the books.
Love to hear other people's thoughts on this.
Hi @SilverStr I agree with you 100% that dollars doesn't technically mean revenue (for the revrec issues you mentioned). Many small startups, including my own, don't close our books every month. Yes, it's a good practice and required for larger companies but not so for folks trying to get something off the ground.
We've decided to only offer monthly pricing until we feel like a plan (features and dollars) will survive 6-12 months. Right now we're changing pricing and features 1x a month - so it's not feasible to offer a long term contract. For people that do and back out - it's not cool and customer are left holding the bag (no service no cash back). I guess, it's to say, if you are offering long term plans, do grandfathering or refunds or at the very least a sorrow filled email.
Worrying about accounting is kinda the antithesis of Indie Hacking. Most people never make it so far where these things matter. It's like spending years on your app to make it performant enough to handle millions of users when you don't even have 100 paying customer.
One might argue that the point @SilverStr makes can be considered common sense rather than getting serious with your accounting/bookkeeping. The ramifications of taking on a 1 year obligation to a customer matters for every starting entrepreneur. Or at least, it should.
That's almost his point though. A lot of people don't make it very far. So if you have annual contracts it basically creates a liability. So if you go under before the year is out then you could be liable. Personally liable too depending on company structure.
Well said Mitchell. And bang on.
I know what you mean Amin that few IHers fret about accounting in the early days. Then don't take on liabilities you can't cover either. You can't have it both ways.
We use Baremetrics to analyze finances and they handle this perfectly. Annual payments come in and they don't count it towards that month's MRR; instead, they take 1/12 that revenue and add it to your monthly recurring revenue.
Agreed here. Definitely important to utilize money as it comes in to grow the business but not to forget that you have to fulfill a year of service and that your MRR for that month doesn't increase by the same factor as the yearly payment.
I was actually thinking the same thing today. You're right that you have an obligation to provide your service for the next 12 month but there are some benefits to annual contracts. For one you have less processing fees from your payment processor. (Stripe sorry @csallen). I would imagine it could reduce customer churn too. Less friction. You only have to pay once etc. (Not backed up by anything)
I don't disagree. And from a cash flow perspective you somewhat can eliminate the SaaS cash flow trough issue when you collect all the money up front and can recover the CAC, since you can apply that to the business... ASSUMING you are using it to keep the company going and growing.... and not moving from 'ramen profitability' to 'lobster success'.
I was talking to an IHer last week who quit and went back to his day job because of personal issues (wife not supportive of the risk of his startup and the tight cash flow). He spent almost a year building up his business, and was doing only annual contracts. He closed down shop and had no provisions in his terms of service... leaving his customers helpless and hopeless. Until Monday, when one of the customers responded to the closure by threatening to sue.
Cash is not revenue. You can have a healthy "deferred revenue" stream on the books, and be cash poor... because you spent money before you earned it. Happens. It's part of bootstrapping. But if you aren't accounting for it.... well that's a whole different beast.
I know some IHers will think their revenue is so small it doesn't matter. But the day you have to talk to the bank, an investor or a vendor... it may very well be important. I think starting day one knowing the issue at least keeps you forearmed, and forewarned.... which was the reason for this post.
Thanks for commenting. Appreciate the insight.
What should be in the contract to protect both the customer and the founder in case one party goes under or gets bought out?
Thats a good point about the guy quitting. Without having a provision in his terms of service he could very well be liable. I can imagine a lot of early stage founders are probably not keeping their books in order and accounting for the deferred revenue. I'm in the very early stages and accounting is the last thing on my mind right now. This is a great conversation. Thanks for shedding some light on the possible downsides of annual contracts
Cash recieved by a service I provide IS revenue.
This comment was deleted 7 years ago
This was a wonderful and useful example. It makes all the sense now. Thank you.
Excellent example and explanation! I think a lot of people don't think about this sort of thing.
This comment was deleted 7 years ago