Appendix D. Software

 

D.1 Accounting Guidance for Internal Use Software Costs

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. This information expands on the requirements in the Financial Accounting Manual (FAM)'s Chapters 1 (Section 4.21) and 3 (Sections 30.50, 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 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 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 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 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. 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 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 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 8 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 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.³ 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) should be charged to current expense regardless of amount.

4. Cloud Computing arrangements

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 license 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. Costs arising from implementation, set-up, etc. should be carefully evaluated for capitalization purposes. To the extent the software license transfers in a cloud computing arrangement; Appendix D should be reviewed for guidance for costs resulting from training, data capture, and conversion activities.

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,
• 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 8. 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:

Capital	Expense
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 1	Reformatting of reports including the inclusion/exclusion of existing data fields
Converting to a new platform (mainframe to distributed platform; 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

1. Initial or upgrade work performed during the development phase should be capitalized. Similar work performed during the post-implementation phase should be expensed. Return to table

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 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.⁶ 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 8.

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.

7. 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 13).

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. 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 13).

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 7
• 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 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. Certain tasks described in the transition phase of the SDF correspond to the post-implementation stage (see detailed matrices in section 13).

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) 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 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.

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. 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.

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 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-35-1:

• "Internal-use computer software is not expected to provide substantive service potential.
• A significant change occurs in the extent or manner in which the software is used or is expected to be used.
• A significant change is made or will be made to the software program.
• 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. Comparison of System Development Framework phases and ASC stages

SDF and Technology Project Management (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.

Inception Phase Controls

ASC Stage	Tasks	SDF Control	Artifact	Capitalize
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, reviewed, and documented	1.1.3. Requirements for high-value / high-risk requirements are elaborated	Process Flow Diagrams, Wire Frame Diagrams, Use Case, User Story, Supplementary Specifications	No
Preliminary	Create plan to define major releases of project, specifically the timing and content of each phase.	1.1.4. Initial release plan is created	Project Schedule Release Notes	No
Preliminary	Define versions and 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, and resolving software and security defects.	1.1.6. Defect tracking processes are defined	Software Development Plan	No
Preliminary	Identify types of testing to be conducted and by whom.	1.1.7. Testing strategy is defined	Software Development Plan, Test Strategy, QA Test Plan	No
Preliminary	Evaluate criteria for exiting the Inception phase and confirm controls have been identified and met.	1.1.8. Assessment of Inception phase is completed	Assessment Criteria, Decision to Proceed, Update Project Management	No
Preliminary	Include high level statement of customer's view of product in Project Charter.	1.2.1. Vision is documented in the scope of the Project Charter	Project Charter	No
Preliminary	Roles, responsibilities, governance, organizations and authorizations rights specific to project are identified and incorporated in artifacts.	1.2.2. Software development roles, responsibilities and governance structures are identified	Software Development Plan Project Charter, Project Assignment Responsibility Matrix	No
Preliminary	Identify and document risks specific to project, including security risks.	1.2.3. Software development risks are added to the Risk Register	Project Risk Register	No
Preliminary	RFI or RFP are created for external vendor services or products.	1.2.4. RFI/RFP for vendor/contract/ COTS procurement is created and distributed	RFI/RFP	No
Preliminary	High-level estimates and schedule are developed.	1.2.5. Low-fidelity cost estimate and project scheduled are documented	Project Charter, Project Schedule	No
Preliminary	Determine control process for scope changes made to the original project.	1.2.6. Scope change management practice is defined	Project Charter, Project Scope, Management Plan	No

Elaboration Phase Controls

ASC Stage	Tasks	SDF Control	Artifact	Capitalize
Preliminary	Update high level list of functional and non-functional requirements.	2.1.1 Requirements survey is updated	Requirements Survey	No
Preliminary	Detailed business specifications for high-value/high-risk business, security, and technical requirements are obtained, reviewed and documented.	2.1.2 Functional and non-functional requirements identified for this phase are elaborated	Process Flow Diagram, Wire Frame Diagram, Use Case, Misuse Case, User Story, Supplementary Specification	No
Development	Identify tests to be performed and writing test cases or scripts.	2.1.3 Initial testing artifacts are created	Test Plan, Test Cases Scripts, Test Results	Yes
Preliminary	Establish and document quality control practices.	2.1.4 Quality control practices are identified and implemented	Software Development Plan Quality Management 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 and prioritizing 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	Software Architecture Document, Development Plan	Yes
Development	Determine criteria for existing Elaboration phase controls have been identified and met.	2.1.10 Assessment of Elaboration phase is completed.	Update Project Management Documents	No /Administrative
Preliminary	Vision is updated in Project Charter to reflect any discoveries and additional information.	2.2.1 Vision is updated as necessary in the Project Charter	Project Charter	No
Development	As occurring, 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, Scope Management Plan	No
Preliminary	Externally provided services or products are evaluated and selected.	2.2.4 Vendor/contract/ COTS services or products identified for this phase are evaluated, selected, and procured	Procurement Management Plan, Contract Statement of Work	No
Development/Post implementation	Products/services are procured.			Yes

Construction Phase Controls

ASC Stage	Tasks	SDF Control	Artifact	Capitalize
Preliminary	Detailed business specifications identified for this phase are obtained, reviewed, and documented by business area.	3.1.1 Requirements addressed in the construction phase are elaborated	Process Flow Diagram, Use Case, Misuse Case, User Story, Supplementary Specification	No
Development	Writing test cases or scripts.	3.1.2 Testing artifacts for construction phase are created	Test Cases and Scripts, Test Results	Yes
Development	Establish and document quality control practices.	3.1.3 Quality control practices are implemented	Quality Management Plan	Yes
Development	Project team reviews work performed in previous 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	Software Development Plan	Yes
Development	Establish an approach for tracking and prioritizing backlog.	3.1.6 Backlog is updated	Backlog	Yes
Development	Describe how the system will operate to meet the business objectives.	3.1.7 Operational plan is developed	Operational Plan	Yes
Development	Determine criteria for exiting Construction phase controls have been identified and met.	3.1.8 Assessment of Construction phase is completed	Update Project Management Documents	Yes
Development	Strategy and approach for system implementation (what will be deployed, where, and when) is documented in a plan.	3.2.1 Initial implementation plan is completed	Implementation Plan	Yes

Transition Phase Controls

ASC Stage	Tasks	SDF Control	Artifact	Capitalize
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.	4.1.2 Full Acceptance Testing is completed	Acceptance Test Plan, Acceptance Test Script	No / End User Testing is not capitalized
Development	Execute practices for version control of all software development artifacts.	4.1.3 Configuration management practices are executed	Software Development Plan	Yes
Post Implementation	Determine criteria for exiting Transition phase controls have been identified and met.	4.1.4 Assessment of Transition Phase is completed	Update Project Management Documents	No / Administrative
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	Scope Verification	No

References

Back to Top

• Other Formats

• Full report (PDF)

• Stay Connected

• Twitter
• YouTube
• Flickr
• RSS Feeds
• Subscribe

Last update: February 17, 2017

Home | Publications