Technology Spotlight — Accounting for the Development of Generative AI Software Products (October 7, 2024)

The development of AI infrastructure foundation models is based on machine learning algorithms that consider linguistic rules and statistical models so that a computer can “understand” the natural language of a user’s input prompt.

Entities that intend to develop a foundation model may incur the following costs:

• Software developer costs — Internal and external labor costs related to the development of the AI infrastructure code, time-intensive training, validation of outputs, and optimization activities.
• Data acquisition costs — Foundation model developers might incur costs to acquire the vast amount of data they need to develop foundation models that perform various NLP tasks and produce a wide range of responses.
• Computation resources — High-performance hardware must be used to train a foundation model. An entity could choose to purchase either specific hardware (e.g., computers with powerful CPUs, GPUs, or RAM) or platform or infrastructure services from third parties (i.e., cloud services) that offer the same computational scalability.
• Storage costs — Because of the amount of data needed to train and maintain a foundation model, entities may incur significant storage costs. An entity could choose to purchase or lease hardware for storage or to purchase cloud storage services from third parties.

Generative AI applications interact with and rely on a foundation model to generate outputs on the basis of user prompts. The dependency of AI applications on foundation models can be thought of as similar to the reliance of traditional software applications on operating systems. As a large-scale, pretrained language model, a foundation model serves as an engine that software developers train and calibrate for specific scenarios when creating their own generative AI applications. Currently, a limited number of companies have developed foundation models and some have provided access to this technology as open-source software or software sold as part of a hosting arrangement.

Because of the complexity of foundation models, the development of this technology is expected to be labor- and resource-intensive. We therefore expect most generative AI application developers to leverage existing foundation models in their applications rather than create their own. However, foundation models can vary in size and some entities might develop a private foundation model or LLM that is trained only on entity-specific data.

In addition to the data and training costs, an entity may also incur traditional software development costs (e.g., costs related to developing the software application user interface, infrastructure, graphics, and content) when creating a generative AI application. These costs may also be subject to capitalization or expense under ASC 985-20, ASC 350-40, or other U.S. GAAP.

When AI software is developed for internal use, a significant portion of the software development costs may be incurred during the preliminary project stage. Unlike ASC 985-20 (discussed further below), ASC 350-40 does not require the establishment of technological feasibility2 for capitalization but does have other requirements for capitalization depending on the stage of development. Generally, development costs incurred during the application development stage are capitalized, while costs incurred during the preliminary project stage and postimplementation-operation stage are expensed as incurred.

The following are some indicators of when an entity is in the preliminary project stage and when costs should therefore be expensed as incurred in accordance with ASC 350-40:

• The entity is considering allocating resources (i.e., developers, financial budget) between different projects (e.g., different AI applications or other software projects).
• The entity is still determining the performance requirements for the AI application or the infrastructure requirements necessary for the application to operate.
• The entity is holding ongoing conversations with vendors (e.g., foundation model vendors, hardware vendors, cloud computing vendors) to determine which products are best aligned with the entity’s software performance requirements.
• The entity is still exploring alternatives related to achieving the performance requirements identified (i.e., using internal software developers to train foundation models versus hiring third-party consultants).
• The entity is determining whether there is an existing technology for developing a specific generative AI application to meet the identified performance requirements.

The preliminary project phases for many AI applications and software projects may be longer than those for other software development projects given the use of new and advanced technologies as well as the emergence of high-risk development issues that could affect the successful completion of the project.

Once the preliminary project stage is complete and the application development phase commences, entities developing AI applications will need to identify and capitalize the direct internal and external costs incurred to develop the AI application. When both foundation models and AI applications are being developed or implemented at the same time, entities will need to carefully track internal and external costs to ensure they are appropriately deferred or capitalized in accordance with the guidance in ASC 350-40. In addition, the development and implementation of foundation models and AI applications may involve new activities (e.g., training) performed by employees who have not historically tracked time spent on developing software. In these circumstances, entities may need to create new processes and controls to track these costs accurately.

As a result, minimal costs tend to be capitalized when software is developed to be marketed or sold externally unless the costs incurred are subject to other GAAP.

Under ASC 350-40, costs incurred to implement a hosting arrangement that is a service contract would be subject to the same recognition and measurement guidance as costs incurred to develop or acquire internal-use software. However, any costs deferred in accordance with this guidance would be presented in the same manner as any prepayments made for the underlying service.

Costs incurred to acquire data from a third party should be evaluated to determine whether it is appropriate to capitalize the costs as a separate intangible asset. The guidance in ASC 350-30 would apply to intangible assets that are acquired individually or as a group of other assets (that do not constitute a business), and ASC 350-30-25-1 states that “[a]n intangible asset that is acquired either individually or with a group of other assets shall be recognized.” Further, ASC 350-30-25-43 states the following regarding the acquisition of intangible assets:

Acquired data will lack physical substance and will most likely be acquired as part of a contract that defines the rights controlled by the entity. In these cases, the acquired data are likely to meet the definition of an asset (because the data are separately identifiable and provide an entity with a present right to future economic benefits) and could be recognized separately as an intangible asset. Entities would need to determine the useful life of the acquired data and perform an impairment assessment in accordance with ASC 350.

 

