Accounting for Clouds: Stop Saying CapEx Vs. OpEx

I've seen many people refer to one of the economic benefits of cloud computing as moving expenditures from Capital Expenditures to Operating Expenses. As I have suffered through many a tech nerdy explanation, I'll now make you all suffer through an accounting nerdy explanation, as among my many sins I have an MBA.

First, some background: when people make that statement they are making the argument that with traditional data centers you need to buy servers, networking equipment software licenses and other necessary IT infrastructure up-front (sic "CapEx"), while with cloud computing (whether it's IaaS, SaaS or PaaS), you pay as you go, based on usage (sic "OpEx").

Here are the problems with this statement:

Problem #1: Confusion of accounting terminology

The statement as made above has nothing to do with CapEx and OpEx, which are accounting terms. What these people are referring to is actually cash flow, and specifically the timing of cash outlays. In other words they are talking about spending money upfront versus over time.

I won't bore you too much with accounting terminology, but CapEx refers to an investment we make in assets that will be used over a long period of time (typically several years). CapEx assets are usually depreciated in value over time on the company's accounting (in other words, their value on the books - specifically Balance Sheet - is decreased every period based on certain rules). OpEx refers to expenses incurred in the course of ordinary business, such as sales, general and administrative expenses (and excluding cost of goods sold - or COGS, taxes, depreciation and interest).

CapEx can include things like real estate, vehicles, machinery - and yes, servers. But this has nothing to do with the cash payments for these assets. For example, we may buy servers outright, but with a payment plan of 3 years. It's a CapEx, but the cash outlays are spread over time. On the flip side, we may pay for a service -- say, support services for three years -- upfront, but from an accounting perspective it is an operating expense that is accounted for over the three years.

Problem #2: There is nothing inherently financially beneficial in moving an expense from CapEx to OpEx.

There is no reason to think that there is a financial benefit to making an OpEx expense vs. CapEx expense. Period.

Problem #3: There is nothing inherently financially beneficial to switching from an upfront investment to a cash outlay overtime

"Fine", you say. "You're nitpicking accounting terminology, Geva. What people really mean is that you don't have to make a big upfront investment in your IT infrastructure and surely that's good for any business." 

Wrong.

I hope that most adults understand the concept of "time value of money", but I am often surprised by what people say. If I were to tell you I'll give you $1 million dollars today or $1.1 million a year from now, which would you choose? There is of course no way of answering this question without more information. For example, what is the level of certainty I'll be able to pay the $1.1 million in a year? If you took the $1 million now and invested it, would you be able to make gains of more than $100,000 a year and at a risk equal to or lesser than the risk that I won't be able to pay the promised amount in 12 months? How much do you need the money now? Maybe you are in debt for a $1 million and paying more than 10% interest a year. Maybe you're just flat broke and desperate for money to pay the rent. What are the tax consequences of taking the money now or in 2009? And so on.

The same applies to the notion of the business investing upfront in IT infrastructure or paying for it over time. Let's get something straight: on a per time unit basis, it is more expensive to rent than to buy. This almost always holds true. Joe Weinman put this nicely in his 10 Laws of Cloudonomics post on GigaOm, as Cloudonomics Law #1:

An on-demand service provider typically charges a utility premium — a higher cost per unit time for a resource than if it were owned, financed or leased.

In other words, let's say you're buying a server from Dell for $5,800 dollars and you expect to use that server for 3 years. You also have to pay a 10% annual maintenance fee on that server, so the total cost over three years is $7,540. Amazon, on the other hand, charges $0.40 per hour for an equivalent Large instance on EC2. A simple calculation will show that using the EC2 instance for three years would cost you:

$0.4 x 24-hours/day x 365 days/year x 3 years = $10,512

And that's excluding other charges from Amazon for bandwidth usage and other services, but it includes maintenance which falls on Amazon. This also assumes that you are using the AMI 24/7/365, which may not be true, but will get to that later.

Apparently, over the period of 3 years you're paying more for the Amazon Machine Instance (AMI) than you are for buying the server upfront. Without any consideration to other cost issues involving the two options (and I am well aware that there are many and I'll get to them), let's look at the time value of money implications.

