skip to main navigation skip to secondary navigation skip to content
Board of Governors of the Federal Reserve System
skip to content

Financial Accounting Manual for Federal Reserve Banks, January 2017

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.1 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.2 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.3 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.4 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,5 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.6 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 processing7
  • 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).8 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.

Two-rate approach:

Two-rate approach

Blended-rate approach:

Blended-rate approach

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

1. This appendix is based on a memo issued by RBOPS FRB Financial Accounting Section on December 27, 2007. Return to text

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

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

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

5. The term "without significant penalty" contains two distinct concepts: (1) the ability to take delivery of the software without incurring significant cost, and (2) the ability to use the software separately without a significant diminution in utility or value. Return to text

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

7. Parallel testing related activities are generally performed by the end-user and take place when the internally developed system is deemed functionally complete. Parallel processing related activities take place when the newly internally developed system is designated as the "system of record" and runs in parallel with the system that has been replaced (designated as the legacy system). Return to text

8. Federal Reserve System users should reference the Reserve Banks SharePoint site for detailed procedures. Return to text

Back to Top

Last update: February 17, 2017