Accounting for Internal-Use Software (#394)

Changes to the Accounting for Internal-Use Software

The accounting for internally-developed software used to be built around project stages, where costs could be capitalized once you reached a certain development stage. That worked fairly well when software development followed a linear path from start to finish. But projects don’t always work that way anymore. Project cycles tend to be a lot shorter, with lots of incremental releases. This makes it more difficult to use the old guidance.

The new guidance replaces the old approach entirely, and uses a fairly simple recognition threshold to decide when to capitalize development costs. In essence, you start capitalizing only when two conditions are met. First, management has authorized and committed to funding the project. Second, it’s probable that the project will be completed and that the software will be used for its intended function. That second condition can be difficult. The standard says that capitalization cannot begin if there is significant development uncertainty. In effect, you have to determine whether the project is still too uncertain to justify putting development costs on the balance sheet.

There are two indicators of development uncertainty. One is technological uncertainty. If the software includes technological innovations or novel, unique, or unproven features, and that uncertainty has not yet been resolved through coding and testing, then the project has not yet crossed the capitalization threshold. The other indicator is uncertainty about performance requirements. If you haven’t yet identified what the software needs to do, or if those significant requirements are still being substantially revised, then capitalization has to wait.

So, the accounting model is now more focused on substance than on labels. Instead of arguing about whether a project has officially entered an application development stage, you simply have to ask, have we committed to this project, and have we reduced the uncertainty enough that completion is probable?

That change is especially important for agile development. Under older guidance, agile teams often had trouble pinpointing when one stage ended and another began, because planning, coding, testing, and revision can all overlap. The new model is designed to work better in that environment by focusing on the threshold for recognition rather than on a rigid sequence of stages.

Even so, any costs incurred before the capitalization requirements are met have to be expensed as incurred. Early conceptual work, such as feature discussions, unresolved technical issues, and other uncertain development efforts are all expensed until the recognition threshold has been reached.

Once the threshold is met, the list of capitalizable costs is fairly specific. It includes the external direct costs of materials and services used to develop or obtain the software. It includes the payroll costs for employees who are directly associated with the project, but only for the time they spend directly on it. It also includes the costs to develop or obtain software for the conversion of old data for the new system.

There are also some costs that are not capitalized. Training costs are expensed as incurred. General and administrative costs are not capitalized. Maintenance is expensed as incurred. So, capitalization is not a blanket rule for all project spending. It applies only to eligible items.

This means that project accounting becomes very important. You have to distinguish between direct software development activities and all the surrounding activities that may support a project but do not qualify for capitalization. Without good time tracking and vendor invoice coding, it becomes much harder to apply the guidance correctly.

And then there’s the issue of upgrades. If a modification gives the software additional functionality, then those costs can be evaluated for capitalization under the same general model. If you can’t separate maintenance from minor upgrades on a reasonably cost-effective basis, then you should expense those costs as incurred. And, if an outside contract combines maintenance with upgrades, then the contract cost has to be allocated so that the maintenance element is charged to expense.

Capitalization ends when the software is substantially complete and ready for its intended use. This point is reached no later than the completion of all substantial testing. After that point, further costs are generally expensed, unless they qualify as a separate enhancement.

There is also an impairment dimension. If it later becomes no longer probable that the software project will be completed and placed in service, then no further costs are capitalized. At that point, you have to evaluate the existing asset for impairment.

There are some warning signs for this, including a lack of project spending, programming problems that can’t be resolved on a timely basis, significant cost overruns, or a decision to switch to third-party software instead of finishing the internally developed system.

This guidance also applies to the development of a website. For example, any fees paid to develop a website can be capitalized once the recognition threshold is met. It might also be possible to capitalize the cost of the initial graphics for the site. But search engine registration costs are treated as advertising and expensed right away, while website hosting fees are also expensed over the usage period.

The basic lesson here is that software capitalization is no longer driven by a checklist of project stages. Instead, it’s driven by a recognition threshold. Management has to authorize and commit to a project, and it has to be probable that the project is going to be completed. If there are major technical uncertainties, or if the requirements are still unsettled, then capitalization has to wait.