Money comes in many colors. Green here in the United States. Much prettier colors around the world. There is a saying in the project management business that money comes in two colors - Green and Blue. Green money has an actual dead president on one side. Presidential faces are on our money. The presidents are always dead presidents. Blue money, is referred to as budget. Budget is not spendable money since it is not actually currency. It is allocated funds to the budget for the project.
But in the software development world, the domains of IT, there are two other colors of money. CAPEX and OPEX. CAPEX is expenditures that generate future benefits. CAPEX represents the substantial assets of the company, like the plant, property, equipment – and IT systems. It's these IT systems that are represented by the CAPEX number. The cost color of money in a business is OPEX. OPEX represents day-to-day running expenses whose effects can be measured within a short timeframe. Unlike an asset, an operational expense has no intrinsic value. It’s just that – a one-time expense.
There are two types of software that are developed for a business: 1) internal-use software, and 2) software developed to be sold, leased or marketed (“software to be sold”). The accounting and capitalization requirements for these two different types of software are very different. Here is a high-level comparison of how each type of software is capitalized.
For internal use software, there are three stages defined by accounting guidance: 1) preliminary project phase (i.e. planning, evaluating alternatives, conceptual formation); 2) application development (i.e. design, coding, integration with hardware), and; 3) Post-implementation phase (i.e. testing, maintenance). The capitalization of costs should start after the preliminary project phase and is contingent on management committing to funding the continued development of the software, and the completion of the project being probable. Costs should cease to be capitalized after the project is substantially finished (generally, close to the start of the post-implementation phase). All costs outside of this capitalization window should be expensed as incurred. The costs qualifying for capitalization are also restricted, but that is a whole blog unto itself.
For software to be sold to third parties, the accounting guidelines are completely different. Accounting guidance requires that costs associated with the development of software to be sold are charged to expense as incurred, until the point in which technological feasibility has been established. Technological feasibility is established once an entity has completed planning, designing, coding, and testing the software to ensure that the software will work for its intended function. As a general guideline, sometimes technological feasibility is considered established once software enters beta testing. Capitalization must cease when the software is ready for general release to customers. Accordingly, the window for capitalization is extremely small, and often, startup companies expense all costs during development.
Accounting Rules for IT, Including the Development of Software
There are always rules in any business. Accounting rules are always present, no matter the business size, it's status as a public or private firm.
So what do the accounting rules cover? The answer depends on which phase the software development is in. Let's start with that dreaded waterfall development process. Agile will come next, but waterfall (and of course the term is no longer allowed in US DOD procurement, but it is an acceptable accounting term), provides the easiest framework for software development cost accounting.
US GAAP is very explicit in terms of accounting for software development costs (expensed versus capitalized).
- Internal and external costs incurred during the preliminary project stage shall be expensed as they are incurred.
- Internal and external costs incurred to develop internal-use computer software during the application development stage shall be capitalized.
- Costs to develop or obtain software that allows for access to or conversion of old data by new systems shall also be capitalized.
- Training costs are not internal-use software development costs and, if incurred during this stage, shall be expensed as incurred.
- Data conversion costs, except as noted in paragraph 350-40-25-3, shall be expensed as incurred.
- Internal and external training costs and maintenance costs during the post-implementation operation stage shall be expensed as incurred.”
In the waterfall accounting process there are three phases in software development:
- 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.
It's never this simple of course, no matter how much we'd like it to be. For example:
- Enterprise software licenses are CAPEX, but the annual maintenance costs are OPEX.
- Functional design is OPEX and technical design is CAPEX. The connections between functional design and technical design is blurred when done by collaborative teams.
- Production upgrades or enhancements are capitalizable. 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 an IT asset, which generates long-term value, while the latter is a one-off with no alternative future use.
- T&E (Travel and Expenses) are normal 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, that is, it doesn’t sit on the company’s balance sheet. We’ll go more into this further on when talking about cloud computing. This, by the way, is the financial attraction to SaaS.
One critical concept here is that it is not the work activity by itself that is capitalizable (development), but 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.
There is enough latitude here to drive a truck through 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?
So Now What About Agile Development Processes
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 detailed 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 a 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 program 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).
FASB accounting standard SOP 98-1: Accounting for the Costs of Computer Software Developed or Obtained for Internal Use (ACC Section 10,720) provides legal guidance on the appropriate way to account for corporate investment in software. In a waterfall method of software development with phased gates where all of the feasibility, analysis and design activities and task are completed before development begins and individual team members track their time to specific work breakdown tasks associated with discrete project phases (i.e. a preliminary phase of feasibility analysis and high-level design; a development phase of development, testing, implementation, integration and deployment; and a deployment phase of stabilization and maintenance); this accounting standard provides clear guidance. However, as Agile gains prominence, the phased gate language results in significant confusion and challenges of interpreting how to map the iterative work that happens throughout an Agile project lifecycle and is becoming an increasing urgent issue.
Minimizing Capital Expense and Tax Burden
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, e.g. software vendors) and companies whose core business is not IT, e.g. 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 that 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.
Resources
- 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
- Accounting for Software Development
- Why Should Agilest Care About Capitalization?
- FASB Section 10,720 – Accounting for Internal Use Software
- FASB Handbook of Federal Accounting Standards and Other Pronouncements, as Amended
