Financial Accounting Manual
- Revision Set 53
- Chapter 1. Balance Sheet
- Chapter 2. Collateral and Custodies
- Chapter 3. Property and Equipment
- Chapter 4. Central Bank Unique Accounting
- Chapter 5. Federal Reserve Notes
- Chapter 6. Reporting Requirements
- Chapter 8. Special Topics
Appendix D. Software
D.1 Accounting Guidance for Internal Use Software Costs
In this Section:
- 1. Capitalization thresholds for internal use software
- 2. Ownership of software
- 3. Definition of the asset unit for software
- 4. Improvements to existing software
- 5. Replacement of existing software
- 6. Capitalizable costs during software development
- 7. Assigning a useful life to the software asset
- 8. Amortization of software
- 9. Regular evaluation of assigned useful lives
- 10. Impairment and write-off of software development costs or software assets
- 11. Unusual Situations
- 12. Comparison of System Development Framework phases and ASC stages
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 information expands on the requirements in the Financial Accounting Manual (FAM)'s Chapters 1 and 3 and further highlights the underlying accounting principles that relate to software assets and expenses.16 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.17
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 2007 the Reserve Banks adopted the Software Development Framework (SDF) as part of the Technology Project Standards. The SDF identifies four phases (inception, elaboration, construction, and transition) of software development. In view of the Reserve Banks' use of this framework and to assist in the analysis and evaluation of the accounting treatment for internally developed software, the relationship of these four phases to ASC 350-40 is also discussed.
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 accounting staff 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 Accounting Policy and Operations Section staff must be contacted for approval of FAM exceptions.
The analysis, conclusions, and rationale for the accounting treatment should be carefully documented.
1. Capitalization thresholds for internal use software
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 $25,000 or more for externally purchased software as 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. When internal use software that costs $100,000 or more is acquired from a vendor, the contract or lease terms should also be evaluated to determine if the acquisition must be treated as a capital lease as required by FAM Chapter 3, section 30.80 (Capitalized Lease). 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 pass ownership or rights, software ownership is determined by several factors that indicate control such as:
- the entity makes decisions about the software; 18
- the entity operates and provides daily support for the software;
- and the entity controls access to the software.
In the Federal Reserve System, there is a designated entity, such as a Central Application Business 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, such as the U.S. Treasury'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 such as the U.S. Treasury, that will be controlled by the outside party (the above factors are satisfied) and is installed on the outside party's own hardware, 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 7 and placed in service when substantially complete and ready to 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 would 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.19 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.20 Standard desktop utility software (such as word processing, electronic mail, and anti-virus software) should be charged to current expense regardless of amount.
4. 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,
- 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 7. 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:
|Augmenting existing business functions with new features and functions||Updating of flags and thresholds|
|Building completely new business functions||Updating field lengths and comment fields|
|Creating new screens and reports for new features or business functions||Reformatting of reports including the inclusion/exclusion of existing data fields|
|Converting to a new platform (mainframe to client/server) (See section 5)||Modifying layout of screens|
|Building a new interface||Changes to facilitate a new operating system version (Windows XP to Windows Vista)|
|Installing fixes and patches|
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.
5. 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 6, 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.21 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 7.
In addition, if there is a replacement of an element of existing software and the expenditures meet the criteria in sections 1, 2, and 6, 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 4.
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.
6. Capitalizable costs during software development
Costs incurred during software development are capitalized or expensed depending on the stages of development. These stages are most often described as preliminary, development, and post-implementation. Reserve Bank IT management and staff apply the SDF, which describes four phases (inception, elaboration, construction, and transition), to capture software development hours and related costs. To simplify reconciling the framework phases to the ASC stages, this section aligns development phase activities with the development stages.
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.
The tasks described in the inception phase of the SDF correspond to the preliminary stage (see detailed matrices in section 12).
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, including parallel processing), installation of software on hardware, preparation of code to convert old data, and development of user guides. Certain tasks described in the elaboration phase, and almost all tasks described in the construction phase of the SDF correspond to the development stage (see detailed matrices in section 12).
- external costs of materials and services (for example, consulting fees), salary and retirement and other benefit costs of employees directly associated with the project (i.e., average salary plus benefits, no standard support rates should be used)
- 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.
- cost of testing necessary to accept the developed application or validate that the application satisfies the business requirements. (Example: functional testing)
- although costs associated with some testing may not be easily captured for capitalization (Example: parallel testing) Banks are expected to make a reasonable effort
- general and administrative costs
- end-user testing
- end-user training
- actual purging, cleansing, and conversion of historical data
- FISMA certification
- cost of testing performed in conjunction with development of enhancements or 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. Certain tasks described in the transition phase of the SDF correspond to the post-implementation stage (see detailed matrices in section 12).
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.
7. 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 5 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 5 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.
8. Amortization of software
A software asset is amortized over its useful life. When new software development, an element, an improvement, or a replacement is substantially completed (after all relevant testing is completed) and is ready for its intended use (not necessarily when it is placed in production), the in-service date is established and amortization begins.
9. Regular evaluation of assigned useful lives
At a minimum, each Bank should assess the useful lives of software annually. If there is a need to change the useful life 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, the extension should not exceed the maximum allowed by FAM, which is 5 years. In unusual situations, a request to establish a longer life may be submitted for Board staff approval.
10. 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 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.
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 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.
11. 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.
12. Comparison of System Development Framework phases and ASC stages
SDF and TPM controls also apply to vendor-developed/purchased software applications. Although some of the artifacts or steps involved in meeting the controls may vary slightly from those shown below, the ASC stage and the capitalization decision should be consistent with that shown.
|Preliminary, Development, or Post Implementation||SDF Controls|
|Preliminary||Develop high level list of functional and non functional requirements||1.1.1 Requirements Survey is developed||Requirements Survey||No|
|Preliminary||Determine which requirements are high value and/or high risk and document.||1.1.2 High value / high risk business requirements are identified based upon the requirements survey||Requirements Survey||No|
|Preliminary||Detailed business specifications for high value/high risk business requirements are obtained, documented, by business area & reviewed||1.1.3. Requirements for high value / high risk requirements are elaborated||Use Cases, Wire Frames, Process Flow diagrams||No|
|Preliminary||Plan is created that defines major releases of project.||1.1.4 Initial release plan is created||Project ScheduleRelease Plan||No|
|Preliminary||Define versioning & control process for all software development artifacts.||1.1.5 Configuration management practices are defined||Software Development Plan||No|
|Preliminary||Define process to facilitate reporting, tracking, & resolving software & security defects.||1.1.6 Defect tracking processes are defined||Software Development Plan||No|
|Preliminary||Identify types of testing to be conducted.||1.1.7 Testing strategy is defined||Software Development Plan Test StrategyQA Test Plan||No|
|Preliminary||Determine all Inception Phase controls have been met.||1.1.8 Assessment of Inception phase is complete||Update Prj Mgmt Documents||No|
|Preliminary||Include high level statement of customer's view of product in Charter.||1.2.1 Vision is documented in the scope of the Project Charter||Project Charter||No|
|Preliminary||Roles, responsibilities, & governance specific to project are identified in artifacts.||1.2.2 Software development roles, responsibilities and governance structures are identified||Software Development Plan Project Charter||No|
|Preliminary||Identify and document risks.||1.2.3 Software development risks are added to the Risk Register||Risk Register||No|
|Preliminary||RFI or RFPs are created for external vendor services or products.||1.2.. RFI/RFP for vendor/contract/COTS procurement is created and distributed||RFI/RFP||No|
|Preliminary||High level estimates and schedule are developed.||1.2.4 Low-fidelity cost estimate and project scheduled are documented||Project Charter and Project Schedule||No|
|Preliminary||Determine process for scope changes for project.||1.2.5 Scope change management practice is defined||Project CharterProject Scope Mgmt Plan||No|
|Preliminary, Development, or Post Implementation||SDF Controls|
|Preliminary||Update high level list of functional & non functional requirements||2.1.1 Requirements Survey is updated||Requirements
|Preliminary||Detailed business specifications identified for this phase are obtained, documented by business area & reviewed||2.1.2 Functional and non-functional requirements for this phase are elaborated||Use Cases Wire Frames||No|
|Development||Identify tests to be performed/writing test cases or scripts||2.1.3 Initial testing artifacts are created||Test Plan Test Cases and scripts||Yes|
|Preliminary||Document quality control practices||2.1.4 Quality control practices are identified and implemented||Software Development Plan, Quality Mgmt Plan||No|
|Development||Refine and execute practices for version control of all software development artifacts.||2.1.5 Configuration management practices are refined and executed||Software Development Plan||Yes|
|Development||Project team reviews work performed in prior iterative period, and prioritizes and assigns work to be done in next iterative period.||2.1.6 Iteration planning artifacts are developed||Iteration Plan||Yes|
|Preliminary||Establish an approach for tracking backlog items.||2.1.7 Backlog mechanism is created||Software Development Plan||No|
|Development||Document how software is organized into building blocks, patterns, or components. ( Blueprint for application)||2.1.8 Architecture specifications/design is defined and documented||Software Architecture Document||Yes|
|Development||Architecture components are developed and validated through build out and demonstration for high value/high risk requirements.||2.1.9 Architecturally significant components are developed and demonstrated||Yes|
|Development||Determine all Elaboration Phase controls have been met.||2.1.10 Assessment of Elaboration phase is complete||Update Prj Mgmt Documents||
|Preliminary||Vision is updated to reflect any discoveries and additional information.||2.2.1 Vision is updated as necessary in the Project Charter||Project Charter||No|
|Development||As realized, software development issues are added to the Issue Log to be prioritized and addressed.||2.2.2 Software development issues are added to the Issue Log||Issue Log||Yes|
|Preliminary||Documents are updated to reflect discoveries from Elaboration Phase.||2.2.3 Schedule and cost baselines are updated.||Schedule||No|
Externally provided services or products are evaluated and selected.
Products/services are procured.
|2.2.4 Vendor/contract/ COTS services or products identified for this phase are evaluated, selected, and procured||Contract||
|Preliminary, Development, or Post Implementation||SDF Controls|
|Preliminary||Detailed business specifications identified for this phase are obtained and documented by business area.||3.1.1 Requirements addressed in the construction phase are elaborated.||Use Cases, Wire Frames||No|
|Development||Writing test cases or scripts||3.1.2 Testing artifacts for construction phase are created||Test Cases and scripts||Yes|
|Development||Quality control practices established in Elaboration phase are implemented.||3.1.3 Quality control practices are implemented.||Documentation of review||Yes|
|Development||Project team reviews work performed in prior iterative period, and prioritizes and assigns work to be done in next iterative period.||3.1.4 Iteration planning artifacts are developed.||Iteration Plan||Yes|
|Development||Execute practices for version control of all software development artifacts.||3.1.5 Configuration management practices are executed||Yes|
|Development||Update backlog.||3.1.6 Backlog is updated.||Backlog||Yes|
|Development||Describes how the system will operate to meet the business objectives.||3.1.7 Operational plan is developed.||Operational Plan||Yes|
|Development||Determine all Construction Phase controls have been met.||3.1.8 Assessment of Construction phase is complete||Yes|
|TPM Controls||Update Proj Mgmt Documents|
|Development||What will be deployed where and when is documented in a plan.||3.2.1 Initial implementation plan is completed.||Implementation Plan||Yes|
|Preliminary, Development, or Post Implementation||SDF Controls|
|Development||Detailed notes that describe the specific contents of a release for customer or outside testing party||4.1.1 Release notes are developed and distributed.||Release Notes||Yes|
|Development||Complete test of entire system by customer or delegated party is completed.||4.1.2 Full acceptance testing is completed||Acceptance Test Plan.||No - end user testing is not typically capitalized|
|Development||Execute practices for version control of all software development artifacts.||4.1.3 Configuration management practices are executed.||Yes|
|Post Implementation||Determine all Transition Phase controls have been met.||4.1.4 Assessment of Transition Phase is completed.||Update Proj Mgmt Documents||No|
|Post Implementation||Detailed implementation plan is revised and finalized.||4.2.1 Implementation plan is finalized.||Implementation Plan||No|
|Post Implementation||Stakeholder provides written approval that product meets documented business requirements.||4.2.2 Stakeholder approval is obtained||No|
16. As background, information in the FASB ASC Topic 350-40; formerly CON 6 and SOP 98-1 was reviewed. The accounting principles are: the tangible object or intangible right has economic value to its owners, has continuing benefits for future periods, and can be expressed in terms of its costs; and that costs are matched with the accounting periods that the costs benefit. Return to text
17. This appendix is based on a memo issued by RBOPS FRB Financial Accounting Section on December 27, 2007. Return to text
18. Irrespective of that fact, in designating Reserve Banks as fiscal agents, the U.S. Treasury has delegated many rights; however, high-level decisionmaking, such as implementation and decommissioning of applications developed for the U.S. Treasury, remains with the Treasury. As such, the decisionmaking criteria related to the determination of control may not be completely met by the Reserve Bank. Return to text
19. The $100,000 threshold is not related to the threshold for internally developed software, but is an amount that is deemed a significant or material enough bulk purchase to warrant capitalization. Return to text
20. Some contracts are open ended or may include subsequent orders. If a subsequent purchase does not satisfy the threshold it would be expensed. Return to text
21. The above describes the porting of the application software; another approach is hosting, whereby a distributed platform is used to emulate the mainframe so that the mainframe application software can be used without recoding; such an approach would likely not be treated as a replacement. Return to text