The Elephants and the Rabbits (Accounting at SaaS Companies)
August 19, 2009
Brian Sommer just posted a very funny piece on how SaaS CEOs can prepare for an earnings call. If anything, he understates the problem.
We have learned over the years how to respond to software company earnings calls. We look at license revenues; we look at revenues; we look at margin; and we decide whether the company is doing what it “should” do at its level of maturity.
What few people realize is that the rules governing SaaS vendors are different, so comparing SaaS vendors and perpetual license vendors is like comparing–oh, let’s try to avoid a cliche–elephants and rabbits.
This gives these guys so much opportunity to obfuscate that frankly, they don’t even need to practice.
To understand how this works, you need to understand the differences between the rules. I’ll stick with the basics. The key difference is that when a perpetual license vendor sells something on the last day of the month, they report the total amount of the contract as revenue; when a SaaS vendor sells the same software, they don’t.
With the perpetual license vendor, the idea of the accounting powers that be is that selling a software license is like selling a piece of packaged software over the counter. You sign the contract; they invoice; ka-ching. With the SaaS vendor, the idea is that they’re not selling an over-the-counter product, they’re selling a promise to deliver a service. And, since there’s always a risk that they won’t deliver, they can’t recognize revenue until they actually do that delivery.
Let’s see how this works in an example. What we’re trying to do is evaluate how sales are going. With a perpetual license vendor, at the end of the quarter, we can look at their reports and be able to tell, basically, what they sold, and how sales are going. If SAP sells a $1 million contract on June 30 (and ship and invoice), they report $1 million in license revenue, and we know that’s what the sales force did.
Now imagine that a SaaS vendor is working equally effectively. At the end of a quarter, they sign a $1 million contract that is effectively equivalent in the customer’s eyes. (Who knows, maybe SAP and Salesforce were competing and Salesforce won.) If we look at their revenues, we’ll have no idea that this is the case. Almost none of that $1 million will appear as revenue, because they are only allowed to report revenue for the days of SaaS that were actually delivered. For that $1 million contract signed on the last day of the quarter, SAP will report $1 million in license revenue, but Salesforce will only report $1,000, assuming they turned the product on that day and so delivered one day of a 1,000-day (3-year) contract.
This makes Salesforce look bad. But later on, things reverse. Imagine there’s a quarter when both SAP and Salesforce reps sell bupkes in a quarter. That quarter SAP reports $0 license revenue, but Salesforce reports the $90,000 that it earned from the 90 days of delivery on that old contract.
Two companies. Identical performance. Completely different-looking results. Now, we’re not completely trapped. We can get some idea of what’s going on, by looking at what are called the “bookings” numbers. (The booking is the amount of money invoiced during the quarter for the contracts that are signed.) Most financial analysts just use a quick and dirty rule of thumb for comparison purposes; bookings for SaaS companies are roughly equivalent to sales revenues for perpetual license companies.
if SaaS companies booked revenues the same way that perpetual license companies bill for revenues, this would be fine. But in fact, SaaS companies don’t necessarily book all the revenue from contracts like that $1 million contract that I’m using as an example. Very often, they don’t invoice for the product until it actually starts being used. So on that last day of the month, it’s reasonably likely that the bookings will be, say, $299,000 and the revenues $1,000 for that contract. But the rest of that $1 million won’t appear anywhere. It will be booked in the fullness of time, but by that time, we won’t really care.
So how do you compare the elephants and the rabbits? You don’t. To compare the two, you would have to know the value of the contracts that the SaaS companies signed And they have no responsibility whatsoever to tell you what that value is. In fact, they can say anything they want to about that imaginary $1 million contract; they can announce it, hide it, whatever. If this quarter, they want you to believe that they’re selling as much as SAP is, well, they can release figures that make it seem that way. And if this quarter, they want you to believe something else, well, OK. All perfectly legal. In our example, Salesforce and SAP are “actually” doing equally well. But there is no way of knowing this.
Oh, it gets worse. It turns out that the accounting standards that govern SaaS companies make margins worse than they “actually” are. So even if you did get data that let you compare sales accurately, the accounting standards would automatically make the SaaS company look less profitable than the on-premise company.
Awful, right? Not even close. You see, very soon, it’s going to get even worse. The accounting standards are changing. But hey, that’s material for another blog.
Think Small: Appropriate Technology for the Enterprise
June 24, 2009
Vinnie Mirchandani frequently rails against maintenance fees in his Deal Architect blog, quite correctly in my view. As apps get older, the ecosystem becomes more robust, the number of people available to make the things work increases, and the underlying technology gets better, prices should go down. That they don’t is a testimony to the chutzpah of the application vendors and the, er, timidity of the customers, nothing more.
But let’s say, Vinnie, that you know this and you’re not particularly craven, but you need these guys. What do you do? Or let’s say that you’re just buying something they’re offering, because it makes sense. What do you do? Or let’s say that you believe those silly pundits and you’ve decided to go off maintenance. What do you do?
As I said in an earlier post, you still need an application strategy. The question is really, “What should that strategy look like?”
In that earlier post, I suggested that you should favor cloud applications, because they reduce the invisible, but very real long-term infrastructure costs. You should think Google Apps and Salesforce and developing on Amazon (but not on Intuit’s QuickBase, no matter what you do).
But this isn’t in itself a strategy, it’s just a guideline. So let me add another such guideline.
Think small.
Do you remember back when Jerry Brown was governor of California and was talking about something he called, “Appropriate Technology.” Appropriate technology was small stuff, which worked, which didn’t cost too much, and which was suited to a small, local problem at hand.
Let me give you an example that I remember from the time. Our local, San Diego power company wanted to build a plant in the desert, basically to deal with peak power demand. This was a big technology solution. Perhaps emboldened by Governor Moonbeam, the appropriate technology people proposed a combination of cogeneration and peak usage pricing. Miracle of miracles, they one. Why? Well, I can assure you it wasn’t because San Diego County had gone blue. It was because everybody could see the point of not having to pay for concrete and transmission lines, when they didn’t have to.
Oh, gosh, am I talking about best-in-breed apps, heterogeneous computing environments, multiple vendors, nightmarish integration costs, etc., etc., all the things we were trying to get out from underneath when we jumped onto the big app bandwagon?
Yup, yup, yup. That’s what I’m saying. In this day and age, you’re better off figuring out small, local solutions to specific problems–and accepting the costs associated with that–than you are buying a large, global solution, that supposedly offers economies of scale, but never delivers them.
If you adopt this strategy, you think (or at least you entertain the possibility) that a small, light call center/knowledge management app that deflects 10% of the time-wasting calls and can go in tomorrow, SaaS, might do more for you than the global call-center app that is designed to automate your interaction with most of your customers, costs jillions, and will take so long to install that none of us will ever be there to see what happened–even though the large app is supplied by your primary IT supplier and will become part of your global application footprint (the one you pay all that maintenance for).
I know it’s a radical notion. But that’s the idea. Think small. Look for small improvements. Buy small apps to make the small improvements. Don’t buy more than you need; assume that light apps that do less are the way to go.
Given the cost structure in place today, you’ll not only do more, faster; you’ll save money.
Why? Well, when you cut through all the nonsense, it’s the same reason I pick up a wrench rather than call the plumber. It doesn’t require that much. The job gets done. And there’s no reason to pay any more than I have to.
Cloud Confusing
June 5, 2009
This is one of what I hope is a long series of posts on what’s wrong with cloud computing. (The more cloud computing grows, the more things there will be wrong with it.)
OK, so this morning I get an e-mail from Xactly, a sales compensation software company closely allied with Salesforce. It’s a hosted, oops, cloud application, a fixture on the AppExchange, which at least theoretically lets salespeople who use Salesforce figure out what their compensation is going to be if they ever get one of those sales.
Steve Cakebread, part owner of Cakebread Cellars and, oh yes, for many years CFO at Salesforce is giving a seminar on how to sell to the CFO. The seminar is sponsored by Xactly of which, not coincidentally, Cakebread is now the CFO.
The wine is quite good. I’ve had it at many of those lavish events for analysts that Salesforce used to sponsor back in the days now gone. But of course it was before noon when I got this e-mail, so I didn’t think too much about the wine.
So I signed up, or tried to. You see, while Xactly may be on the AppExchange, they don’t use Force.com as a platform, they have their own product which is hosted by OpSource, another long-time Salesforce partner and AppExchange stalwart that has a particular appeal to AppExchange partners because they help people through the process of joining the AppExchange.
The e-mail comes from Xactly, but actually Xactly is using the events software from OpSource, so when you register, you register at a site with an OpSource URL.
So when you get to the registration site, you can see labels, like Name, E-mail, etc., but you can’t actually see any fields to put your name in. This is probably due to the fact that OpSource (or whoever wrote this registration page) actually doesn’t believe in providing products that work correctly on Firefox, another cloud computing provider.
Where is that wine?
To register, I have to find the fields by hitting the Submit button, which gives me an error message, saying I haven’t filled out a field, and then I can kind of guess where to put the cursor, and at the end, my name is David Dobrin Dobrin, because I put David Dobrin in what I thought was the Name field, but was actually the First Name field and then had to poke my way around until I could find the Last Name field and put my last name in again.
Is it noon, yet?
So I’m registered, yay, but I can’t actually remember when it is, so there’s a little button that says, “If you’d like to sign up with Adobe Connect, you’ll get an e-mail with an item for your Outlook calendar.” I cringe a little because Outlook calendar items don’t integrate very well with the Mail app from Apple, but OK. So I hit the button. I am now hooked up with Adobe Connect (although it’s still an OpSource URL), and again, I am asked for my registration information. So do I have to register again or not? You tell me. I don’t know.
Except that there’s another button that says, “If you’ve already registered with us, click here.” Now who is “Us?” OpSource? Adobe Connect? Xactly? Salesforce? Cakebread Cellars? I’m assuming “us” means “the seminar you just signed up for, dummy,” so I click the button. Up come a username and password field. For whom? OpSource? Adobe? Crud, I wonder if my old username and password for that meeting software that Adobe bought years ago still works. What was it? I can’t remember.
Guys. Give me a break. If I want to sign up for your seminar, I don’t want to have to establish/remember relationships with three other cloud computing companies. The only other company I even want to know about is Cakebread Cellars. If you don’t actually believe in, want to participate in, or know anything about universal identifiers as a necessary lubricant in the cloud, then at least have the good taste not to inflict all your relationships on me.
In cloud computing, you always do a lot of function shifting onto your partners. But if that simply becomes cost-shifting onto your customer, you and cloud computing have failed.
And when that happens, I have a ready alternative. Instead of dealing with Cakebread CFO, I deal with Cakebread Cellars. Have some wine.
Problems with Cloud Services I: RIM and XO
April 13, 2009
Talk to the typical SaaS executive about the complexities of customer service in Cloudland, and they give you a blank stare. What’s the problem. We provide our service. We guarantee it. We do a better job than
Well, yes. But that’s not all. When you’re getting cloud services, the services are often coming from multiple providers. Each of them can think they’re doing a good job or the right job. But even so, delivery can fail. And when that happens, it’s a nightmare for the customer. A nightmare.
Here’s a simple example. I have a Blackberry Pearl. My web site and domain name are hosted by XO. Two SaaS providers. I get my Blackberry e-mail from XO, which forwards it to the Blackberry domain name (tmo.xxx.com).
All of a sudden, this weekend, I started lots and lots of new spam–you know, the usual, sex stuff, plus a lot of spam with a Facebook return address, etc., etc., stuff that had been filtered. The new spam appears on both my Blackberry and in the e-mail delivered directly to my POP3 Mail account on my Mac. But much more new spam appears on my Blackberry.
Obviously, something happened to one or more of the spam filters that are provided to me. I know of at least two of these filters: one at XO and one on my Mac. Is there another one at RIM? Who knows.
I’d like it to stop, but I don’t have the time to troubleshoot this problem. Did XO change its forwarding policy? Did RIM install a new filter and screw up? Who knows.
If I just had one provider, I’d have some chance of solving it. But when I have two, I just have to sit and wait. The worst of it is, it might be the case that neither provider will ever realize that there’s a problem.
I wonder if the iPhone has a spam filter on it?
The point? Well, cloud service providers need to start thinking about this–and taking responsibility for the actual delivery of services, not just for making those services available.
Four-Five Years
March 31, 2009
Within the tiny world of SaaS executives, there’s a little-known rule of thumb. I call it the Four-Five Years Rule. The rule is this. “When comparing the cost of SaaS offerings against an equivalent perpetual license offering, the break-even point comes in four-five years.” That is, when you add up the total cost of leasing a SaaS offering and the total cost of a perpetual license offering, the latter including hardware, the software license, and maintenance, and even the cost of money, the SaaS offering is cheaper for four years-plus; after five years, you’ve spent less on the perpetual license offering.
Did you know that? Bet you didn’t.
So is that an argument for SaaS, or is it an argument for perpetual license? After all, most installations last longer than 5 years. So maybe you should bite the bullet and pay up front, right?
No. You see, there’s a big, big difference between the two at the break-even point. With a perpetual license application, the application you’ll have is four-five years old. (You see, I’m not including the cost of upgrades.) But with a SaaS application, the application you’ll have is brand new and up-to-date.
It’s sort of an inversion of the old automobile lease-vs-buy conundrum. At the three-year breakeven point, if you buy you have a car, but if you lease, you have an empty parking space. With software, if you lease, your installation stays new. If you don’t, it gets old.
It’s also an inversion of the standard idea about SaaS, that it’s cheaper, but you get less. Not at all, after five years, it’s more expensive, but maybe worth it, because you’ve got a superior product, one that’s been kept up to date.
Not necessarily worth it, mind you. If you don’t need all the stuff they put in to keep the software new, or if you need to customize, you’re definitely better off with perpetual license. A lot of it depends on what you think the useful life of the old software will be.
One last argument for perpetual license, of course. If you do think the old software will have a long useful life, you can plan to save a boodle by going off maintenance sometime after those five years are out. If you do that, perpetual license can be way cheaper.
The Applicator 