Software Cost Accounting

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. A budget?is not spendable money since it is not a currency. It allocates 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 company's substantial assets, like the plant, property, equipment – and IT systems. The CAPEX number represents these IT systems. The cost color of money in a business is OPEX. OPEX?represents day-to-day running expenses whose effects can be measured quickly. Unlike an?asset, an operational expense has no intrinsic value. It’s just that – a one-time expense.?

Two types of software 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 probable completion of the project.? 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.

The accounting guidelines are completely different for software sold to third parties.? 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 it 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, regardless of the business size or 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 regarding 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 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.
• As noted in paragraph 350-40-25-3, data conversion costs will be paid as incurred.
• Internal and external training 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:

• The preliminary project stage or evaluation phase establishes the project's technical feasibility. ?These are essentially R&D costs and are charged to OPEX because there would be no asset to speak of if the project ended here.
• Software development or application configuration phase. All development and configuration work after 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, 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 are blurred when done by collaborative teams.
• Production upgrades or enhancements are capitalizable. Maintenance and bug fixing are not, despite having development costs. This is because the former significantly enhances the asset's value while 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 into this further 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”, we are really saying that they are capitalizable because of their?outcome, in that they are being used to build a wholly-owned asset that 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 how 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 they cannot be applied directly to iterative or agile development with its collaborative approach, short cycles, and absence of a big upfront design. This means 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 several 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 that can be capitalized, which generally will be less than under waterfall’s detailed program design approach. This is because the initial development is done during iterations?before reaching technological feasibility. In contrast, in waterfall, all development is done?after?technological feasibility (which once again underscores the earlier point that it is the outcome rather than the activity that 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 than waterfall, which is heavily front-loaded with OPEX before 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, but 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 accounting 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 tasks 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 in interpreting how to map the iterative work that happens throughout an Agile project lifecycle and is becoming an increasingly urgent issue.?

Minimizing Capital Expenses and Tax Burden

As mentioned at the start of this article, some companies capitalize on 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, often based on concurrent engineering and cross-functional teams. The norm for product development companies is to expense IT (see 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 on their software development).

• IT departments?and their financial controllers generally don’t view IT as R&D; for example, 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 low total project cost, a short useful life, and a short time between technological feasibility and the completion of software development. I polled several 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 showed?that over 80% of IT departments capitalize on their software development. I have worked far more with IT departments that capitalize than those that 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. In contrast, 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.