Connecting the Dots

ASC 350-30-25-4 refers to the asset recognition criteria in FASB Concepts Statement 5. However, as noted in footnote 3, ASU 2024-02 removed the references to the concepts statements throughout the Codification. Further, the definition of an asset in FASB Concepts Statement 5 was amended by FASB Concepts Statement 8. The definition of an asset in paragraph E17 of FASB Concepts Statement 8, Chapter 4,4 is as follows:

An asset has the following two essential characteristics:

1. It is a present right.
2. The right is to an economic benefit.

A present right of an entity to an economic benefit entitles the entity to obtain this benefit from the right and to restrict others’ access to it. We believe that rights to data acquired from a third party would generally meet the definition of an asset. Further, while there are differences in the definition of an asset under the two concept statements, the differences are not expected to significantly change what does and what does not represent an asset. Accordingly, we believe that rights to data acquired from a third party would generally meet either definition of an asset.

Although costs incurred to acquire data from a third party would generally be capitalizable as an intangible asset, data acquisition costs would be expensed as incurred under ASC 730-10 if the data will be used in research and development activities and do not have alternative future uses.5 Such data costs would include those incurred for a specific software development project that is within the scope of ASC 985-20 for which technological feasibility has not been established. This is because, as noted above, costs incurred to develop technological feasibility are considered research and development activities within the scope of ASC 730-10. ASC 730-10-25-2 states, in part:

Data may also be acquired for a specific software project that is being developed for internal use and does not have an alternative future use (e.g., other software projects). In this case, rather than being a separate intangible asset, the data costs may be direct external costs incurred to develop internal-use software within the scope of ASC 350-40. Specifically, an entity could purchase data to train generative AI applications, resulting in the creation of new functionalities. If the AI software project is in the application development stage, it may be appropriate to capitalize the data acquisition costs as direct costs incurred during that phase. Alternatively, as discussed further below, if the data and resulting training were only necessary to maintain the existing features or functionality of the generative AI application, capitalization would not be appropriate because the costs would be akin to maintenance costs. Further, any costs incurred in the preliminary project phase of development should be expensed as incurred.

If acquired data have an alternative future use (as discussed above) and are separately recorded as an intangible asset in accordance with ASC 350-30, we do not believe that the subsequent amortization of the intangible asset would be included as a cost eligible for capitalization under the internal-use software guidance. In such circumstances, the subsequent amortization would not be considered a direct cost incurred during the application development stage and would therefore not be within the scope of ASC 350-40.6

Upgrades and enhancement to generative AI applications that are sold or marketed externally, and that are within the scope of ASC 985-20, would be subject to the same capitalization threshold as the initial product development (i.e., an entity is required to establish technological feasibility of the upgrade or enhancement to capitalize associated costs).

Maintenance activities would be expensed as incurred for all software. ASC 350-40 does not define the term “maintenance,” but ASC 985-20-20 defines it as follows:

A key consideration related to incurring data costs to train the AI software after initial deployment is whether additional training results in the creation of new functionality (e.g., whether the AI application can perform a different task) or whether ongoing training is necessary to retain the relevance of the AI application (e.g., maintain its intended functionality). Data and associated training that are intended to keep an AI application current or relevant would most likely be considered maintenance. Unless the costs are separately capitalizable as an intangible asset, such costs would be expensed as incurred.

In contrast, training that creates new functionality might be considered an upgrade or enhancement. Therefore, entities will need to determine whether the additional fine-tuning they are performing maintains the current software features of their generative AI application or whether the fine-tuning introduces additional software features that did not previously exist. This would dictate whether the data costs incurred to perform the fine-tuning should be capitalized as costs incurred to develop a software upgrade, expensed as software maintenance, or evaluated for capitalization separately as an intangible asset.

If an entity enters into a hosting arrangement with a vendor to leverage the vendor’s computation or storage capabilities, it is likely that the arrangement will be accounted for as a service arrangement. Typically, in such circumstances, (1) the entity does not have “the contractual right to take possession of the software at any time during the hosting period without significant penalty”7 or (2) it is not “feasible for the [entity] to either run the software on its own hardware or contract with another party unrelated to the vendor to host the software.”8 Accordingly, the costs incurred to implement third-party infrastructure or storage services would be evaluated for capitalization in accordance with ASC 350-40 and, if capitalized, would be deferred as a prepaid asset and recognized over the contract period (as well as over periods for which contractual renewals are reasonably certain to be exercised). Note that ongoing costs to use or maintain the third-party infrastructure or storage services would not meet the deferral criteria.

In addition, as noted above, AI applications typically need to be developed to work with one or more AI foundation or LLM models. An entity that enters into a hosting arrangement with a vendor to purchase a foundation model will need to determine whether it has (1) purchased or licensed software or (2) purchased a service arrangement. The entity must perform this assessment regardless of whether the foundation model will be used to create a generative AI application for internal use or whether it will be sold as a hosting arrangement or an on-premise license. We expect that most entities will determine that the foundation models or LLMs they acquire will be through a service contract, which could be accounted for as a prepaid asset if an up-front payment is made for the future use of the functionality.