Page 1 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
Statement of Federal Financial Accounting Standards 10:
Accounting for Internal Use Software
Status
Summary
This statement provides accounting standards for internal use software. Under the provisions of
this statement, internal use software is classified as “general property, plant, and equipment”
(PP&E) as defined in Statement of Federal Financial Accounting Standards (SFFAS) 6,
Accounting for Property, Plant, and Equipment. This statement includes software used to operate
a federal entity’s programs (e.g., financial and administrative software, including that used for
project management) and software used to produce the entity’s goods and services (e.g., air
traffic control and loan servicing).
Internal use software can be purchased off-the-shelf from commercial vendors and can be
developed by contractors with little technical supervision by the federal entity or developed
internally by the federal entity.
For capitalizable software, capitalization would begin after the entity completed all planning,
designing, coding, and testing activities that are necessary to establish that the software can
meet the design specifications.
At the conclusion of the PP&E project the Federal Accounting Standards Advisory Board
discussed whether the standard for internally developed software should also apply to
contractor-developed software. Also, some users of SFFAS 6 were unsure how to apply it to
COTS and contractor-developed software. The Board decided, in December 1996, to review the
issue and develop a separate standard for internal use software.
This standard requires the capitalization of the cost of internal use software whether it is COTS,
contractor-developed, or internally developed. Such software serves the same purposes as other
general PP&E and functions as a long-lived operating asset. This standard provides guidance
regarding the types of cost elements to capitalize, the timing and thresholds of capitalization,
amortization periods, accounting for impairment, and other guidance.
Issued October 9, 1998
Effective Date For periods beginning after September 30, 2000.
Affects • SFFAS 10, paragraph 7, rescinds SFFAS 6, paragraphs 27-28.
Affected by • SFFAS 32 amends paragraph 35.
• SFFAS 50 amends paragraph 16 and 36.
Related Guidance TR 16, Implementation Guidance for Internal Use Software.
SFFAS 10
Page 2 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
Table Of Contents
Page
Summary
1
Scope 3
Materiality 4
Effective Date 4
Internal Use Software Accounting Standard
4
Definitions 4
Recognition, Measurement, and Disclosure 7
Implementation 12
Appendix A: Basis for Conclusions
15
Appendix B: Glossary [See Consolidated Glossary in Appendix E]
26
SFFAS 10
Page 3 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
Introduction
Purpose
1. This statement provides accounting standards for internal use software
1
used by federal
entities. Federal entities purchase commercial “off-the-shelf” (COTS) software, hire
contractors to develop substantially all of the desired software (contractor-developed), or
develop software internally using their own employees, with or without a contractor’s
assistance (internally developed).
Scope
2. This statement establishes accounting standards for the cost of software developed or
obtained for internal use. These include the cost of
• software used to operate an entity’s programs (e.g., financial and administrative
software, including that used for project management),
• software used to produce the entity’s goods and to provide services (e.g., air traffic
control and loan servicing), and
• software that is developed or obtained for internal use and subsequently provided to
other federal entities with or without reimbursement.
3. This statement provides standards on accounting for software consisting of one or more
components or modules. For example, an entity may develop an accounting software
system containing three elements: a general ledger, an accounts payable subledger, and an
accounts receivable subledger. Each element might be viewed as a component or module
of the entire accounting software system. This standard may be applied to the total cost of
the software or, when appropriate, to individual components or modules. For example, one
software module may be implemented before others, in which case, the provisions of this
standard for capitalization, amortization, etc., would apply to it separately.
1
The terms defined in the glossary will be in boldface when they first appear in the body of this document [see
Appendix E, Consolidated Glossary]
SFFAS 10
Page 4 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
Background
4. At the conclusion of the general property, plant, and equipment (PP&E) project, the Federal
Accounting Standards Advisory Board (Board) discussed whether the standard for internally
developed software should also apply to contractor-developed software. Also, some users
of Statement of Federal Financial Accounting Standards (SFFAS) No. 6 were unsure of how
to apply it to COTS and contractor-developed software. The Board decided in December
1996 to review the issue and develop a separate standard for internal use software.
5. In June 1997, the Board issued an exposure draft entitled Accounting for Internal Use
Software. The Board received comments from 26 respondents and held a public hearing on
December 18, 1997.
Materiality
6. The provisions of this statement need not be applied to immaterial items.
Effective Date
7. The provisions of this statement are effective for reporting periods that begin after
September 30, 2000. Paragraphs 27 and 28 of SFFAS No. 6, Accounting for Property, Plant,
and Equipment, which pertain to internally developed software, are rescinded upon this
standard’s issuance. Federal entities may continue their current accounting practices for
internal use software for accounting periods beginning before October 1, 2000. Early
implementation of this statement is encouraged.
Internal Use Software Accounting Standard
Definitions
8. Software includes the application and operating system programs, procedures, rules, and
any associated documentation pertaining to the operation of a computer system or program.
“Internal use software” means software that is purchased from commercial vendors “off-the-
shelf,” internally developed, or contractor-developed solely to meet the entity’s internal or
operational needs. Normally software is an integral part of an overall system(s) having
interrelationships between software, hardware, personnel, procedures, controls, and data.
SFFAS 10
Page 5 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
9. This definition of internal use software encompasses the following:
a. Commercial off-the-shelf (COTS) software: COTS software refers to software that is
purchased from a vendor and is ready for use with little or no changes.
b. Developed software
(1) Internally developed software refers to software that employees of the entity are
actively developing, including new software and existing or purchased software
that are being modified with or without a contractor’s assistance.
(2) Contractor-developed software refers to software that a federal entity is paying a
contractor to design, program, install, and implement, including new software and
the modification of existing or purchased software.
Software Development Phases
10. Software’s life-cycle phases
2
include planning, development, and operations. This standard
provides a framework for identifying software development phases and processes to help
isolate the capitalization period for internal use software that the federal entity is developing.
11. The following table illustrates the various software phases and related processes. The steps
within each phase of internal use software development may not follow the exact order
shown below. This standard should be applied on the basis of the nature of the cost
incurred, not the exact sequence of the work within each phase.
2
There are no federal requirements regarding the phases that each software project must follow. The life-cycle phases
of a software application described here are compatible with and generally reflect those in the Office of Management
and Budget’s (OMB) Circular A-130, Management of Information Resources, and Capital Programming Guidance; the
Government Accountability Office’s (GAO), Measuring Performance and Demonstrating Results of Information
Technology Investments (GAO/AIMD-98-89, Mar. 1998); and the American Institute of CPA’s Statement of Position No.
98-1, Accounting for the Costs of Computer Software Developed or Obtained for Internal Use (Mar. 4, 1998).
Successful software projects normally would have at least an initial design phase, an application development phase,
and a post-implementation/operational phase. Also, software eventually would become obsolete or otherwise be
replaced and therefore have a termination phase. Circular A-130 acknowledges that the “life cycle varies by the nature
of the information system. Only two phases are common to all information systems—a beginning and an end. As a
result, life cycle management techniques that agencies can use may vary depending on the complexity and risk
inherent in the project.” (A-130, “Analysis of Key Sections,” p. 63).
SFFAS 10
Page 6 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
12. In the preliminary design phase, federal entities will likely do the following:
a. Make strategic decisions to allocate resources between alternative projects at a given
time. For example, should programmers develop new software or direct their efforts
toward correcting problems in existing software?
b. Determine performance requirements (i.e., what it is that they need the software to do).
c. Invite vendors to perform demonstrations of how their software will fulfill a federal
entity’s needs.
d. Explore alternative means of achieving specified performance requirements. For
example, should a federal entity make or buy the software? Should the software run on
a mainframe or a client server system?
e. Determine that the technology needed to achieve performance requirements exists.
f. Select a vendor if a federal entity chooses to obtain COTS software.
g. Select a consultant to assist in the software’s development or installation.
13. In the software development phase, federal entities will likely do the following:
a. Use a system to manage the project.
Preliminary design
phase Software development phase
Post-Implementation/
operational phase
Conceptual formulation of
alternatives
3
Evaluation and testing of
alternatives
Determination of existence of
needed technology
Final selection of alternatives
Design of chosen path, including
software configuration and
software interfaces
4
Coding
Installation to hardware
Testing, including parallel
processing phase
Data conversion
Application maintenance
3
See OMB Circular A-11, Planning, Budgeting, and Acquisition of Capital Assets; Supplement to Circular A-11, Capital
Programming Guide (July 1997); and Circular A-109, Major Systems Acquisitions, par. 11, “Alternative Systems.”
4
See OMB Circular A-109, Major Systems Acquisitions, par. 13, “Full-Scale Development and Production.”
SFFAS 10
Page 7 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
b. Track and accumulate life-cycle cost and compare it with performance indicators.
c. Determine the reasons for any deviations from the performance plan and take
corrective action.
d. Test the deliverables to verify that they meet the specifications.
14. In the post-implementation/operational phase, federal entities will likely do the following:
a. Operate the software, undertake preventive maintenance, and provide ongoing training
for users.
b. Convert data from the old to the new system.
c. Undertake post-implementation review comparing asset usage with the original plan.
d. Track and accumulate life-cycle cost and compare it with the original plan.
Recognition, Measurement, And Disclosure
Software Used As General PP&E
15. Entities should capitalize the cost of software when such software meets the criteria for
general property, plant, and equipment (PP&E). General PP&E is any property, plant, and
equipment used in providing goods and services.
5
Capitalizable Cost
16. Although the measurement basis remains historical cost, reasonable estimates maybe used
to establish the capitalized cost of internally developed software, in accordance with the
asset recognition and measurement provisions herein. For internally developed software,
capitalized cost should include the full cost (direct and indirect cost) incurred during the
software development stage.
6
Such cost should be limited to cost incurred after
a. management authorizes and commits to a computer software project and believes that
it is more likely than not that the project will be completed and the software will be used
to perform the intended function with an estimated service life of 2 years or more and
b. the completion of conceptual formulation, design, and testing of possible software
project alternatives (the preliminary design stage).
5
General PP&E, as distinguished from stewardship PP&E, is defined in pars. 23-25, in SFFAS No. 6, Accounting for
Property, Plant, and Equipment.
6
For a full discussion of direct and indirect cost, see SFFAS No. 4, Managerial Cost Accounting Concepts and
Standards for the Federal Government (June 1995), pars. 90-92. Also see pars. 94-95, Statement of Federal Financial
Accounting Concepts No. 2, Entity and Display.
SFFAS 10
Page 8 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
17. Such costs include those for new software (e.g., salaries of programmers, systems analysts,
project managers, and administrative personnel; associated employee benefits; outside
consultants’ fees; rent; and supplies) and documentation manuals.
18. For COTS software, capitalized cost should include the amount paid to the vendor for the
software. For contractor-developed software, capitalized cost should include the amount
paid to a contractor to design, program, install, and implement the software. Material internal
cost incurred by the federal entity to implement the COTS or contractor-developed software
and otherwise make it ready for use should be capitalized.
Data Conversion Cost
19. All data conversion costs incurred for internally developed, contractor-developed, or COTS
software should be expensed as incurred, including the cost to develop or obtain software
that allows for access or conversion of existing data to the new software. Such cost may
include the purging or cleansing of existing data, reconciliation or balancing of data, and the
creation of new/additional data.
Cutoff For Capitalization
20. Costs incurred after final acceptance testing has been successfully completed should be
expensed. Where the software is to be installed at multiple sites, capitalization should cease
at each site after testing is complete at that site.
Multiuse Software
21. The cost of software that serves both internal uses and stewardship purposes (“multiuse
software”) should be accounted for as internal use software (e.g., a global positioning
system used in connection with national defense activities and general operating activities
and services).
Integrated Software
22. Computer software that is integrated into and necessary to operate general PP&E, rather
than perform an application, should be considered part of the PP&E of which it is an integral
part and capitalized and depreciated accordingly (e.g., airport radar and computer-operated
lathes). The aggregate cost of the hardware and software should be used to determine
whether to capitalize or expense the costs.
SFFAS 10
Page 9 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
Bundled Products And Services
23. Federal entities may purchase software as part of a package of products and services (e.g.,
training, maintenance, data conversion, reengineering, site licenses and rights to future
upgrades and enhancements). Federal entities should allocate the capitalizable and
noncapitalizable cost of the package among individual elements on the basis of a
reasonable estimate of their relative fair values. Costs that are not susceptible to allocation
between maintenance and relatively minor enhancements should be expensed.
Capitalization Thresholds
24. Each federal entity should establish its own threshold as well as guidance on applying the
threshold to bulk purchases of software programs (e.g., spreadsheets, word-processing
programs, etc.) and to modules or components of a total software system. That guidance
should consider whether period cost would be distorted or asset values understated by
expensing the purchase of numerous copies of a software application or numerous
components of a software system and, if so, provide that the collective cost should be
capitalized.
Enhancements
25. The acquisition cost of enhancements to existing internal use software (and modules
thereof) should be capitalized when it is more likely than not that they will result in significant
additional capabilities. For example, in an instance where the federal entity adds a capability
or function to existing software for making ad hoc queries, the cost would be capitalized.
26. Enhancements normally require new software specifications and may require a change of
all or part of the existing software specifications as well. The cost of minor enhancements
resulting from ongoing systems maintenance should be expensed in the period incurred.
Also, the purchase of enhanced versions of software for a nominal charge are properly
expensed in the period incurred.
27. Cost incurred solely to repair a design flaw or to perform minor upgrades that may extend
the useful life of the software without adding capabilities should be expensed.
7
7
However, in instances where the useful life of the software is extended, the amortization period would be adjusted.
The Board has considered the cost associated with modifying internal use software for the year 2000 (Y2K) and has
determined that such cost should be charged to expenses as incurred, since it is a repair of a design flaw that allows
existing software to continue being used. However, an enhancement could presumably provide enhanced capabilities
and at the same time, as an integral part of the new code and other software enhancements, cure the Y2K problem.
The total cost of such an enhancement should be capitalized rather than allocated between the Y2K cost and all other
cost.
SFFAS 10
Page 10 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
Impairment
POST-IMPLEMENTATION/OPERATIONAL SOFTWARE
28. Impairment should be recognized and measured when one of the following occurs and is
related to post-implementation/operational software and/or modules thereof:
• the software is no longer expected to provide substantive service potential and will be
removed from service or
• a significant reduction occurs in the capabilities, functions, or uses of the software (or a
module thereof).
29. If the impaired software is to remain in use, the loss due to impairment should be measured
as the difference between the book value and either (1) the cost to acquire software that
would perform similar remaining functions (i.e., the unimpaired functions) or, if that is not
feasible, (2) the portion of book value attributable to the remaining functional elements of the
software. The loss should be recognized upon impairment, and the book value of the asset
reduced accordingly. If neither (1) nor (2) above can be determined, the book value should
continue to be amortized over the remaining useful life of the software.
30. If the impaired software is to be removed from use, the loss due to impairment should be
measured as the difference between the book value and the net realizable value (NRV), if
any.
8
The loss should be recognized upon impairment, and the book value of the asset
reduced accordingly. The NRV, if any, should be transferred to an appropriate asset account
until such time as the software is disposed of and the amount is realized.
DEVELOPMENTAL SOFTWARE
31. In instances where the managers of a federal entity conclude that it is no longer more likely
than not that developmental software (or a module thereof) will be completed and placed in
service, the related book value accumulated for the software (or the balance in a work in
process account, if applicable) should be reduced to reflect the expected NRV, if any, and
the loss recognized. The following are indications of this:
• Expenditures are neither budgeted nor incurred for the project.
• Programming difficulties cannot be resolved on a timely basis.
• Major cost overruns occur.
• Information has been obtained indicating that the cost of developing the software will
significantly exceed the cost of COTS software available from third party vendors;
8
Presumably, NRV will be zero for software. However, in the rare case that it is not zero, NRV should be recognized.
SFFAS 10
Page 11 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
hence, management intends to obtain the product from those vendors instead of
completing the project.
• Technologies that supersede the developing software product are introduced.
• The responsibility unit for which the product was being created is being discontinued.
Amortization
32. Software that is capitalized pursuant to this standard should be amortized in a systematic
and rational manner over the estimated useful life of the software. The estimated useful life
used for amortization should be consistent with that used for planning the software’s
acquisition.
9
33. For each module or component of a software project, amortization should begin when that
module or component has been successfully tested. If the use of a module is dependent on
completion of another module(s), the amortization of that module should begin when both
that module and the other module(s) have successfully completed testing.
34. Any additions to the book value or changes in useful life should be treated prospectively.
The change should be accounted for during the period of the change and future periods. No
adjustments should be made to previously recorded amortization. When an entity replaces
existing internal use software with new software, the unamortized cost of the old software
should be expensed when the new software has successfully completed testing.
Disclosures
35. The disclosures required by SFFAS No. 6, paragraph 45, for general PP&E are applicable
to general PP&E software. Thus, for material amounts, the following should be disclosed in
the financial statements regarding the software:
• The cost, associated amortization, and book value.
• The estimated useful life for each major class of software.
• The method(s) of amortization.
• The above listed disclosure requirements are not applicable to the U.S. government-
wide financial statements. SFFAS 32 provides for disclosure applicable to the U.S.
government-wide financial statements for these activities.
9
For example, federal agencies use the following planning guidance: OMB Circulars A-11, Budget Planning,
Budgeting, and Acquisition of Fixed Assets; A-94, Guidelines and Discount Rates for Benefit-Cost Analysis of Federal
Programs; and A-109, Acquisition of Major Systems; OMB’s Capital Programming Guide (July 1997); GAO’s
Assessing Risks and Returns: A Guide for Evaluating Federal Agencies’ IT Investment Decision-making (Feb. 1997);
and other federal guidance.
SFFAS 10
Page 12 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
Implementation
36. Alternative Methods for Establishing Opening Balances.
9A
The following guidance is
applicable for the reporting period when the reporting entity is presenting financial
statements, or the line item addressed by this Statement, following generally accepted
accounting principles (GAAP) promulgated by FASAB either (1) for the first time or (2) after
a period during which existing systems could not provide the information necessary for
producing such GAAP-based financial statements without use of the alternative methods.
The following should be considered in establishing opening balances:
a. The alternative methods for establishing opening balances may be applied for the
reporting period in which the reporting entity, taken as a whole, makes an unreserved
assertion
9B
that its financial statements, or the line item addressed by this Statement,
are presented fairly in accordance with GAAP. The alternative methods provided in
this Statement should also be applied to correct subsequently discovered errors in
general PP&E that were valued under an alternative method.
b. The application of these alternative methods based on the second condition specified
in paragraph 36 is available only once to each reporting entity.
c. A reporting entity that meets either condition in paragraph 36 and elects to apply any
of the alternative methods available in establishing opening balances is subject to the
reporting requirements under paragraph 13 of Statement of Federal Financial
Accounting Standards 21, Reporting Corrections of Errors and Changes in
Accounting Principles, Amendment of SFFAS 7, Accounting for Revenue and Other
Financing Sources.
d. Alternative Methods. A reporting entity should choose among the following alternative
methods for establishing an opening balance for internal use software. Because a
reporting entity may have multiple component or subcomponent reporting entities
9C
9A
Opening balances are account balances that exist at the beginning of the reporting period. Opening balances are
based upon the closing balances of the prior period and reflect the effects of transactions and events of prior periods
and accounting policies applied in the prior period. Opening balances also include matters requiring disclosure that
existed at the beginning of the period, such as contingencies and commitments.
9B
An unreserved assertion is an unconditional statement.
9C
SFFAS 47, Reporting Entity, provides that “component reporting entity” is used broadly to refer to a reporting entity
within a larger reporting entity. Examples of component reporting entities include organizations such as executive
departments and agencies. Component reporting entities would also include subcomponents that may themselves
prepare general purpose federal financial reports (GPFFRs). One example is a bureau that is within a larger
department that prepares its own standalone GPFFR.
SFFAS 10
Page 13 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
selecting different alternative methods, a reporting entity should establish an opening
balance based on one, or a combination, of these alternative methods. However,
application of a particular alternative method must be consistent within each individual
subcomponent reporting entity prior to consolidation into the larger component
reporting or reporting entity.
i. Alternative Valuation Method. Deemed cost
9D
is an acceptable valuation method
for opening balances of internal use software. See SSFAS 6 paragraph 40.d. for
implementation guidance regarding deemed cost.
ii. Prospective capitalization. The reporting entity may choose prospective
capitalization of internal use software. If the reporting entity elects prospective
treatment, the reporting entity should choose between the following acceptable
alternative methods at the opening balance date:
(a) Exclude all internal use software, inclusive of that under development at the
opening balance date, from the opening balance.
(b) Exclude internal use software in service from the opening balance, but include
amounts related to internal use software under development at the opening
balance date. Internal use software under development should be recognized
in opening balances based on the provisions of paragraphs 15 through 27 or
on the alternative valuation method (deemed cost) provided in paragraph
36.d.i.
e. Once established using alternative methods, opening balances are considered
consistent with GAAP.
f. Component Reporting Entity Disclosures:
i. A component reporting entity electing to apply deemed cost in establishing
opening balances for internal use software should disclose this fact and describe
the methods used in the first reporting period in which the reporting entity makes
an unreserved assertion that its financial statements, or one or more line items,
are presented fairly in accordance with GAAP. Financial statements or, as
applicable, reports on line items of subsequent periods need not repeat this
disclosure, unless the financial statements for which deemed cost was applied in
establishing opening balances are presented for comparative purposes. No
9D
Deemed cost is an amount used as a surrogate for initial amounts that otherwise would be required to establish
opening balances.
SFFAS 10
Page 14 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
disclosure of the distinction or breakout of the amount of deemed cost of internal
use software included in the opening balance is required.
ii. A component reporting entity electing to apply the provisions of paragraph 36.d.ii.
should disclose this fact and describe the alternative methods used in the first
reporting period in which the component reporting entity makes an unreserved
assertion that its financial statements, or one or more line items, are presented
fairly in accordance with GAAP. In the event different alternative methods are
applied by subcomponent reporting entities consolidated into a larger reporting
entity, the alternative method adopted by each significant subcomponent should
be disclosed. Financial statements or, as applicable, reports on line items of
subsequent periods need not repeat this disclosure, unless the statements for
which the alternative method was applied in establishing opening balances are
presented for comparative purposes. No disclosure of the distinction or breakout
of amount of deemed cost of internal use software included in the opening
balance is required.
g. Financial Report of the U.S. Government Disclosures:
i. When a component reporting entity elects to apply deemed cost, the U.S.
government-wide financial statements should disclose this fact, the identity of the
component reporting entity, and a reference to the component reporting entity’s
financial report. Subsequent financial statements need not repeat this disclosure
unless the financial statements for which deemed cost was applied in establishing
opening balances are presented for comparative purposes. No disclosure of the
distinction or breakout of the amount of deemed cost of internal use software
included in the opening balance is required.
ii. When a component reporting entity elects to apply the provisions of paragraph
36.d.ii.,the U.S. government-wide financial statements should disclose this fact,
an explanation of the election, the identity of the component reporting entity, and a
reference to the component reporting entity’s financial report.
The provisions of this Statement need not be applied to information if the effect of applying the
provision(s) is immaterial. Refer to Statement of Federal Financial Accounting Concepts 1,
Objectives of Federal Financial Reporting, chapter 7, titled Materiality, for a detailed discussion
of the materiality concepts.
SFFAS 10
Page 15 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
Appendix A: Basis For Conclusions
This Statement may be affected by later Statements. The FASAB Handbook is updated annually
and includes a status section directing the reader to any subsequent Statements that amend this
Statement. Within the text of the Statements, the authoritative sections are updated for changes.
However, this appendix will not be updated to reflect future changes. The reader can review the
basis for conclusions of the amending Statement for the rationale for each amendment.
General Property, Plant, And Equipment
37. As stated in Statement of Federal Financial Accounting Standards (SFFAS) No. 6,
Accounting for Property, Plant, and Equipment, paragraph 10, the Federal Accounting
Standards Advisory Board (Board) believes that measuring the cost associated with using
general property, plant, and equipment (PP&E), and including that cost in a federal entity’s
operating results will help to achieve the operating performance objective. To meet the
operating performance objective, the Board seeks to provide accounting standards that will
result in
• relevant and reliable cost information for decision-making by internal users,
• comprehensive, comparable cost information for decision-making and program
evaluation by Congress and the public, and
• information to help assess the efficiency and effectiveness of asset management.
38. The Board believes that the cost of software acquired or developed for internal use that
meets the SFFAS No. 6 criterion for general PP&E should be capitalized. Internal use
software is specifically identifiable, can have determinate lives of 2 years or more, is not
intended for sale in the ordinary course of operations, and has been acquired or constructed
with the intention of being used by the entity.
10
39. This standard does not apply to software that is an integral part of stewardship property,
plant, and equipment. For example, if software is a part of a weapons systems, it would not
be capitalized but included in the cost of investing in that weapons system. On the other
hand, software used to accumulate the cost of acquiring that weapons system or to manage
and account for that item would meet the criteria for general PP&E and should be
capitalized.
10
See SFFAS No. 6, par. 17.
SFFAS 10
Page 16 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
40. Regarding any costs of internal use software acquired or developed for stewardship PP&E
or stewardship investments, the Board chose to follow SFFAS No. 6, Accounting for
Property, Plant, and Equipment, and SFFAS No. 8, Supplementary Stewardship Reporting,
and expense them as incurred. For example, a research project may involve new software
applications for computer simulation or modeling and meet the definition of a stewardship
investment in research and development. In such cases, that software should be expensed
as part of that research and development stewardship investment. However, software used
to manage, account for, and report on research and development projects and activities
would meet the criteria for general PP&E and should be capitalized.
Comparison With SFFAS No. 6
41. As explained in the following paragraphs and in subsequent sections of the Basis for
Conclusions, the accounting standard for internal use software required some tailoring of
the provisions in SFFAS No. 6. First, the criteria in this standard for determining when to
start amortizing/depreciating differs from SFFAS No. 6. SFFAS No. 6 provides that for
constructed PP&E, depreciation begins when the PP&E is “placed in service.” However, this
standard defines the start of amortization for internal use software as the point when final
acceptance testing is successfully completed. This additional criteria is necessary,
especially for internally developed software
—but also for contractor-developed and
commercial off-the-shelf (COTS) software
—because (1) testing plays a major role for
software assets by demonstrating that the software product can meet the requirements and
(2) of the need for clear point for ending the developmental phase.
42. A second area of tailoring involves “enhancements” and other potentially capitalizable
expenditures incurred after the software and/or other general PP&E is in service. SFFAS
No. 6 provides a criterion for capitalizable cost for general PP&E that is different from that
required here for software enhancements. SFFAS No. 6 provides that cost incurred to either
extend the useful life of existing general PP&E or to enlarge or improve its capacity should
be capitalized.
11
43. By contrast, this standard, as explained below, takes a different tack for software. It provides
that material expenditures to add capability/functionality would be capitalized but
expenditures that result in extending useful life or capacity would be expensed.
44. Finally, it should be noted that this standard provides additional procedures for recognizing
and measuring impairment. The provisions in this standard and in SFFAS No. 6 are the
11
Par. 37.
SFFAS 10
Page 17 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
same regarding situations where the software/general PP&E is impaired and will be
removed from service in its entirety. Both provide that the loss is measured as the difference
between the book value and the net realizable value, if any. However, as explained below,
this standard also provides for instances where (1) operational software is only partly
impaired and (2) developmental software becomes impaired.
Respondent’s Comments
45. The respondents to the exposure draft (ED), Accounting for Internal Use Software, generally
agreed with the principles presented therein. Most of the respondents agreed that the cost
of internal use software and enhancements thereto should be capitalized, that capitalized
amounts should be written down or off when the software is impaired, and that the guidance
in the ED was sufficient to identify capitalizable cost and to recognize impairment. Two-
thirds of the respondents agreed with the capitalization point in the ED
—after (1)
management authorizes and commits to funding a project and believes that it is more likely
than not that the project will be successful and (2) the preliminary design stage is complete.
46. Some respondents raised objections and concerns, similar to those expressed in response
to the original PP&E exposure draft, about capitalizing software, especially internally
developed software. They were concerned that distinguishing between the cost of new
and/or enhanced software on the one hand and maintenance and routine improvements
that do not benefit future periods on the other hand would be difficult. Other respondents
noted the rapidity with which technology changes and current software becomes obsolete,
and said that the risky and uncertain nature of software development makes write-off much
more likely for software than for general PP&E.
47. Notwithstanding these objections, the Board continues to believe that internal use software
is similar to other general PP&E and should be accounted for accordingly. Internal use
software and other information technology products and services are important resources
for government operations. They are subject to similar risks of impairment and write-off and,
otherwise, have general PP&E characteristics. Moreover, some respondents said they were
already capitalizing their COTS software, which represents a large and growing percentage
of their software portfolio.
48. The Board believes that the difference between internal use software and other general
PP&E is not sufficient to justify different accounting treatment. This standard provides
guidance for determining when capitalization starts and stops, how to amortize the software,
how to determine and measure impairment, and other guidance.
SFFAS 10
Page 18 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
Cost-Benefit
49. Several of the respondents opposed the capitalization of internal use software because they
do not believe that the benefits of doing so are worth the cost. The respondents are
concerned about the difficulty and cost of evaluating, measuring, and tracking such
information. Some respondents point especially to the difficulty of allocating federal
employees’ salaries and contractors’ cost in multiuse contracts (e.g., systems development
and maintenance).
50. Some argue (1) that capitalized internal cost related to developing internal use software is
often unrelated to the software’s actual value or is irrelevant, (2) that capitalization would
result in arbitrary values and amortization periods, and (3) that such cost is frequently
written-off, causing readers to be misled by the initial capitalization and subsequent write-
off.
51. In Statement of Federal Financial Accounting Concepts No. 1, Objectives of Federal
Financial Reporting, the Board points out that recommending accounting standards
necessarily involves judgments about the cost and benefits of producing information and
that standards can have different effects on different users. The Board is concerned that the
benefits from standards should exceed the cost of complying with them but realizes that the
benefits from standards are very hard to quantify.
12
52. The Board is persuaded that the benefits from this standard exceed the cost. The Board
believes that internal use software meets the definition of general PP&E and that general
PP&E ought to be capitalized as an asset and amortized to the future periods benefited.
53. Capitalizing software contributes to the effective management of federal entities’ resources.
The careful measurement of the cost to construct capital assets, the matching of such cost
to periods and programs benefitted on the federal entity’s statement of net cost, and the
comparison of cost with other alternatives for achieving the entity’s goal comprise good
management. Moreover, the regular review of software assets for impairment provides an
early warning of problems. In short, such information provides periodic feedback about the
quality and competitiveness of software products and services.
13
12
Also, see OMB Circular A-130, Management of Federal Information Resources, par. 7d, which establishes the goal of
having benefits exceed cost but notes that “the benefits to be derived from government information may not always be
quantifiable.”
13
See OMB Circular A-130, par. 8a, “Information Management Policy,” and par. 9b, as well as OMB’s Capital
Programming Guide, for detailed guidance on analyzing information technology through the planning, acquisition, and
management-in-use phases.
SFFAS 10
Page 19 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
54. The Board believes that expensing software costs incurred (1) in the preliminary design
stage, (2) for software repairs and improvements that increase efficiency and useful life (see
discussion of enhancements below), and (3) under materiality considerations will ease the
burden of complying with this standard. Federal entities incur cost in the preliminary design
stage exploring design and technical possibilities. Expensing this cost will limit the risk of
“over-capitalization.”
55. The Board realizes that software
—in general—and internally developed internal use
software
—in particular—present difficult materiality considerations. However, the Board
believes that federal entities will be able to use their discretion under the materiality
provisions of federal accounting standards to set reasonable limits to capitalization and
avoid incurring excessive cost in tracking de minimis items.
56. SFFAS No. 4 calls for the full cost of resources that directly and indirectly contribute to the
production of outputs to be assigned to outputs through appropriate costing methodologies.
Cost effectiveness is a key consideration in selecting a cost assignment method. As a
general rule, directly tracing costs and assigning costs on a cause-and-effect basis are more
expensive than cost allocations, because they require detailed analyses and record-keeping
for costs and activities. However, they are preferable because they produce more reliable
cost information than cost allocations.
14
In any case, the method used to trace, assign or
allocate costs must produce materially correct and complete costs.
57. The Board acknowledges that the service life of software is less predictable than that for
other general PP&E. However, the Board is not persuaded that the difficulties of estimation
and adjustment justify an accounting treatment different from that for other general PP&E.
The Board believes that the additional guidance in the standard versus that in the ED will
address the concerns raised by respondents and will be sufficient for federal entities to
comply with the standard.
Cost To Be Capitalized—Direct And Indirect Cost
58. Many respondents agreed with the ED position that indirect cost should be expensed. The
ED provided that such cost should be expensed because of cost-benefit considerations and
the risk of over-capitalization.
59. Several respondents objected to the failure of the ED to require indirect as well as direct
costs to be capitalized. Most of these respondents based their objection on the full-cost
14
SFFAS No. 4, par. 143.
SFFAS 10
Page 20 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
requirements in SFFAS No. 4, Managerial Cost Accounting Concepts and Standards for the
Federal Government, believing that the Board would not be consistent with this standard
unless full cost accounting were adopted.
60. The Board had reserved final judgment on the issue of capitalizing indirect cost at the time
the ED was published. Several of the Board’s members had argued that capitalizing only
direct cost was inconsistent with SFFAS No. 4. Also, some Board members felt that, if the
standard not did require indirect cost to be capitalized, the cost of internally developed
internal use software would not be comparable with COTS and contractor-developed
software, which would include indirect cost.
61. After reconsidering the issue, the Board is persuaded that SFFAS No. 4 requires both direct
and indirect costs to be capitalized. Moreover, the new federal capital programming
guidelines
15
require full life-cycle cost to be tracked, which is a more extensive requirement
than that required by this standard, since it includes cost that would be expensed for
accounting purposes.
16
Also, software asset values will be comparable among internally
developed, COTS and contractor-developed software.
Commencing Capitalization
62. Two-thirds of the respondents agreed that capitalization should begin as described in
par. 21 of the ED (and par. 16 of this standard): that is, when (1) management authorizes
and commits to a software project and believes that it is more likely than not that the
software will be completed and (2) the preliminary design stage is complete. Two of these
respondents noted that the standard was consistent in this regard with the American
Institute of Certified Public Accountant’s (AICPA) draft Statement of Position (SOP).
17
Six
other respondents would begin to capitalize only when “technological feasibility” is
demonstrated.
18
Other respondents either would not capitalize internal use software under
any circumstances or only COTS software.
15
The Office of Management and Budget’s (OMB) Capital Programming Guide, Supplement to OMB Circular A-11, Part
3 (July 1997), integrates the various executive branch and statutory asset management initiatives, including the
Government Performance and Results Act, the Clinger-Cohen Act, and the Federal Acquisition Streamlining Act, into a
single, integrated capital-programming guide.
16
“Capital assets are land, structures, equipment, and intellectual property (including software) that ... have an
estimated life of two years or more... The cost of a capital asset is its full life-cycle cost, including all direct and indirect
cost for planning, procurement ... operations and maintenance, including service contracts and disposal.” Capital
Programming Guide, version 1.0, definition of capital asset, p. i (July 1997).
17
Published March 4, 1998 as SOP No. 98-1.
18
“Technological feasibility” is the criteria that the Financial Accounting Standards Board (FASB) used in Statement of
Financial Accounting Standards (SFAS) No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or
Otherwise Marketed.
SFFAS 10
Page 21 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
63. The Board has added a framework for identifying the stages of a software project. Also, the
standard now draws a sharper distinction between internally developed software on the one
hand and COTS and contractor-developed software on the other. However, the Board
believes that flexibility is needed so that the standard can be applied governmentwide.
64. One respondent asked for clarification regarding management’s commitment to the
software project. This is critical, since it is the starting point for the capitalization of software
cost. The Board believes that management’s authorization and commitment are a
recognizable point for major software projects. A “go/no go” decision should be a visible
milestone. Management should use its best judgment to identify when its commitment to a
major software project takes place.
65. The Board decided that the “technological feasibility” test in SFFAS No. 6, which follows the
Financial Accounting Standard Board’s Statement of Financial Accounting Standards
No. 86, should be changed. The Board believes that that test is appropriate for software
developed for sale or lease or otherwise marketed but is not applicable to internal use
software. Federal software should be capitalized because it is a long-lived operating asset
rather than inventory to be sold. However, federal entities normally do not develop software
for sale. If, in a rare instance, an entity should engage to develop software for another
federal entity, SFAS No. 86 would be applicable.
Software Licenses
66. One respondent asked for guidance on accounting for licenses for COTS software. The
Board had not discussed software licenses during its deliberations leading up to the
publication of the ED. Software licenses can cover periods ranging from the entire estimated
service life of the software (a “perpetual” license) to annual or more frequent periods and
are similar to leases of general PP&E.
67. The Board believes that it would be appropriate for the federal entity to apply lease
accounting concepts
19
and the entity’s existing policy for capitalization thresholds and for
bulk purchases to licenses. Immaterial costs would be expensed, but the entity should
consider whether period costs would be distorted by expensing the license.
19
See SFFAS No. 5, Accounting for Liabilities of the Federal Government, “Capital Leases,” pars. 43-46, and SFFAS
No. 6, Accounting for Property, Plant, and Equipment, par. 20, for federal accounting standards for leases.
SFFAS 10
Page 22 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
Capitalization Thresholds
68. In SFFAS No. 6, the Board carefully considered whether to take a prescriptive approach
regarding capitalization thresholds or to permit each entity to set its threshold in light of its
own particular operating environment. The Board decided that federal entities were too
diverse to require one threshold for all entities; hence, the Board adopted a materiality
approach whereby each entity establishes its own threshold as well as the guidance for bulk
purchases. The Board continues to believe that permitting management discretion in
establishing capitalization policies will lead to a more cost-effective application of the
accounting standards.
Data Conversion Cost
69. The issue of whether to capitalize all, some, or no data conversion cost is a difficult one.
Some argue that the cost of converting existing data to a new software system is analogous
to the types of cost that the Accounting Principles Board Opinion (APB) No. 17, Intangible
Assets, requires to be expensed as incurred because they are not specifically identifiable,
have indeterminate lives, or are inherent in a continuing business and related to an
enterprise as a whole
—such as goodwill (APB 17, par. 24). The Board is persuaded that
data conversion costs are operating costs and should be expensed.
Amortization Period
70. Most respondents said that no maximum period for amortization should be set in the
standard. One respondent asked for clarification regarding the meaning of the general
requirement that the amortization period be “consistent with management’s plan for use.”
Another respondent asked whether the amortization period should begin when capitalization
stops or when the system is put into use, saying that, often, there can be a significant time
lag between these two events. One respondent asked for clarification regarding incremental
implementation.
71. The Board has added additional guidance regarding the cessation of capitalization and
commencement of amortization. The standard now focuses on the point when testing is
complete. The term “operational,” which some respondents found vague, is no longer used
as a definitive point for cessation of capitalization. Also, provision has been made to treat
each location and/or module separately.
Enhancements
72. Several respondents requested additional guidance for distinguishing maintenance from
enhancements. The exposure draft proposed capitalizing the cost of changes to the existing
SFFAS 10
Page 23 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
system as an enhancement if it is more likely than not that the changes add capabilities or
useful life. One respondent asked whether the cost of changes that make the software or
system easier to use and users more efficient, but do not significantly change the
capability/functionality (i.e., the system does not do any additional tasks), should be
expensed or capitalized. Also, the ED proposed that year 2000 (Y2K) cost be expensed as
incurred, even though they extend useful life. Several respondents asked whether Y2K cost
were “enhancements.”
73. The Board believes that an “enhancement” should be limited to instances where significant
new capabilities are being added to the software. Merely making the software more efficient
and/or extending its service life should not constitute a capitalizable cost. Software is more
fluid and malleable than other PP&E and the Board concludes that a higher threshold for
additional capitalization is reasonable.
Impairment
74. Two-thirds of the respondents said that the guidance on impairment was sufficient. Several
respondents had questions about how the impairment provisions would apply to particular
situations.
75. A respondent asked whether the availability of a new, updated version of COTS software
with significantly improved functionality, efficiency, or effectiveness means that the older
version is impaired even if the older version is still performing the functions for which it was
designed. He asked whether the availability of new technology, whether adapted or not,
render existing software “impaired.” He asked about the affect of modernizing existing
software to take advantage of the new technology. This respondent was concerned that if
modernization is included in the definition of “impairment,” there will be constant write-
downs.
76. The Board believes that none of the situations cited by the respondent would meet the
criteria of this standard in paragraphs 28-31. According to the criteria, in order for software
to be considered impaired, it would have to have lost its service potential such that the
federal entity would plan to remove it from service or the software would have had its
capabilities reduced.
77. One respondent asked about the ED’s proposal for expensing Y2K cost. Since the
implementation date for this standard has been moved back to FY 2001, the issue is largely
moot. However, the Board’s rationale for recommending that the Y2K cost be expensed is
that such cost is incurred to repair a design flaw rather than to add to the software’s
capabilities or useful life, although the latter would be affected.
SFFAS 10
Page 24 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
Working Capital Funds
78. At least one respondent was concerned about the impact of capitalizing non-COTS internal
use software on the cash flows, billing rates, and performance measurement of working
capital funds (WCFs). This respondent said that developing software internally and through
contractors could require long lead times during which WCFs would have to finance the
project because WCFs could not start to recover the cost from customers until the software
project was complete and amortization commences. Also, this respondent said that write-
downs or write-offs due to impairment by rapidly changing technology would be difficult to
recapture from customers who expect and budget for consistent billing rates. This
respondent believes that the capitalization of internally developed or contractor-developed
software could result in fluctuating rates depending on when new projects come “on line”
and on write-downs or write-offs due to impairment.
79. This respondent said that if write-downs or write-offs cannot be recovered from customers,
then capital funds would be unavailable for investment, the WCFs’ equity could be seriously
impaired, and the WCFs would rapidly become unable to effectively provide the services for
which they were established. The respondent said that WCFs are vulnerable to capital
shortages because they operate on a break-even basis rather than generate retained
earnings, and because they do not have access to private capital markets. This
respondent’s WCF currently capitalizes COTS software because it is a proven commodity; it
becomes operational immediately and the WCF can begin chargingback the cost to
customers.
80. Fixed assets usually provide important future benefits but require large amounts of
resources up-front and extended periods for planning and acquisition. Making capital
planning decisions is often difficult for agencies because full budget authority is required
before the acquisition can commence and the entire acquisition has an immediate
budgetary impact. This makes capital assets look expensive relative to, for example, annual
lease payments even though the latter may be more expensive in the longrun.
20
81. Notwithstanding these very real concerns, the Board concludes that the WCFs problem is
one of budgetary control and program finance rather than of accounting. Congress has
instituted various alternatives for WCFs to acquire capital. The Board’s responsibility is to
recommend what it considers the best accounting treatment considering all the
circumstances and the Board’s objectives.
20
See GAO, Budget Issues: Budgeting for Federal Capital (GAO/AIMD-97-5 Nov. 1996), for (1) an analysis of capital
budgeting problems experienced by WCFs and federal agencies generally and (2) possible solutions.
Page 25 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
SFFAS 10
Implementation Date
82. The 23 respondents who addressed the question of the implementation date were almost
evenly divided as to the feasibility of an FY 1999 implementation date. Most respondents
opposing the FY 1999 date said that federal agencies do not have the cost accounting
systems as yet to account for capitalized cost but are developing such capabilities. Some
respondents said that most federal agencies have a great deal “on their plate” now, when
one considers the many recent initiatives. They said that an FY 2000 or FY 2001
implementation date would be better.
83. One respondent said that the AICPA’s SOP is effective for periods beginning after
December 15, 1998, and that there is no reason for the federal government to adapt such a
standard before the private sector does. The respondent said that federal implementation
after the private sector implements its standard would allow the federal government to learn
from the private sector’s experience.
84. The Board believes that federal entities are striving to meet deadlines for audited financial
statements, performance reports, cost accounting, technology management, and other
initiatives. Entities resources are under stress to meet these deadlines. Thus, the Board
believes that moving the implementation to FY 2001 is reasonable.
Page 26 - SFFAS 10 FASAB Handbook, Version 22 (12/23)
SFFAS 10
Appendix B: Glossary
See Consolidated Glossary in “Appendix E: Consolidated Glossary”.
