Normally, I make numerous references to the Federal Acquisition Regulations (FAR) when writing. However, there is only one FAR reference for this topic, and then we must turn to the Accounting Standards Codification (ASC). In this case, that single FAR reference is FAR 31.201-2(a)(3).
The topic of our discussion today is “software.” While you may be able to hold the media that the software (i.e., code) has been placed on, the software itself is not tangible. This makes software an intangible item or asset. FAR and even the Cost Accounting Standards (CAS) do not specifically address the necessary cost accounting for software costs impacting government contracts.
I wrote and made available a whitepaper on the way I see software should be accounted for under government contracts, “Cost Accounting for Software Related Costs To Be Sold, Leased, or Marketed.” Thus, the reason for this article. The Financial Accounting Standards Board (FASB) is proposing a change to the ASC that will impact my whitepaper at least a little – so I wanted to bring that to your attention. The FASB is seeking Public Comments on Targeted Improvements to Internal-Use Software Guidance. Comments are due by January 27, 2025.
A Little Introduction
First, the Federal Acquisition Regulations (FAR)
Because neither the FAR nor CAS specifically addresses the accounting for self-constructed intangible assets (in this case, software), we have to turn to the ASC (i.e., Generally Accepted Accounting Principles – GAAP) as directed by FAR 31.201-2(a)(3). FAR 31.201-2(a)(3) provides that when determining whether a cost is allowable, the amount of the cost must be measured and assigned as an expense based on “[s]tandards promulgated by the CAS Board, if applicable, otherwise, generally accepted accounting principles and practices appropriate to the circumstances.”
Second, the Accounting Standards Codification (ASC)
My whitepaper deals with software to be sold, leased, or marketed. So, why are we concerned with a change to the accounting for internal use software? Well, the drafters of the ASC must have gone to the FAR school of clarity. It turns out that while ASC 350-40-15-4 provides that the guidance in this subtopic does not apply to software sold, leased, or otherwise marketed, ASC 985-20-55-2 requires software that meets specific requirements to be accounted for as internal-use software under ASC 350-40. Software to be sold or leased as part of a hosting or service arrangement, including Software as a Service (SaaS), is accounted for as internal use if the customer does not have the right to take possession of the software and the customer would not have the feasibility to run the software on its own. Yes, I lifted these words directly from my whitepaper, but as I am the author of both, I do not believe I need the quote and give myself credit.
Third, the Impact of Software
Seeing as software, whether sold or used internally, has a significant impact on today’s businesses, I believe I would have written this article even if my whitepaper had not been impacted. The FASB even states in the proposed change that “virtually every entity is affected by the accounting for software costs.”
What is the Proposed Change?
Currently, ASC 350-40-25 provides that software be accounted for based on a phased approach as follows:
- “Preliminary Project Stage” the costs incurred shall be expensed as incurred.
- “Application Development Stage” the costs incurred are to be capitalized.
- “Postimplementation-Operation Stage” the costs incurred shall be expensed as incurred.
The FASB states that this current “guidance was issued when software was developed using the waterfall method; therefore, the current guidance does not contemplate other methods of software development.” Today, most software development projects are more of an iterative process (i.e., the agile method), which does not map well to the current ASC guidance.
The FASB is proposing to make targeted improvements to Subtopic 350-40. “The proposed amendments would specify that an entity would be required to start capitalizing software costs when both of the following occur:
- Management has authorized and committed to funding the software project.
- It is probable that the project will be completed, and the software will be used to perform the function intended (referred to as the ‘probable-to-complete recognition threshold’).
In evaluating the probable-to-complete recognition threshold, an entity may have to consider whether significant uncertainty is associated with the software’s development activities (referred to as ‘significant development uncertainty’). Factors to consider in determining whether there is significant development uncertainty include whether:
- The software being developed has novel, unique, unproven functions and features or technological innovations.
- The entity has determined what it needs the software to do (for example, functions or features), including whether the entity has identified or substantially revised [d] the software’s significant performance requirements.
The proposed amendments would require an entity to separately present cash paid for capitalized internal-use software costs as investing cash outflows in the statement of cash flows.
Additionally, the proposed amendments would supersede the website development costs guidance and incorporate the recognition requirements for website-specific development costs from Subtopic 350-50 into Subtopic 350-40.”
In my opinion, the targeted improvements proposed by the FASB are a step in the right direction.
What is the Concern for Government Contractors?
Believe it or not, it comes down to audit risk. Your financial auditor’s audit risk is that you started the capitalization of software costs too soon. Why, you ask? Well, capitalizing the software cost moves the expenses from the income statement to the balance sheet, resulting in a better-looking bottom line for the current fiscal year. It is likely a favorable outcome for many of the executives. Thus, there is an audit risk for the financial auditors.
Now then, your government auditors (our friends at the Defense Contract Audit Agency – DCAA) see their audit risk as being you started the capitalization of software cost too late. Starting the capitalization later allows more of the current fiscal year expenses to be charged to government contracts. We can’t have the taxpayers paying for something too soon. Yes, it is just a timing issue.
I would like to say that both your financial and government auditors are going to take a reasonable look at your business decision based on the requirements in ASC and hopefully be fully supportive of your decision. However, I do not often see the reasonable side of government auditors (especially DCAA auditors). This is likely the case, at least for me, because I do not get calls when government auditors are being reasonable. OK, let’s get back on track here.
These two opposing viewpoints on audit risk are likely to bring your decision on when to start capitalization under review. This means you need to have a well-supported and documented decision as to when and why you started capitalization of your software. Yes, I boldened “documented” for a reason. Contemporaneous documentation carries much greater weight with auditors than any story developed after the fact.
How Can Redstone GCI Help?
Redstone GCI can assist your company by helping you understand the Federal Acquisition Regulation (FAR) requirements and drafting essential policies and procedures. We provide training to your staff, either on-site or virtually, to ensure they are well-prepared. Additionally, we review your contemporaneous documentation supporting capitalization for any areas of concern and perform assessments of your software capitalization practices.