In essence, you are borrowing money from Amazon to buy a server, and paying the loan back to them in monthly payments of $292 ($10,512 / 36 months). Which means it's an annual interest rate of roughly 15%. Is that a good deal? Maybe. As I explained in my $1 million example above, it all depends on your situation and alternatives: for example, can you invest that money is sales, marketing, R&D and other activities that will produce more than 15% annual return? 

Going back to the title of this post, my point in all of this is not that there are no economic benefits to cloud computing, but that whatever those benfits are, they have nothing -- absolutely nothing -- to do with CapEx vs. OpEx, so please don't say that anymore!

As I alluded to in my previous post, I want to dedicate a separate post to the ROI of cloud computing. I will just say briefly that in the analysis above I left out some very important things because they were not the focus of this discussion:

• The whole point about cloud computing, and particularly infrastructure-as-a-service, is that you DON'T utilize 100% of your IT 24/7/365. Cloud providers allow you to deploy new servers in minutes and pay based on hourly usage, which will have a huge impact on the economics. Several back of the envelope calculations I've seen, show that even with an average utilization as high as 70% (and that's very high), you're better off with EC2 than buying your own hardware  


• There are many costs involved in running your own IT infrastructure that go beyond just buying servers, networking equipment and software licenses. These include real estate, energy, cooling, IT admin staffs, management and monitoring software and servers and on and on. It is true that many of these costs are already included in hosting services such as Rackspace, but the important thing is to make sure you're always comparing apples to apples.  


• There are many economic benefits to cloud computing that arise from issues other than direct costs savings on infrastructure acquisition. They have to do with things such as increased agility (the ability to get up and running with new products and services faster), with the ability to scale on-demand to handle unexpected loads (and thus prevent loss of business due to decreased performance or outright downtime), and several other issues, which I will discuss in my ROI post.  

Comments

[Guy Nirpaz]

Geva,

I'm looking forward to your ROI post on the subject. Please be sure to include the following costs as well:

* cost of migration - time to value. Obviously when starting from scratch there is no transition cost and the model can applied from day one

* operational implications - for example - automation. Clearly building a QA env. on EC2 will require adaptations in the way QA teams build and deploy their tests.

[Jim Liddle]

Geva, I think you miss one more point is worth mentioning on the CAPEX V OPEX argument. It's not all about the nuances of how the money is accounted for and when it is paid. It's also about "whose budget pays for it".

I've been in many sales situations where departmental budgets, which are from the Capital Expenditure pot, are either not sufficient, or need to be stretched out, which impacts what can be done. Moving the deal to a budget which is accounted for by OPEX means that in some cases, the department / group has a way which it can do business with you.

This is not at all related at to Cloud per se but to any deal that you are trying to cut with a company, but cloud does have the advantage that it core SaaS type model is much easier to slot into an OPEX budget stream. For many companies selling cloud infrastructures / tooling, this can be difference between walking away or doing some business and forming a revenue generating relationship with a company.

[botchagalupe]

Thanks for setting the record straight. When non "*BA" dudes like me start using those terms incorrectly something has to be done.

Great post as always...

John
johnmwillis.com

[Geva Perry]

@ Guy Nirpaz -- Both very good points. In some cases, with existing applications, there will also have to be some overlap time that needs to be taken into consideration during the migration phase.

I also agree with your second point. I think it will be very interesting to understand the true value of cloud environments in helping manage the entire application lifecycle dev -> Test/QA -> Deployment -> Production -> Change/Upgrade and so on

Geva

[Geva Perry]

@Jim Liddle -- Very good point which I did not mention. But are you sure the issue is whether it is in a CapEx or OpEx budget or whether it is the fact that the organization does not have to make a long-term upfront commitment?

[Geva Perry]

Thanks, John.

[George Reese]

I agree with points #1 and points #2, but I find point #3 entirely problematic.

You say, "There is nothing inherently financially beneficial to switching from an upfront investment to a cash outlay overtime."

But there is. When you say "nothing is inherently financially beneficial", you are saying, "all other concerns aside, financially I am perfectly willing to let a coin flip determine whether I cough up the cash today or pay it out over time. If that were true, the time value of money would be zilch.

All else being equal, you will always take a dollar today over a dollar tomorrow. You will always spend a dollar tomorrow over a dollar today. There is an inherent difference. When you pay over time, you pay for that inherent difference in a variety of way. Interest rates, rental fees, etc.

The benefits of a payments over time can be erased by situational issues. Like absurd hourly fees, going nuts allocating EC2 instances, etc. And the harder it is or more expensive it is for you to acquire capital, the more beneficial payment over time becomes.

[Jim Liddle]

Not having to pay an upfront cost is an important, but different reason, to my initial reply.

For many organisations who have complex procurement processes the challenge for individuals is often how to do business within the boundaries that are defined. This is where exploring opex budget streams can be the difference between doing business (or not).

[Simon Wardley]

Having spent over a decade using utility mechanisms of billing for computing services, Jim Liddle is absolutely correct on his point about exploration of different business streams and how capex and opex are often seen differently.

Whilst you're absolutely right in your description of capex, opex and how you can have capital lease arrangements, there is a common use in business conversations for capex to mean upfront cash outlays for an asset depreciated over time and opex as general run of the mill operating expenditure.

With any activity which is highly variable and has large capacity spikes, there can be a huge benefit to switching from an upfront investment covering the maximum of capacity over the whole time period to variable pricing based upon actual activity. Seasonal capacity spikes in many business can be an order or more of magnitude from base levels of activity.

Capex to opex is simply a convenient short-hand way of describing this.

Just as your use of SaaS is a convenient, well understood BUT ultimately incorrect short hand in the eyes of a pedant. All the layers of the computing stack you describe involve software. Really you're talking Applications as a Service.

[Geva Perry]

@George Reese - That is not at all what I said - that I might as well let a coin flip decide. I think I was quite explicit in stating that it depends on the circumstances. In real-life business it is virtually never the case that I have the choice between spending $1 today and the same $1 tomorrow. I have to pay for time, as I demonstrated with real numbers comparing purchasing a Dell server or renting a Large AMI from Amazon.

My second point to you would be that even if it is true that it is beneficial to spread payments over time, it is nothing specific to cloud computing (Dell provides an option to lease servers, for example).

[Geva Perry]

@Simon Wardley - Jim Liddle is correct in stating that politically in certain circumstances it is easier to navigate an organization's budget by using the term CapEx or OpEx. I have no problem with that and it does not contradict anything I've written in my blog. It stil doesn't turn it into a reality that cloud computing is economically beneficial because it's CapEx, not OpEx.

Second, I don't know why you are making the sweeping statement that it is common use in business to call upfront investments CapEx, etc. I would agree that it is a common error.

Your third point about variability, is absolutely correct but has nothing to do with the topic of the blog, as I clearly stated in the closing comments.

Finally, there is a huge difference between using a term such as SaaS, which has been infused with a very specific commonly accepted meaning in the industry, and using terms with very clear definitions from the FASB incorrectly.

Additionally, even if I were to be a pedant, I don;t see how the use of SaaS in this blog post is incorrect in any way.

[Simon Wardley]

@Geva: For the twenty years that I've been running businesses from small start-ups to operating units in large multi-nationals, and consulting from the large to the small, I'd argue that a common use in business conversations is for "capex to mean upfront cash outlays for an asset depreciated over time and opex as general run of the mill operating expenditure".

Of course everyone is aware of capital lease arrangements and the horde of various cashflow options, however the general use is not the same as the specific.

Capex to opex conversation is simply a useful short-hand for describing a myriad of opportunities including variability against activity.

The point about SaaS is that the S stands for Software and in your layered approach to the computing stack each of different layers contain Software. A pendant would argue that it is therefore incorrect and the problem with pedantry is it is not concerned with the common usage but the correct usage as though language of any form was static.

However common usage is what matters and that's the point. Capex to opex conversion has a common business meaning which most people in business would intuitively understand.

[Dennis Howlett]

@geva: tut tut my friend. Your grasp of accounting and the way accountants look at this 'stuff' is askew. Trust me - I am one (lol.)

The problem EVERYONE faces in this debate is figuring out what to include and what to exclude in any comparative example. In some categories that's easier than in others.

For instance, your Dell server example seems reasonable at face value except you would never contract on a 24x7x365 days basis for a comparable aaS deal in any sizeable negotiation. That is something you seem to have addressed.

On the other hand, determining the fully loaded cost of running say SAP/Oracle CRM compared with Salesforce is fraught with all sorts of difficulties, largely because people have not really thought through the cost of implementing and managing their computing environment. Far less have they bothered to properly assess theory versus reality.

On premise software providers often trot out the long term cost argument but they fail to factor in things like risk (how many failure stories do you want to hear), forced march upgrades, architectural or technical changes etc. The SaaS providers on the other hand wave a hand and say point the browser at our software and you're done.

We both know that each side has 'issues.' Perhaps the best way to think about this is from the vendor perspective. So far it is has proven difficult for the saas providers to make money. Even the mighty salesforce makes a pittance on $1 billion. Compare that to say a PeopleSoft at the same stage and you'd see a marked difference in performance.

Salesforce could throttle back marketing but then it would risk losing sales.

We know that large scale saas is hardly a proven profitable software delivery model and colleagues who are more entrenched than I in this market tell me there is a long way to go.

That suggests to me the saas provider is bearing a lot of cost I don't need to consider so all other things being equal, I have the advantage of risk transfer back to the provider. That's welcome as it's a cost I don't want to bear.

If that gets me off the capex treadmill and ensures that I have a predictable cost I can factor into my accounting then I"m likely going to smile and sign the deal.

In other words, 'cost' is not a simple accounting construct but one that requires significant thought.

To your comment referencing Weinman, I have to say I don't buy that. Looking across the landscape it seems we are largely stuck in a $5,10,20 (take your pic) market mindset in many softwares. I don't see how they have any bearing on theories around market premiums etc but are a reflection of what the vendor believes the market will bear. As someone who has done a LOT of work on pricing, it is at best an inexact science and at worst a black art. So for example, a Basecamp service seems reasonable but then if I tack in say a Freshbooks, then all of a sudden, the total economics start to look rich for me as the customer. Who has got it wrong? Who needs to adjust?

As to the more general argument about capex v opex, as a professional I can say that I have no difficulty in understanding the difference but that much of this debate is about the financing of the software. If anything, it is telling me that the prevalance of financing arrangements indicates a preference for the immediate write off route, ie opex.

The problem with capital acquisition is that unlike almost all other physical assets, software is ephemeral and there is no way to know whether it will deliver value at the pint of acquisition. At least with a building, you can see alternative uses. Finally, depreciation is an arbitrary construct developed as a matter of convenience. Of itself it is meaningless. On the other hand, my direct monthly write off for a service I am consuming is tangible.

[Geva Perry]

@Dennis Thanks for the thoughtful comment. If anything, what you are saying only strengthens my point. I was not trying to give a thorough explanation of what CapEx and OpEx is. I was saying exactly what you did:

'cost' is not a simple accounting construct but one that requires significant thought.

To put it in context, on many of the cloud computing blogs it has become a mantra to simply say "cloud computing is good because it shifts CapEx to OpEx." That's what I was arguing with. I'm sure you'll agree with me that it is not an a-priori good thing in every case, without knowing anything about the circumstances of the business and deal at hand.

For example, you're assuming that the business wants an immediate write-off. What if it's losing money and expects to be profitable in the future? Generally, isn't it better to depreciate over time? (again, I am sure there are many considerations per case - and that's my point).

