THE COLOURS OF MONEY
There are various national and international regulations and accounting standards (eg FASB and IFRS) which lay down clear guidelines for capex vs opex when developing software for internal use. Note that these guidelines don’t dictate whether companies have to capitalize or not, only the rules they have to follow if they decide to do so. As we’ll see further on, some companies capitalize their software development while others expense it.
Now regardless of where your IT department sits on this, you should still be able to understand the underlying debate, because, at the end of the day, it all comes down to the numbers – capex or opex.
CAPEX VS OPEX RULES IN IT
So what do the accounting rules cover? Essentially the following three phases in software development, based on the waterfall approach (we’ll talk about iterative or agile development further on):
- Preliminary project stage or evaluation phase, which establishes the technical feasibility of the project. These are essentially R&D costs, and are charged to opex, because, if the project ended here, there would be no asset to speak of.
- Software development or application configuration phase. All development and configuration work subsequent to technological feasibility is capex. The end result is an asset, comprising software (bought or built), hardware and infrastructure.
- Post implementation or production phase. This is opex because these are day-to-day running costs.
Now, if only it were that simple! Unfortunately, IT is not science or engineering (even though we often like to think it is!). For example:
- Enterprise software licenses are capex, but the corresponding annual maintenance costs are opex.
- Functional design is opex and technical design is capex, but the border between the two can be blurred when done by collaborative teams.
- Production upgrades or enhancements are capitalizable, whereas maintenance and bug fixing are not, even though they both have development costs. This is because the former significantly enhances the value of the asset, whilst the latter does not.
- An ERP-to-CRM order entry interface is a capital cost, whereas a one-time ERP-to-CRM data migration interface is an expense. This is because the former is an integral part of the asset, which generates long-term value, while the latter is a one-off with no alternative future use.
- T&E (Travel and Expenses) are normally expenses – except when they are part of a capitalizable activity!
- Software as a Service or SaaS is pure opex. Even if you end up customizing a SaaS application, the development costs will still be opex because you are renting. You don’t own the asset, ie it doesn’t sit on your company’s balance sheet. We’ll go more into this further on when talking about cloud computing.
One of the key take-aways from these examples is that it is not the activity in itself that is capitalizable (eg development), but rather the outcome of that activity and the ownership of the resulting asset. So when we say “development and testing are capitalizable”, what we are really saying is that they are capitalizable because of their outcome, in that they are being used to build a wholly-owned asset which will generate long-term economic value.
As you can see, there is plenty of room for interpretation, resulting in differences in the way companies capitalize IT costs. So how does the average project or application manager – for whom most of the above is probably news – do proper budgeting and cost management that can stand up to an audit? (Test your own level of knowledge with the following survey).
The main answer lies in their level of financial awareness. Unfortunately, another survey shows that about 50% of respondents don’t know the difference between capex and opex, and 80% have never had any formal IT financial training in the course of their career. This can be mitigated to some extent by the level of support they get from the finance department and the degree to which ERP systems can be set up to automatically implement some of these rules.
WHAT ABOUT ITERATIVE OR AGILE DEVELOPMENT?
The above accounting rules and guidelines are based on the waterfall methodology, so cannot be applied directly to iterative or agile development with its collaborative approach, short cycles and absence of a big upfront design. This means that there is no clear process milestone for technological feasibility, which therefore requires a different approach to identify the start of capitalization.
According to FASB, technological feasibility can be based on either a detailed design or a working product:
- Detailed design: “The detail design of a computer software product that takes product function, feature, and technical requirements to their most detailed, logical form and is ready for coding”.
- Working model (or prototype): “An operative version of the computer software product that is completed in the same software language as the product to be ultimately marketed, performs all the major functions planned for the product, and is ready for initial customer testing (usually identified as beta testing)”
In iterative or agile development, as management consultant and agile specialist, Craig Larman, explains, technological feasibility is reached after a number of iterations (called sprints in the Scrum methodology) after which capitalization can start. This would correspond to Barry Boehm’s LCA (Life Cycle Architecture) milestone, or the Rational Unified Process (RUP) “end of elaboration” milestone.
Another key difference between waterfall and agile is the amount of development costs which can be capitalized, which in general will be less than under waterfall’s detailed programme design approach. This is because the initial development is done during iterations prior to reaching technological feasibility, whereas in waterfall all development is done after technological feasibility (which once again underscores the point made earlier on that it is the outcome rather than the activity which is the main criteria for capex vs opex). But this is perhaps a moot point, because iterative development generally requires far less time to reach technological feasibility compared to waterfall, which is heavily front-loaded with opex prior to the start of development.
In any case, these agile vs waterfall distinctions are not seen very often in practice, because not only is agile development not the norm in IT departments, those that do practice it don’t do so on a scale large enough to warrant capitalization. And those companies that do practice large scale iterative or agile development are usually product development companies that don’t capitalize anyway (discussed further on).
ON-PREMISES vs CLOUD – THE DECIDING FACTOR
Implicit in the above discussions of waterfall and agile is the notion of on-premises, ie the software ends up running in a technological environment or data centre which belongs to the company that built it. That is why it can be capitalized as an asset.
But on-premises is no longer the only game in town; cloud computing is rapidly becoming an integral part of the landscape. A waterfall or an agile project can therefore be developed and run either on-premises or in the cloud – which now becomes the deciding factor for capex vs opex rules. Let’s see how.
Cloud computing is based on a rental fee for standardized, on-demand services hosted in a data centre, based on the following models:
- Software as a Service, or Saas: you pay per user for an application (eg CRM), and the vendor manages everything. This is the most common cloud model.
- Infrastructure as a Service, or IaaS: you develop your application in-house but you pay for externally-hosted infrastructure services, eg server capacity.
- Platform as a Service, or PaaS: you develop your application in-house but you pay for externally-hosted infrastructure and run-time services, eg a complete software development environment.
Clouds can be public or private (they can also be hybrid, but let’s stay simple for now). Public clouds, eg Amazon Web Services, are accessible by any client with a credit card. Private clouds are restricted to one or more clients, usually for security and data privacy reasons. Private clouds can be hosted internally (ie by the IT department itself) or externally (ie by a vendor as a hosted private cloud).
Public clouds have no hardware or infrastructure capital costs for the client because these are owned by the vendor. As we move up the cloud value chain though, capex vs opex rules may apply:
- for IaaS and PaaS, the client is developing software on someone else’s infrastructure, which he will then own and run. Capex vs opex rules therefore apply when developing the software using agile or waterfall.
- For Saas, however, there are no software assets created by the client, since the software is owned by the vendor, eg Salesforce.com. So, even if you end up customizing your SaaS CRM application, for example, the development costs will still be opex because you are renting. You don’t own the asset, ie it doesn’t sit on your company’s balance sheet. Public SaaS is therefore pure opex, and the capex vs opex rules for waterfall and agile do not apply.
For internal private clouds the rules are much simpler. Since everything is developed and hosted internally – ie on-premises – the underlying hardware, software and infrastructure are capitalizable because they are wholly-owned assets which sit on the company’s balance sheet.
For external private clouds hosted by a vendor, however, there are no hardware or infrastructure capital costs for the client because these are owned by the vendor, as for public clouds. The software, however, is bought or built by the client and is therefore capitalizable because it is a wholly-owned asset which sits on the company’s balance sheet.
The subject of capex vs opex for cloud computing still generates lots of discussions, most of which can be explained by the generally low financial awareness of most IT staff (as evidenced by the surveys mentioned earlier in this article). A good starting point for further reading on capex vs opex for cloud computing is Bernard Golden’s excellent article, Capex vs Opex – most people miss the point about cloud economics.
TO CAPITALIZE OR NOT TO CAPITALIZE – THAT IS THE QUESTION
As mentioned at the start of this article, some companies capitalize their software development while others expense it. What drives such decisions?
We should first make the distinction between product development companies (in which IT is their core business, eg software vendors) and companies whose core business is not IT, eg manufacturing or pharmaceutical companies:
- Product development companies understand that IT is indistinguishable from R&D – indeed, as Craig Larman points out, historically IT used to be called R&D or Systems Development or Engineering. Consequently, they have been doing the appropriate accounting for as long as they’ve been around, often based on concurrent engineering and cross-functional teams. The norm for product development companies is to expense IT (see the survey in the 2006 report, Capitalization of Software Development Costs: A Survey of Accounting Practices in the Software Industry, in which 146 out of 207 software companies did not capitalize their software development).
- IT departments and their financial controllers generally don’t view IT as R&D; eg in a pharmaceutical company, R&D means making drugs, not building software. So the dominant waterfall methodology prevails, with accounting practices which lend themselves more to the FASB capex vs opex rules outlined in this article. However, that does not mean they all capitalize. Some do and some don’t.
A key reason for expensing, identified by both Luigi Paraboschi (VP of Finance at HP in Geneva) and Eugene Nisker (CEO of Evident Point Software in Vancouver), is to account for the cost sooner and therefore minimize the tax burden in the short term.
Other reasons include a combination of a low total project cost, a short useful life and a short time between technological feasibility and the completion of software development. I polled a number of people on this in Europe, the US and Canada and answers ranged from none or very few to 50/50 (Suraj Nekram, CEO of SteelGlass Consulting in New Jersey). A financial maturity survey in June 2011 showed that over 80% of IT departments capitalize their software development. I have personally worked far more with IT departments that capitalize than with those who expense.
While there is no right or wrong since both are financially compliant, conventional wisdom holds that CIOs “prefer” capex because it reduces the current year IT budget, whereas investors prefer opex because capitalization can be seen as artificially boosting current year profits. Echoing this view, the financial website Investopedia, in an article on cash flow, says that telco “Verizon chose to include capitalized software in capital expenditures” whereas “Microsoft responsibly classifies all such development costs … which improves the quality of its reported cash flow from operations” (the term responsibly says it all…). For Luigi Paraboschi, affordability is a key criterion: if your P&L can afford it, it is better to expense.
In summary, if you work in IT, regardless of whether your company capitalizes or expenses software development, you should still be able to understand the underlying mechanics. Sooner or later, somewhere along the line, from investment planning and budgeting to cost management and chargebacks, you will hear a CIO, a product manager, a PMO Director or a financial controller bring up the subject. So, as the saying goes, “mind the gap!”
- Capitalization and Amortization of Software Costs (Putra), 2009
- Capitalization of Software Development Costs: A Survey of Accounting Practices in the Software Industry (Georgia Tech, College of Management), 2006
- An Introduction to IT Project Financials – Budgeting, Cost Management and Chargebacks (Michael Gentle), 2010
I would like to thank Craig Larman (author, management consultant and agile specialist), Suraj Nekram (CEO of SteelGlass Consulting, New Jersey), Eugene Nisker (CEO of Evident Point Software in Vancouver) and Luigi Paraboschi (VP of Finance at HP in Geneva) for their help in polling their clients on whether they capitalize or expense their software development costs. Extended thanks go to both Craig and Luigi, who went one step further and provided me with lots of additional information on the subject, which enabled me to refine the key messages. Finally, though I never spoke to him at all, Putra’s article on Capitalization and Amortization of Software Costs (see Further Reading above) proved invaluable in tying it all together.