Before I start, I want to stress that I am not a lawyer. I am not an accountant. You’d be a total fool to base any business or legal decisions on anything I write here. Consult a an attorney or a fully accredited CPA or some other person who truly knows what he’s talking about before deciding how to make any decisions whatsoever about anything having to do with money, the law, revenue, etc. I don’t know anything, and if you listen to me, you are making a big mistake.
Developers and other people involved in the software business have heard a lot about “Sarbannes-Oxley” (SOX) and “revenue recognition” and how it effects what Embarcadero can and cannot do with respect to updates, upsells, promotions, and all kinds of issues surrounding selling and releasing Delphi. SOX was a significant, game-changing piece of legislation here in the US, and it affects virtually every public company in the country. It also affects private companies that might someday want to be a public company. It affects software companies in particular, because software is not a physical good in reality, but “acts” like one in the marketplace.
When I was at Borland/CodeGear/Embarcadero, it took me a while to come to grips with what SOX meant and how it altered our business and what we wanted to do. Frankly, I found it all very frustrating. On the face of it, the rules and limitations seemed ridiculous. At first I complained bitterly about it. It took a while, but finally I came to accept them and realize that SOX and the ensuing rules were the “field we had to play on”. Finally, I think I actually gained enough insight into it that I was able to come to grips with the new rules and understand why things work the way they do. As a result, I thought I’d share a bit of that with you fine people.
What is Revenue Recognition?
First, it might be obvious, but let’s be sure we know what the term “revenue recognition” means. Revenue recognition is the process by which a business says “Yep, we actually earned that revenue”. Note, it most decidedly does not mean “We got the cash”. In an accrual accounting system – common to businesses of almost any size – the receipt of cash can actually go down as a liability. Think of taking an advanced payment for services: If you take half the money up front for a job, you have it in the bank, but you still owe the services. Revenue can’t be “recognized” until you do in fact deliver that good or service for the money you’ve received. So if you are a software company, you can recognize revenue only when the software you sell is actually delivered. But software is a strange product in this regard, as we’ll see. As a result, The rules for revenue recognition for software are somewhat cloudy and definitely untested in a court of law.
Why it Became an Issue
When it comes to software, one of the main roots of the revenue recognition rules stem from the (previously) common practice of "pumping the channel". Near the end of the quarter, firms would "sell" lots of stuff to their channel partners. For example, lets say that there was a software company called TrollWare. Selling for a given business quarter started looking a little thin, so TrollWare would "sell" $1,000,000 of product to their favorite online/catalog retailer. (And remember, this was actual, physical boxes back in the day.) Then, they'd claim $1,000,000 of revenue on their books. Wall Street, creditors, and anyone else interested in a company's revenue would think "Hmmm -- that's $1,000,000 in revenue more than we thought! Buy TrollWare stock!” Obviously, this wasn’t a real sale, and could actually end up being a net cost because of the need to actually ship (and maybe even actually destroy) physical boxes of software. This was a common practice throughout the industry, and many companies that we have all heard of did this.
Of course, most often, TrollWare would only really sell, say, $100,000 of all of that "shipped" software by the end of the month and have to buy back $900,000 of it at some point, but hey, revenue is revenue! Clearly this is not a practice laced with clarity, openness, and integrity with respect to people looking at the viability of Trollware.
New, Tougher Rules
This kind of thing was one of many reasons that prompted passing of SOX. The results of SOX are varied, but the results of interest to us software developers were new Generally Accepted Accounting Principles (GAAP) rules for software companies that defined revenue as truly delivering something to the customer. Now, for a hot dog company, it's pretty clear when a box of hot dogs has been fully manufactured and when that box has left the warehouse on the way to a consumer or a business, or whomever is the "end user" of those hot dogs. For example, if you are a rake manufacturer and sell rakes to Home Depot, you can claim the revenue when the delivery truck leaves your loading dock heading to that big orange building. Retailers of rakes like Home Depot can claim the revenue when the rake is scanned across the Point of Sale on its way to clear someone’s lawn. In the first case, Home Depot is the "end user" and in the second case, the guy with the leaves on his lawn is.
But then the question becomes: What does it mean to "deliver a completed software product to the end user"? Well, that's tricky. There are two things here, of course. First, when is the product really “completely produced and manufactured”. Is a beta good enough? What if a promised feature isn’t quite finished? How about a feature that was promised but isn’t there at all? Second -- assuming that you can define the first item -- when is that completed software product actually delivered? Who *really* is the end user? As it turns out, it’s not quite analogous to the rake manufacturer/Home Depot relationship described above. Because software companies were actually fairly guilty of the dubious “channel pumping” practices described above, the rules about what constitutes “final delivery” of software are fairly restrictive, and certainly different than those dictating gardening tools.
There is a lot of accounting literature about this (I’m not thrilled about the fact that I've read a lot of it. It’s not exactly scintillating). For instance, do a Google search on “revenue recognition software licenses” and start reading. The rules are pretty complicated and hard to qualify exactly. And further complicating things, no software company has yet been brave enough to test these rules in court, so they are even murkier as companies work hard to stay well away from the borders of where the rules end and a call from the US Department of Justice starts.
Thus, software revenue can only be recognized when said software is fully and completely delivered to the end user. For a "normal" sale like most of us think of it, revenue can be recognized when the end user has the ability to install the software -- a license is delivered and the user installs it. (For physical software, it's still the truck leaving the loading dock to the actual end user and not merely the reseller).
There's a catch, though: It has to be the complete, finished package. As mentioned above, revenue can only be recognized when a completed product is delivered. If you deliver a "preview" of your product or even a feature of your product, this can imply a commitment to deliver something at a later date. If you even implicitly promise that the purchase today will result in a delivery later, then that probably means you can't recognize revenue until that implicit promise is met. Again, I say “probably” because this is turning out to be the common interpretation of the rules in a world where no one wants to test this in court. This is a unique problem for software because no one normally buys a “preview lawn mower” with the promise of more functionality later.
So, for example: Troll Software delivers a Trollware 1.0 in mid-February. Their spell checker isn't really quite ready, but they need to ship because their main competitor has already shipped a version with a spell checker. Or maybe the need to get some Q1 revenue to keep from not making any money and having to to massive layoffs is a driving factor in the decision. So they ship the product with the label "Spell Checker!!! (Preview only)”. Then, a week into April, they deliver their fully ready Spell Checker to all existing purchasers and update their downloadable ZIP file.
They sell $1,000,000 worth of Trollware by March 31, and think "Yay! We have $1,000,000 in revenue in Q1! Wall Street will love us!"
Oops, not really: They actually have $0 of revenue in Q1 from Trollware. That’s right: $0 in revenue. All of those sales become Q2 revenue, because they didn't actually complete the delivery of any Trollware versions in Q1, but instead in Q2.(This brings about the interesting situation where a company can have $1,000,000 in the bank and $0 of revenue on 31 March for Q1).
Another example: Say you are a Trollware subscriber, and sent them $1200 a year as part of your subscription, receiving updates, improvements, and new features during the term of the subscription. Troll Software can only recognize $100 a month for the 12 month term of the subscription. And consider this: What iff Troll Software wanted to move exclusively to subscription model starting the first of the year? They might have the same number of customers buying, but now their revenue for the first month would immediately be 1/12 of what it normally is, despite having a lot of money in the bank as noted above.
Bug fixes to existing functionality is actually excluded from this -- this is why you normally don't see new features in bug fix updates.
The same might go for "Special offers to registered users". Say they sell a bunch of Trollware in the first half of the year. Starting July 1, they say "Free Grammar Checker to anyone that buys Trollware 1.0!" and in the small print it says "... and if you already have Trollware 1.0, you can have the Grammar Checker, too".
Well, now, if this is the case, have you actually delivered the software to the buyers who purchased before the special offer?
That's why I said "might". As I understand it, this particular issue isn't exactly clear and hasn't been tested in court as far as I know. And of course, no one wants to be the test case for the SEC or the Department of Justice. So in the end, it seems that no one is willing to risk such a deal.
Revenue is King
And of course revenue is everything in business and finance, because it represents the value that you have actually delivered to customers. Revenue is the only real way to measure the accomplishment of a company. And that's fair if you think about it -- that is where Enron is a great example. They weren't actually delivering anything to end customers, but still racking up revenues like crazy. So in the end, measuring accurately what is really, no kidding delivered to end users is what finance people are interested in knowing.
Sarbannes-Oxley was sort of the root of this. One of its main features was to actually hold the corporate officers of public companies criminally liable for their GAAP compliance. The threat of prison time has a tendency to focus the senses. As a side result of SOX, the definition of revenue recognition – and more importantly the desire to strictly follow that definition -- really became an issue, and the need to know a companies real revenue was one of the main fallouts. CEO’s wanted to be 100% sure that they were recognizing revenue correctly because, well, they don’t want to go to jail. Now, there is a lot not to like in SOX, and I personally would like to see it repealed, but the end result being that software company CEOs became far more focused on correctly recognizing software revenue. It's still a bit unclear, and the software industry is still very wary of all of it, because it is untested in court, and as I said, no one wants to draw the attention of the US Government on the matter.
In the end…
Every public company that produces or sells software has to follow the rules set up by SOX. Any business that wants to get a loan from a bank or otherwise interact in the general community of businesses needs to follow GAAP. It's not always fun, but that is the way it works. These revenue recognition rules can result in companies having to do some strange things and, more importantly, not being able to do things that they might want to do and which might even make good sense. But in the end, all organizations in the software business have to follow these rules.
However, in the end, I have no problem with their being clear, concise rules about what "revenue" really means. Really, I think it is hard to disagree. Revenue is a measure of actual, delivered value, and thus a measure of the real value provided by a corporation. That's something that is really good to know.