Accounting for Internal-Use Software: A Practical Application
As companies increasingly employ software engineers to develop customized programs and software to perform internal functions (e.g., ERP systems, CRM systems, customer interfaces), one often overlooked challenge is determining whether the associated costs should be capitalized or expensed.
The phase of a project, along with the type of cost, plays a critical role in determining whether the costs can be capitalized. Companies may also encounter a disconnect between the data maintained for managing software development and the data required by the accounting department to determine whether the activities actually qualify for capitalization.
Here are two key things for companies to consider when evaluating internal use software development costs.
To address this disconnect between the reality of software development and the accounting literature, accounting teams should implement processes that clearly identify and document changes in project phase.
1. Documentation of project phase
US GAAP outlines three phases of an internal-use software project lifecycle: preliminary project, application development, and post-implementation.
During the preliminary project phase, management explores alternatives and determines the path forward for the software. Costs incurred during the preliminary project phase are expensed as incurred. Decisions made during this phase include determining the performance requirements and the technology required, and selecting the right vendors or consultants to assist. A project enters the application development phase once these decisions have been made and funding has been approved. In this phase, time spent on technical activities are capitalized, with some exceptions. In the post-implementation phase, the software is ready for its intended use. Costs are expensed, with the exception of time spent to add additional functionality that was not available at project implementation.
The point at which a project changes phases is a critical factor in determining the accounting treatment. But today’s software engineers are more agile, continuously planning and changing course as software development progresses, rather than following the linear project phase approach that US GAAP envisioned when it issued the accounting guidance. As a result of this fluid approach to developing software, which rarely follows the path set in an initial end-to-end plan, engineers are less likely to maintain documentation of when an overall project was authorized or when funding was approved.
To address this disconnect between the reality of software development and the accounting literature, accounting teams should implement processes that clearly identify and document changes in project phase. One solution is to install a steering committee comprised of the software project leads and accounting team members. This committee will discuss project status quarterly and address items such as approval of projects, project status, changes to scope and timeline, allocation of funding, and any new software being considered. Another solution is to modify existing tracking mechanisms to include project status details required by accounting (e.g., adding project status fields to excel-based project status trackers or adding additional required fields when setting up a project in the company’s project management tool).
2. Detailed time tracking
Time spent by software engineers qualifies for capitalization when it directly relates to the technical development or enhancement of software. During the application development and post-implementation phases, certain activities will meet this hurdle, while other activities (e.g., training, data conversion, and application maintenance) will not, and therefore must be expensed.
Often, software engineers are not provided with training on how to track and categorize time spent on various software development activities and, as a result, simply record their time using free text. This approach makes it difficult for the accounting team to organize data and assess whether the activities are capitalizable. For example, during the application development phase, a software engineer may not know that time spent on coding is capitalizable, while time spent on data conversion is expensed.
To facilitate the accounting team’s identification and evaluation of activities that qualify for capitalization, companies should provide training for project leads and software engineers focusing on the importance of detailed time tracking, including the level of detail required. This training can provide an open forum to ask questions and create a line of communication between accounting and the software engineers. A document detailing the activities that qualify for capitalization versus those that are expensed can also be shared for the engineers to reference on a go-forward basis. A system-based option is to create a selection field for each time submission that requires the selection of ‘cap-ex’ or ‘op-ex,’ prompting users to consider and identify the type of activity.
Although the decision of what hours qualify for capitalization is ultimately made by the accounting team, the data used to make this decision is obtained from a company’s software engineers. Training them on the importance of time tracking and maintaining adequate documentation will result in a more efficient process to determine capitalizable hours and, therefore, more accurate accounting.