Board of Governors of the Federal Reserve System

Appendix D. Software

D.1 Accounting Guidance for Internal Use Software and Cloud Computing Arrangements

The following accounting guidance is provided to assist System financial accounting staff in determining the appropriate accounting treatment for internal use software, whether it is purchased from a vendor, internally developed, or significantly modified for use by the Federal Reserve Banks.¹ This guidance will also be used for recording charges associated with a cloud computing arrangement containing a software license element, if certain conditions are met and for the recognition of implementation costs associated with a cloud computing arrangement that does not contain a software license element. This information expands on the requirements in the Financial Accounting Manual (FAM)'s Chapters 1 (Section 4.21) and 3 (Sections 30.72, 30.78, 30.80, and 30.95) and further highlights the underlying accounting principles that relate to software assets and expenses.² The accounting treatment of costs incurred to purchase or develop internal use software is influenced by the intangible nature of the resulting assets, and the accounting recognition requirements are frequently different than those for tangible assets.

The costs incurred to develop, purchase, and install software must be carefully analyzed and independently evaluated to establish the proper accounting treatment based on all the relevant factors. The discussion that follows will assist those performing the analysis in using a uniform analytical approach when evaluating the events and related information associated with software development efforts to promote consistency in accounting treatment for like transactions.

In April 2018, the Reserve Banks adopted the Program and Project Management (PPM) Standard, which integrates the prior Technology Project Standard, Enterprise Program Standard, Business Case Justification Standard, Technology Project Management Standard, Software Development Framework, Application Development Estimation Framework, and Requirements Engineering Framework (REF). The single PPM Standard is aligned with industry-based standards and incorporates all aforementioned standards and frameworks. The PPM Standard is organized into three stages: Stage 1: Justification, Stage 2: Planning and Execution, and Stage 3: Transition and Closing.

Integral to performing a thorough analysis and determining the proper accounting treatment for software costs is having the requisite information about the contracts, agreements, and circumstances so that the derived accounting treatment is correct. This requires that an accounting staff member communicates with business areas and other affected Reserve Banks' accounting departments and vice versa to discuss all the relevant information, including cost data needed to establish the proper accounting for software assets. In cases where software development costs are related to System initiatives, the product and function offices likely will be part of the communications and will have additional relevant information that is needed to determine the proper accounting treatment for internal use software.

Board staff may also be consulted for assistance in the decision making process and considering the implications for financial reporting, or with emerging arrangements that are not addressed in this document. In certain situations, which are identified later, RBOPS Financial Accounting Policy and Reporting Section staff must be contacted for approval of FAM exceptions.

The analysis, conclusions, and rationale for the accounting treatment should be documented.

1. Capitalization thresholds

For an outlay to be capitalized, it should be material in value, which, for purposes of recognizing assets, is defined as equal to or greater than established capitalization thresholds. For software assets, the thresholds are $100,000 or more for internally developed software and implementation costs for cloud computing arrangements that does not contain a software license and $25,000 or more for externally purchased software. These thresholds are discussed in FAM Chapter 1, section 4.20 (Deferred Charges). The capitalization threshold for externally purchased software was lowered in 2005 to make this threshold consistent with other prepaid license fees. For internally developed software, information referenced in sections 3, 4, and 6 further explain what costs are to be capitalized and how to evaluate the asset unit.

2. Ownership of software

Every asset is an asset of some entity and that entity must control future economic benefits and regulate access to the benefit. The contract is usually the primary source for information about ownership. Contracts and agreements usually indicate who will have future economic benefit, and specify who has which legal rights, which enables determining ownership. Absent contracts or agreements that indicate ownership or rights, software ownership is determined by several factors that indicate control such as:

• The entity makes decisions about the software, including but not limited to defining requirements, and establishing implementation and decommission dates.
• The entity operates and provides daily support for the software.
• The entity controls granting rights to use the software.

In the Federal Reserve System, there is a designated entity, such as a Central Business Administrative Function (CBAF), Product Office, or Function Office that controls a software asset, thus the asset would be recorded on the books of the Reserve Bank hosting this entity or, absent the entity, the Reserve Bank that exercises this control over the asset, regardless of physical location of the software. The software may be installed on another Reserve Bank's hardware, a hardware platform that is operated by a third party vendor that was contracted for by a Reserve Bank, or an outside party's hardware.

As a result, software development may occur at one Reserve Bank, the software may be installed on hardware at another Reserve Bank, and a third Reserve Bank, hosting a CBAF for example, may control the software asset.