You also seem to be focused on software, while I had large data center investments in mind, which includes real estate. I simply gave the server example to make a point -- and thanks for saying on your blog that the point was well made :-)

[Eddie Bovak]

My issue with your argument is that you assume equal access to Capital and Expense dollars. Depending on the company, the time of year and their internal financial processes an manager or business unit may have easier access to expense or capital.

At the end of the year, when capital budgets are under spent it maybe easy to fast-track a capital appropriation; however, for most companies capital expenditures require weeks or months of back and forth with the finance department and multiple levels of approval. Expense dollars, on the other hand, are generally spent at the Manager/Director's discretion, as long as they stay within their budget.

For many projects the ability to fund via expense dollars could be the difference between green-lighting the pilot and waiting till next year's budget planning cycle.

[Geva Perry]

@Eddie Bovak -- I understand where you're coming from, but please point me to where I make the assumption you suggest I'm making. I made no such assumption. And what your're saying may be absolutely true, in some cases. Come to think of it, aren't you making an assumption?

[Colin]

Hi guys, I am a non techie and the over use of esoteric terminology confuses me, so I must be a pedant. Some later comments seem to focus on Assumptions, as an englishman, we try never to ASSUME as this makes an ASS of U and ME. Excellent blog.

[Jan]

speaking of cloud computing, are accountants using saas accounting software nowadays?