RGCI - FASB Proposed Change Impacting Cost Accounting for Software

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:

  1. Management has authorized and committed to funding the software project.
  2. 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:

  1. The software being developed has novel, unique, unproven functions and features or technological innovations.
  2. 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.

Written by John C. Shire, CPA

John C. Shire, CPA John is a Director with Redstone Government Consulting, Inc. providing government contract consulting services to our clients primarily related to the DFARS business systems, CAS Disclosure Statements, and DCAA/DCMA compliance preparation, advisory, and defense. Prior to joining Redstone Government Consulting, John served in a number of capacities with DCAA/DCMA for more than 30 years. Upon his retirement, he was based in Texas as an SES-level Corporate Audit Director for DCAA, managing a staff of 300 auditors at one of the largest DOD programs. Professional Experience John began his career in the late 80s working in the Clearwater, FL audit office and over the next three decades he progressed through a number of positions within both DCAA and DCMA with career highlights as DCAA Program Manager at Ft. Belvoir, Chief of Technical Programs Division, Deputy Assistant Director-Policy, Director of the DCMA Cost and Pricing Center, the SES-level Lockheed Martin Corporate Audit Director, and Director of Integrity and Quality Assurance. John’s three decades of experience in performing and leading DCAA auditors and DCMA reviewers provides a wealth of expertise to our clients. John’s role, not only in the performance of audits, but also in the development of audit policy affords him unique insights into the defense of audit findings and the linkage of audit program steps to the underlying regulatory framework. He is an expert in FAR, DFARS, and other agency acquisition regulation, as well as a subject matter expert in the Cost Accounting Standards having reviewed and provided audit feedback on many of the largest and most complex cost accounting practices during his tenure with the DCAA. John’s tenure with DCAA and DCMA came at a critical time during each agency’s history where a number of changes were occurring such as the response to the ICS backlog, development of audit approaches to the DFARS Business Systems and implementation of new audit initiatives as a result of Congressional oversight through the NDAA process. John’s leadership at the DCMA Cost & Pricing center saw oversight of all major DOD pricing actions, leadership of should cost review teams, the Commercial Pricing group and many other areas of strategic value to our clients. His involvement in these and other Agency initiatives is of great value to our clients due to his in depth understanding of DCAA and DCMA’s internal policy directives. Education John holds a Master of Business Administration and a B.A. in Accounting from the University of South Florida. Certifications Certified Information Systems Auditor State of Alabama Certified Public Accountant

About Redstone GCI

Redstone GCI is a consulting firm focused on fulfilling the needs of government contractors in all areas of compliance. With a singular mission to help contractors through the multiple layers of “red tape,” we allow contractors to focus on what they do best – support their mission with the U.S. Government. We are home to a group of consultants made up of GovCon industry professionals, CPAs, attorneys, and retired government audit and acquisition professionals.

Our focus and knowledge of audit and compliance functions administered by DCAA and DCMA will always be at the heart of what we do. However, for the past decade, we’ve strategically grown to support other areas of the government contractor back-office with that same level of focus and expertise. We’ve added expertise in contracts management, subcontract administration, proposal pricing, various software systems, HR and employment law, property administration, manufacturing, data analytics/reporting, Grant specialists, M&A, and many other areas. When we see a trend in the needs of contractors, we act to ensure we can provide the best expertise in the market to fulfill those needs.

One thing our clients can be certain of is that with the Redstone GCI Team in your corner, there is no problem too big and no issue too technical for our team to tackle.

Topics: Compliant Accounting Infrastructure, Incurred Cost Proposal Submission (ICP/ICE), DCAA Audit Support, Federal Acquisition Regulation (FAR)