Software developed for release to an outside party that will be controlled by the outside party (the above ownership factors are met) is not considered internal use software and should be expensed as development occurs. This includes instances when FRB staff makes further modifications to the software at the request of the outside party, but then releases the modifications for support and operation by that third party.

3. Definition of the asset unit for software

The developed or purchased software (purchased software includes acquisition cost, as well as installation/integration costs) that provides economic benefit and otherwise qualifies to be capitalized is recorded as a single asset. When software development occurs over several years, however, and the software will be implemented in phases as elements, each element (a component or module) should be analyzed to determine whether it should be treated as a separate asset. Specifically, the element should provide economic benefit through distinct, substantive functionality; and meet the tests for materiality, ownership, and eligibility for capital treatment. If all the criteria are met, the element should be treated as a separate asset with a unique useful life determined from the analysis performed for section 9 and placed in service when substantially complete and ready for its intended use.

When the majority of elements associated with a long term software development project are treated as separate software assets, but an element costs less than $100,000, the accounting treatment for this element should be discussed with Board staff.

When identical software that is acquired is a bulk purchase of a number of low cost licenses that are licensed per server (for example software to be placed on many servers) or per user and individually are below the capitalization threshold, the bulk purchase can be capitalized as a single asset when it is material in value, that is $100,000 or more, and the license term is longer than one year.³ A subsequent purchase of the same software that is acquired under the same contract (quantity not originally specified or ‘up to quantity' is specified) and that does not meet the $100,000 threshold should be charged to current expense.⁴ Standard desktop utility software (such as word processing, electronic mail, and anti-virus software) and maintenance should be charged to current expense regardless of amount.

4. Cloud Computing arrangements

Cloud computing arrangements are hosting arrangements in which the customer of the software does not take possession of the software, but instead accesses and uses the software on an as-needed basis or by subscription. A customer that acquires a software license—including in a hosting arrangement that transfers a software license to the customer—recognizes an intangible asset (i.e., the software license) and a corresponding liability to pay for it over time (unless the license is prepaid).

As such, the Reserve Bank will record charges associated with a cloud computing arrangement containing a software license element if both the following conditions are met:

• The Reserve Bank has the contractual right to take possession of the software at any time during the hosting period without significant penalty,⁵ and
• It is feasible for the Reserve Bank to either run the software on its own hardware or contract with another party unrelated to the vendor to host the software.

If the arrangement contains a software license, Reserve Banks should account for the fees related to the software license element in a manner consistent with the acquisition of a software license. If the arrangement does not contain a software license, Reserve Banks should account for the arrangement as a service contract—typically by amortizing the service cost over the expected service period.

Certain cloud computing arrangements may have multiple elements such as implementation, set up, training, and data conversion costs in addition to license and service elements. All expenses should be carefully evaluated for capitalization purposes. Appendix D should be reviewed for guidance for costs including those resulting from training, data capture, and conversion activities.

Capitalized implementation costs for an arrangement that does not contain a software license should be amortized on a straight-line basis over the fixed non-cancellable term of the hosting arrangement.⁶

5. Improvements to existing software

Expenditures made to change existing software assets are considered either improvements or maintenance. Expenditures to existing software assets that meet the capitalization thresholds outlined in section 1 should be capitalized if the resulting improvement provides additional capabilities by meeting one of the following criteria:

• the quantity of output or operating efficiency of the asset is significantly increased, and
• the quality of output is significantly increased.

Improvements add functionality that the software previously did not have, incorporate new specifications, or involve a significant change to the original specifications and are typically termed releases or versions. Improvements should be recorded as separate assets with a unique useful life determined from the analysis performed for section 9. Costs incurred for maintenance such as fixes, patches, or updates such as increasing the field width, adding a comment field, and reformatting or adding reports are expensed.

The following table provides examples of expenditures and how they would be classified:

A specific software development project may include expenditures for improvements and maintenance that cannot be easily separated. One approach that can be used to separate these costs is a ratio that is based on the projected work hours for development activities for each type of work. Such a ratio can be applied to the development costs to determine the percentage of expenditures that should be capitalized. The basis for allocating costs should be defensible.

6. Replacement of existing software

A replacement is a substitution of the existing asset with a new asset. When the results of efforts to rewrite or improve the software are significant enough to be considered a replacement to the existing software and the expenditures meet the criteria in sections 1, 2, and 5, the costs are capitalized. Conversion of an application from a mainframe to a distributed platform is generally considered a replacement. Even though the application's functionality may not have changed, a significant alteration of the software occurs. The software code is converted to a different programming language, different operating systems and technologies are used, and different tools are used to manage the application.⁷ Because the former software asset is significantly altered, the net book value of the former software asset is removed from the books and expensed. The useful life of the replacement, therefore, should be unique based on the analysis performed using section 9.

In addition, if there is a replacement of an element of existing software and the expenditures meet the criteria in sections 1, 2, and 5, then the former element, if previously treated as a separate asset, is removed from the books and expensed. The new element would be capitalized in accordance with section 5.

When the former software asset is replaced by new software whose costs do not meet the capitalization threshold and are expensed, the net book value of the former asset is removed from the books and also expensed.

7. Capitalizable costs

Costs incurred during software development or implementation of a cloud computing arrangement are capitalized or expensed depending on the project stage. These stages are commonly described as preliminary, development, and post-implementation.

The preliminary stage includes activities related to

• the conceptual formulation of alternatives
• the evaluation of alternatives
• the determination of existence of needed technology
• the final selection of alternatives
• the selection of vendors and consultants
• and the prototype or proof of concept.

Capitalized: None

Expensed: All costs associated with preliminary stage activities.

The development stage includes all the activities related to designing the chosen path including configuration and software interfaces, coding, testing (to include all testing prior to user acceptance testing), installation of software on hardware, preparation of code to convert old data, and development of user guides.

Capitalized:

• external costs of materials and services (for example, consulting fees), salary and retirement and other benefit costs of employees directly associated with the project as outlined in section 8
• preparation of developer guides
• costs associated with time spent specifically to oversee developers (programmers), if determinable
• expenditures for integration materials and services, which include consultant fees and salary and retirement and other benefit costs of employees directly associated with the integration effort. Integration efforts include customizing the infrastructure/operating system software so that the developed application will operate on the infrastructure hardware and within existing network environments. (In some cases integration costs may involve the components, installation, and related interconnectivity of hardware, which may require the allocation of integration costs between hardware and software.)
• travel costs for staff, consultants, or vendors should be capitalized if directly related to the software development and, when required, in conformance with applicable Bank travel policies or contract requirements for consultants and vendors
• implementation costs associated with activities to integrate, configure and/or customize a hosted cloud computing arrangement service
• cost of testing necessary to accept the developed application or validate that the application satisfies the business requirements. (example: functional testing or non-functional testing such as business continuity, capacity, availability, and security)

Expensed:

• general and administrative costs
• parallel testing and parallel processing⁸
• end-user testing
• end-user training
• actual purging, cleansing, and conversion of historical data
• FISMA certification
• cost of testing performed in conjunction with fixes, or periodically performed to ensure the continued integrity and maintenance of the application. (Examples are penetration testing and contingency testing.)

The post-implementation stage includes activities such as maintenance to fix problems and training of internal and external users.

Capitalized: Software maintenance contracts that are executed when the software is installed should be capitalized and treated as prepaid expenses or deferred charges in instances when the contract terms indicate a longer maintenance period and costs exceed the FAM thresholds for prepaids and deferred charges. Likewise, software maintenance contracts executed for bulk purchases that exceed FAM thresholds should be capitalized and amortized over the current and prospective periods that benefit from the expenditure.

Expensed: All the costs associated with post-implementation stage activities except maintenance costs as described above. This includes integration costs to reinstall existing software on new hardware.

Purchased software may include costs for multiple services such as training and maintenance in addition to the software license. Because maintenance costs may be capitalized if costs exceed the FAM thresholds for prepaids and deferreds and training costs are expensed, the costs should be allocated among these services based on the value of the services. Vendors may have information that can be provided to assist in determining the costs of these services. The basis for allocation should be defensible.

Because development of internal-use software may not follow the order as stated above (for example, coding and testing are often performed iteratively, or an Agile methodology is used) the accounting treatment should be based on the nature of the costs incurred, not the timing of their occurrence.

8. Software development labor rates

Internally developed software costs that meet the FAM threshold should be capitalized using actual salaries and/or outside agency help (OAH) rate(s).⁹ If actual costs are not readily determinable, a Reserve Bank may use either a blended or two-rate approach. Reserve Banks may use different rates based on varying skillsets, salary differentials, or project structures within a cost pool to help reduce the risk of distorting assets. The rate (blended or two-rate) that a Reserve Bank chooses to use should be consistently applied for all District assets.

Rates should be calculated based on budgeted annual employee salaries (including all types of variable compensation) and budgeted benefit costs, and/or the budgeted annual OAH costs divided by the total applicable annual work hours (AWH). The rates should be adjusted to account for employee turnover, organizational changes, or changes in retirement and other benefits (ROB) rates that have occurred since final budget submission.

9. Assigning a useful life to the software asset

The estimated useful life over which the costs will be amortized should reflect the circumstances for that specific asset. The circumstances to consider include the type of software (for example, operating software, application software) and the effects of obsolescence, technology, competition, immediate- and long-term plans, and other economic factors should be considered. For example, rapid changes in the availability of alternative software solutions or hardware technology (on which the software will operate) would contribute to a shorter expected useful life. Consultation with the outside party (when appropriate), the product or function office, business areas, other Reserve Banks, and Board staff may be necessary in order to determine the appropriate useful life and should reflect the circumstances for that specific asset. While FAM sets the maximum useful life that should be assigned to any software asset at five years, in unusual situations, a request to establish a longer life may be submitted for Board staff approval. The rationale for any adopted useful life should be defensible.

Each element (a component or module) or improvement should be recorded separately from the underlying software asset and assigned a unique useful life, not to exceed five years. In some cases, the separately recorded element or improvement may be assigned a useful life that ends co-terminously with the underlying software asset if the analysis warrants such treatment. For example, an element or improvement may be recorded separately, but be amortized co-terminously with the original asset because it is known that the software will be decommissioned at a specific future date.

10. Amortization of software

A software asset is amortized over its useful life. For each element or improvement, amortization should begin when the software is ready for its intended use (after all substantial testing is completed and not necessarily when it is placed in production). If the functionality of an element is entirely dependent on the completion of another element, amortization should begin when the functionality of both elements are ready for their intended use.

11. Regular evaluation of assigned useful lives

At a minimum, each Bank should assess annually the useful lives of software. Each Bank should also assess annually the amortization periods assigned to implementation costs for a cloud computing arrangement that does not contain a software license. If there is a need to change the useful life or amortization period due to the effects of obsolescence, technology, and other economic factors, then revisions are made prospectively. As such, the current net book value is amortized over the revised remaining useful life. In cases where this analysis results in an extension of a useful life for software, the extension should not exceed the maximum allowed by FAM, which is five years. In unusual situations, a request to establish a longer life may be submitted for Board staff approval.

12. Impairment and write-off of software development costs or software assets

Significant events or changes in operating circumstances warrant a review to determine whether the carrying value of an existing software asset or capitalized implementation costs for a cloud computing arrangement that does not contain a software license is not recoverable and should be impaired. Tests should be performed consistent with FAM, Chapter 3, section 30.95 (Asset Impairment) and Board staff should be contacted for approval. In the case of software applications developed for Treasury, no impairment typically results because all costs including those associated with software are generally recoverable from the Treasury. The need for a change in estimated useful life, however, should be considered.

Impairment is applicable, for example, when one of the following events or changes in circumstances occurs related to the software being developed or currently in use indicating that the carrying amount may not be recoverable according to ASC Topic 350-40:

• Internal-use computer software or the cloud computing arrangement is not expected to provide substantive service potential.
• A significant change occurs in the extent or manner in which the software or the cloud computing arrangement is used or is expected to be used.
• A significant change is made or will be made to the software program or the cloud computing arrangement.
• Costs of developing or modifying the internal-use computer software significantly exceed the amount originally expected to develop or modify the software.

When it is no longer probable that a software project will be completed, no further costs should be capitalized and any costs that have been capitalized should be written off. Any expected recovery of accumulated costs from third parties, including the U.S. Treasury, should be considered in the write off. Indications that the software may no longer be completed include:

• the lack of commitments to fund further development
• the discontinuance of the business segment the software was designed for
• the inability to resolve programming difficulties timely
• significant cost overruns
• or a decision to obtain third-party software instead and abandon the current software development.

13. Unusual situations

Categorization of some software development may not be as readily ascertainable from the above guidance and may require more analysis and review with the product or support office, business area, and Board staff to determine whether the software costs should be capitalized or expensed.

14. Software Standard Task Description List

Reserve Bank initiatives with a software component must comply with the PPM Standard. The PPM Standard also applies to any Reserve Bank technology initiative, including software development, purchased software (vendor-developed/purchased software applications), infrastructure, and service. Reserve Bank users should reference the standard task list description when determining capitalization or expense classifications for software development or purchased software initiative activities. The standard task list description is found on the Reserve Banks' FAM SharePoint site.

Footnotes