Financial Management Regulation Volume 4, Chapter 27

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-1

*VOLUME 4, CHAPTER 27: “INTERNAL USE SOFTWARE”

SUMMARY OF MAJOR CHANGES

Changes are identified in this table and also denoted by blue font.

Substantive revisions are denoted by an asterisk (*) symbol preceding the section,

paragraph, table, or figure that includes the revision.

Unless otherwise noted, chapters referenced are contained in this volume.

Hyperlinks are denoted by bold, italic, blue, and underlined font.

This is the initial publication.

PARAGRAPH

EXPLANATION OF CHANGE/REVISION

PURPOSE

Various

This chapter contains updated policy for internal use

software (IUS) based upon IUS policy contained in

Volume 4, Chapter 6, dated June 2009. As a result, the

existing policy in Volume 4, Chapter 6 related to IUS is no

longer applicable.

Revision

Various

The Federal Accounting Standards Advisory Board issued

a new accounting standard for leases with an effective date

for reporting periods beginning after September 30, 2020.

Policy has yet to be fully developed to implement this new

standard, which may result in changes to the capital lease

criteria. Until the new standard becomes effective, the

policy guidance in this chapter must be followed.

Revision

Policy Memo

The Deputy Chief Financial Officer policy memorandum,

“Strategy for Internal Use Software Audit Readiness,”

dated September 30, 2015 has been incorporated into the

chapter as applicable and is cancelled.

Cancellation

1.3

(270103)

Added “Authoritative Guidance” paragraph. Addition

2.1

(270201)

Added a definition for software and additional guidance for

distinguishing internal use software from integrated

software.

Addition

2.2

(270202)

Added relevant United States Standard General Ledger

accounts and their descriptions.

Addition

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-2

PARAGRAPH

EXPLANATION OF CHANGE/REVISION

PURPOSE

2.3

(270203)

Updated guidance for capitalized costs of internally

developed software; treatment of software development

costs; software developed by one activity and used by

others without reimbursement; software development

phases; and documentation. Added guidance for different

software development methods; cross-functional Internal

Use Software (IUS) reviews; determining accounting

treatment of different software development activities; and

capitalizable cost.

Revision/

Addition

2.4

(270204)

Updated guidance for recognition responsibility, including

recognition timing of contractor acquired property and

progress payments. Updated capitalization threshold

amounts and capitalization guidance. Revised recognition

guidance for bulk purchases of software. Added guidance

for IUS developed through a joint venture; for software

licenses; cloud and other subscription based services,

shared services; and guidance on accountable records of

IUS.

Revision/

Addition

2.5

(270205)

Added guidance addressing IUS enhancements. Addition

2.6

(270206)

Updated guidance for maintenance and repair of IUS. Revision

2.7

(270207)

Added guidance addressing amortization of IUS. Addition

2.8

(270208)

Added guidance addressing impairment of IUS. Addition

2.9

(270209)

Updated guidance addressing the removal/disposal of IUS. Revision

3.1

(270301)

Added guidance on the use of the “Canceled” Treasury

Account Symbol.

Addition

3.3

(270303)

Added guidance for reporting requirements. Addition

Figure 27-2

Added a capitalization decision tree for IUS.

Addition

Annex 1

Added an annex containing common terms used by

information technology and software programming

professionals, with corresponding examples, that are

relevant to IUS.

Addition

Annex 2

Added guidance for use as an alternative methodology for

establishing opening balances for IUS.

Addition

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-3

Table of Contents

*VOLUME 4, CHAPTER 27: “INTERNAL USE SOFTWARE” ............................................... 1

1.0 GENERAL (2701) ............................................................................................................. 4

1.1 Overview (270101) ........................................................................................................ 4

1.2 Purpose (270102) ........................................................................................................... 4

*1.3 Authoritative Guidance (270103)................................................................................... 4

2.0 ACCOUNTING FOR IUS (2702) ..................................................................................... 5

*2.1 Definition (270201) ........................................................................................................ 5

Figure 27-1. IUS is Generally One Component of an IT System ......................................... 6

*2.2 Relevant USSGL Accounts (270202) ............................................................................ 8

*2.3 Acquisition/Valuation (270203) ..................................................................................... 8

Table 27-1. Capital versus Expense IUS Activities ............................................................ 12

Table 27-2. Cross-Functional Review Decisions and Timeline .......................................... 14

*2.4 Recognition (270204) ................................................................................................... 17

Table 27-3. Capitalization is Dependent on Term and Aggregate Purchase Amount ......... 20

Table 27-4. Capital Lease Criteria as Applied to Licenses ................................................. 22

*2.5 IUS Enhancements (270205) ....................................................................................... 25

*2.6 Maintenance and Repair (270206) ............................................................................... 27

*2.7 Amortization (270207) ................................................................................................. 27

*2.8 Impairment (270208).................................................................................................... 30

*2.9 Removal/Disposal (270209) ......................................................................................... 32

3.0 ADDITIONAL CONSIDERATIONS (2703) ................................................................. 33

*3.1 Use of Canceled Treasury Account Symbol (270301) ................................................. 33

Table 27-6. Supporting Documentation for IUS Acquisition.............................................. 34

*3.3 Reporting Requirements (270303) ............................................................................... 36

*Figure 27-2. Capitalization Decision Tree for IUS Purchased from Commercial Off-the-

Shelf Vendors; IUS Internally Developed by DoD and IUS Developed by a Third Party on

Behalf of DoD 37

*Annex 1. Definitions and Examples .................................................................................... 1

*Annex 2. Alternative Valuation Methodology for Establishing Opening Balances for

Internal Use Software .................................................................................................................. 1

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-4

*CHAPTER 27

INTERNAL USE SOFTWARE

1.0 GENERAL (2701)

1.1 Overview (270101)

1.1.1. This chapter prescribes Department of Defense (DoD) accounting policy for

Internal Use Software (IUS), which is a subset of General Property, Plant, and Equipment (PP&E).

This overview paragraph will define and describe the characteristics of General PP&E.

1.1.2. General PP&E items are used in providing goods or services, or support the mission

of the entity, and typically have one or more of the following characteristics:

1.1.2.1. The item could be used for alternative purposes (e.g., by other DoD or

Federal Programs, state or local governments, or nongovernmental entities), but it is used to

produce goods or services, or to support the mission of the entity;

1.1.2.2. The item is used in business-type activities; and/or

1.1.2.3. The item is used by entities in activities whose costs can be compared to

those of other entities performing similar activities (e.g., federal hospital services in comparison

to commercial hospitals).

1.2 Purpose (270102)

The applicable general ledger accounts are listed in the government-wide United States

Standard General Ledger (USSGL) contained in Volume 1, Chapter 7. The accounting entries for

these accounts and the DoD Standard Chart of Accounts are specified in the

DoD USSGL Standard Transaction Library. Unless otherwise stated, this chapter is applicable

to all DoD Components, including Working Capital Fund (WCF) activities.

*1.3 Authoritative Guidance (270103)

The accounting policy and related requirements prescribed by this chapter are in

accordance with the applicable provisions of:

1.3.1. Federal Accounting Standards Advisory Board (FASAB) Statement of Federal

Financial Accounting Concepts (SFFAC) 5, “Definitions of Elements and Basic Recognition

Criteria for Accrual-Basis Financial Statements;”

1.3.2. FASAB SFFAC 7, “Measurement of the Elements of Accrual-Basis Financial

Statements in Periods After Initial Recording;”

1.3.3. FASAB Statement of Federal Financial Accounting Standards (SFFAS) 1,

“Accounting for Selected Assets and Liabilities;”

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-5

1.3.4. FASAB SFFAS 4, “Managerial Cost Accounting Standards and Concepts;”

1.3.5. FASAB SFFAS 10, “Accounting for Internal Use Software;”

1.3.6. FASAB SFFAS 50, “Establishing Opening Balances for General Property, Plant,

and Equipment: Amending Statement of Federal Financial Accounting Standards (SFFAS) 6,

SFFAS 10, and SFFAS 23, and Rescinding SFFAS 35;”

1.3.7. FASAB Technical Release (TR) 13, “Implementation Guide for Estimating the

Historical Cost of General Property, Plant, and Equipment;”

1.3.8. FASAB TR 14, “Implementation Guidance on the Accounting for the Disposal of

General Property, Plant & Equipment;”

1.3.9. FASAB TR 15, “Implementation Guidance for General Property, Plant, and

Equipment Cost Accumulation, Assignment and Allocation;”

1.3.10. FASAB TR 16, “Implementation Guidance for Internal Use Software;”

1.3.11. FASAB TR 17, “Conforming Amendments to Technical Releases for SFFAS 50,

Establishing Opening Balances for General Property, Plant, and Equipment;”

1.3.12. FASAB TR 18, “Implementation Guidance for Establishing Opening Balances;”

1.3.13. Office of Management and Budget Circular No. A-136, “Financial Reporting

Requirements;”

1.3.14. DoD Instruction (DoDI) 5000.76; “Accountability and Management of Internal

Use Software (IUS);” and

1.3.15. Treasury Financial Manual (TFM) Volume1, Part 2, Chapter 4700 "Agency

Reporting Requirements for the Financial Report of the United States Government."

2.0 ACCOUNTING FOR IUS (2702)

*2.1 Definition (270201)

2.1.1. “Software” includes the application and operating system programs, procedures,

rules, and any associated documentation pertaining to the operation of a computer system or

program. Most often, software is an integral part of an overall system(s) having interrelationships

between software, hardware, personnel, procedures, controls, and data. IUS is software that:

2.1.1.1. Is acquired or developed to meet the entity’s internal or operational needs

(intended purpose); and

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-6

2.1.1.2. Is a stand-alone application, or the combined software components of an

information technology (IT) system that can consist of multiple applications, modules, or other

software components integrated and used to fulfill the entity’s internal or operational needs

(software type).

Figure 27-1. IUS is Generally One Component of an IT System

Equipment,

Embedded

Software,

Installation

Labor

G/L 175000 or

G/L 172000

Software and

Development Labor

G/L 183000 or

G/L 183200

Period Expenses

and General

Labor

G/L 610000

IT System

IUS

2.1.2. IUS can be:

2.1.2.1. Purchased from commercial off-the-shelf (COTS) vendors and be ready

for use with little or no changes;

2.1.2.2. Internally developed by employees of DoD, including new software and

existing or purchased software that is modified with or without a contractor’s assistance; or

2.1.2.3. Contractor-developed software that a DoD Component paid a contractor

to design, program, install, and implement, including new software and the modification of

existing or purchased software.

2.1.3. IUS includes software that is:

2.1.3.1. Used to operate an entity’s programs (e.g., financial and administrative

software, including that used for project management);

2.1.3.2. Used to produce the entity’s goods and to provide services

(e.g., maintenance work order management and loan servicing); and

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-7

2.1.3.3. Developed or obtained for internal use and subsequently provided to

other Federal Entities with or without reimbursement.

2.1.4. Integrated (embedded) software is not IUS.

2.1.4.1. IUS does not include computer software that is integrated into and

necessary to operate General PP&E, rather than perform an application. Such software must be

considered part of the PP&E of which it is an integral part, and capitalized and amortized

accordingly (e.g., software embedded in airport radar, computer-operated lathes, military

equipment/weapon systems and special test equipment). The aggregate cost of the hardware and

software must be used to determine whether to capitalize or expense the costs. In situations where

software and the hardware on which it runs have independent service lives, the determination of

the useful life of the software must be viewed independently of the useful life of the hardware.

The determination must be made on a case-by-case basis. The rationale for this determination

must be documented.

2.1.4.2. Software used in conjunction with the operation of equipment, which is

not the same as the integrated or embedded software, can be considered IUS if all of the following

criteria apply:

2.1.4.2.1. The software was developed separately from the equipment;

2.1.4.2.2. The software is not required for the equipment to perform its

core purpose and functions; and

2.1.4.2.3. The quantity of equipment items on which the software will

be installed is unknown.

2.1.5. DoD entities may purchase IUS as part of a package of products and services

(e.g., training, maintenance, data conversions, reengineering, site licenses and rights to future

upgrades and enhancements). If the costs are not readily separable between the IUS and the

services on the invoice, contract or other procurement documents, costs should be allocated based

on the relative fair values of the IUS and the services. The cost of the IUS should be capitalized

(assuming it meets the capitalization criteria) and the cost of the training/maintenance should be

expensed. Non-IUS costs (e.g., training and maintenance services) that are not susceptible to

allocation between maintenance and relatively minor enhancements must be expensed.

2.1.6. Materiality, as defined by the SFFAS 1, is the degree to which an item's omission

or misstatement in a financial statement makes it probable that the judgment of a reasonable person

relying on the information would have been changed or influenced by the inclusion or correction

of the item.

2.1.7. Additional definitions can be found in Annex 1.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-8

*2.2 Relevant USSGL Accounts (270202)

2.2.1. Fund Balance with Treasury (Account 101000). This account is used to record the

aggregate amount of funds on deposit with the United States Department of the Treasury,

excluding seized cash deposited.

2.2.2. Internal Use Software (Account 183000). This account is used to record the

amount of capitalized cost of IUS for those costs that are to be capitalized in accordance with

Table 27-1. It includes (1) purchased COTS software, (2) contractor-developed software, and

(3) internally developed software.

2.2.3. Internal Use Software in Development (Account 183200). This account is used to

record the full cost amount incurred for those costs that are to be capitalized in accordance with

Table 27-1 during the software development phase of (1) contractor-developed software and

(2) internally developed software, (as defined in SFFAS 10). Upon completion, these costs will

be transferred to USSGL account 183000, Internal Use Software. There is no Generally Accepted

Accounting Principles (GAAP) requirement to establish a separate account for each software under

development. However, DoD Components may elect to create separate subaccounts to better

differentiate and track costs.

2.2.4. Accumulated Amortization on Internal Use Software (Account 183900). This

account is used to record the accumulated amount of amortization charges to expense for IUS.

2.2.5. General Property, Plant, and Equipment Permanently Removed but Not Yet

Disposed (Account 199500). The General Property, Plant, and Equipment Permanently Removed

but Not Yet Disposed account is used to record the value of General PP&E assets that have been

permanently removed from service. Upon permanent removal from service, IUS assets must be

recorded at their expected net realizable value (NRV) and must cease to be amortized. See

paragraph 270209 for guidance on reporting IUS assets that have been permanently removed from

service.

2.2.6. Gains on Disposition of Assets – Other (Account 711000). This account is used to

record the gain on the disposition (such as sale, exchange, disposal, or retirement) of assets not

associated with investments or borrowings/loans.

2.2.7. Losses on Disposition of Assets – Other (Account 721000). This account is used

to record the loss on the disposition (such as sale, exchange, disposal, or retirement) of assets not

associated with investments or borrowings/loans.

*2.3 Acquisition/Valuation (270203)

2.3.1. Recorded Cost. When acquiring IUS, the acquisition cost and other costs necessary

to bring the software to an operable condition must be recognized in accordance with paragraph

270204.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-9

2.3.1.1. COTS Software. The capitalized cost of COTS software must be the

actual purchase price, plus any costs incurred to place the software in service or otherwise make

the software ready for use.

2.3.1.2. Contractor-Developed Software. The capitalized cost of

contractor-developed software must include the amount paid to the contractor to design, program,

install, and implement new software or to modify existing or COTS software, plus any costs

incurred to implement or otherwise make the software ready for use.

2.3.1.3. Internally Developed Software. The capitalized costs of internally

developed software must include the full cost (direct and indirect costs, as described in

subparagraphs 270203.A.4.a, 270203.A.4.b and 270203.A.4.c) incurred after:

2.3.1.3.1. The DoD Component authorizes and commits to a 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(s), and it will have an estimated service life

of two years or more; and

2.3.1.3.2. The completion of the conceptual planning/planning and

requirements phase (i.e., project evaluation, concept testing, and evaluation alternatives) as

evidenced by a documented approval decision.

2.3.1.4. Table 27-1. This table provides a matrix of the software project phases

and their related processes. The treatment of costs must be applied based on the nature of the costs

incurred, not the exact sequence of the work. Full cost includes the costs of new software

(e.g., salaries of programmers, systems analysts, project managers, and administrative personnel;

associated employee benefits; outside consultants’ fees; rent; and supplies and overhead) and

technical documentation. The development of technical documentation and manuals must be

capitalized, but the costs of mass-producing manuals should be expensed in the period incurred.

The various types of costs incurred during the software project phases include:

2.3.1.4.1. Direct Labor Costs. Direct labor costs are typically the labor

costs of project teams (e.g., programmers, engineers, managers) incurred during the

Design/Development and Testing/Implementation Phase and are capitalized as part of the costs of

the software project. Project managers and/or program managers must track direct labor cost and

allocate to individual software projects. The allocation methodology must be consistent between

projects and must be auditable.

2.3.1.4.2. Indirect Labor Costs. Indirect labor costs are typically the

labor costs associated with the Program Management Office (PMO) personnel responsible for

overseeing more than one software project. In many instances, PMO indirect labor costs are

immaterial when compared with the overall costs of a software project, and if determined to be

immaterial, can be expensed. Decisions regarding the materiality of indirect labor costs, when

such costs are expensed, must be justified, documented, and must be able to stand up to audit

scrutiny. If indirect labor costs are determined to be material to a software project or projects and

are to be distributed to the capitalized costs of such project, the costs must be allocated based on a

distribution methodology that is consistently applied, documented and auditable.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-10

2.3.1.4.3. Overhead Costs. Overhead costs are those costs associated

with utilities, building maintenance, and supplies that are essential to the overall accomplishment

of a software project. In many instances, overhead costs are immaterial when compared with the

overall costs of a software project and if determined to be immaterial, the DoD Components should

expense these costs. Decisions regarding the materiality of overhead costs when such costs are to

be expensed must be justified, documented, and must be able to stand up to audit scrutiny. If

overhead costs are determined to be material to a software project or projects and are to be

distributed to the capitalized costs of such project, the costs must be allocated based on a

distribution methodology that is consistently applied, documented and auditable.

2.3.1.4.4. Contractor Costs. Contractor costs must be evaluated to

determine whether the costs are to be expensed or capitalized. Such determination is based on the

type of work performed by the contractors. Table 27-1 provides a breakdown of the various work

activities and whether the cost of such activities must be expensed or capitalized.

2.3.1.4.5. Data Conversion Costs. All data conversion costs incurred for

internally developed, contractor developed, or COTS software must 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 costs may include the purging or cleansing of existing data,

reconciliation or balancing of data, and the creation of new or additional data.

2.3.2. Software Development Phases Determine Recorded Cost (Internally Developed

Software). Software’s life-cycle phases include planning, development, and operations. This

subparagraph provides a framework for identifying software development phases and processes to

help isolate the capitalization period for IUS that the DoD entity is developing. The three phases

of software development described in subparagraph follow a linear software development method.

Generally, costs incurred during the development phase are to be capitalized and costs incurred in

other phases are to be expensed. However, software development under other methods does not

follow this linear approach and capitalization decisions absent distinct phases are more difficult.

Regardless of timing, the cost incurred for development phase activities must be capitalized or

expensed based on their substance/task activity rather than their phase. The three phases of

software development are:

2.3.2.1. Conceptual Planning/Planning and Requirements Phase. In this phase,

the DoD Components will most likely do the following:

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

2.3.2.1.2. Determine performance requirements (i.e., what it is that they

need to do)?

2.3.2.1.3. Invite vendors to perform demonstrations of how their

software will fulfill a DoD Component’s needs.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-11

2.3.2.1.4. Explore alternative means of achieving specified performance

requirements. For example, should a DoD Component make or buy the software? Should the

software run on a mainframe or client server system?

2.3.2.1.5. Determine that the technology needed to achieve performance

requirements exists.

2.3.2.1.6. Select a vendor if a DoD Component chooses to obtain COTS

software.

2.3.2.1.7. Select a consultant to assist in the software’s development or

installation.

2.3.2.2. Software Design/Development and Testing/Implementation Phase. In

this phase, the DoD Components will likely to do the following:

2.3.2.2.1. Use a system to manage the project;

2.3.2.2.2. Track and accumulate life-cycle cost and compare it with

performance indicators;

2.3.2.2.3. Determine the reasons for any deviations from the

performance plan and take corrective actions;

2.3.2.2.4. Test the deliverable to verify that they meet the specifications.

2.3.2.3. Operations and Maintenance/Disposition Phase. In this phase, the

DoD Components will likely to do the following:

2.3.2.3.1. Operate the software, undertake preventative maintenance,

and provide ongoing training for users;

2.3.2.3.2. Convert data from the old to the new system;

2.3.2.3.3. Undertake post-implementation review comparing asset usage

with the original plan; and/or

2.3.2.3.4. Track and accumulate life-cycle cost and compare it with the

original plan.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-12

Table 27-1. Capital versus Expense IUS Activities

(Adapted from SFFAS 10, paragraph 11)

Project Phase

Task

Treatment

Conceptual Planning/

Planning & Requirements

Project Evaluation

Expense

Concept testing

Expense

Evaluation of alternatives

Expense

Project approval

Expense

Design/

Development & Testing/

Implementation

Design

Capitalize

Coding

Capitalize

Installation to Hardware

Capitalize

Project personnel costs

Capitalize

Technical Acceptance

Testing

Capitalize

Quality assurance testing

Capitalize

Documentation

Capitalize

Overhead costs

Allocate

Data conversion software

Expense

Operations & Maintenance/

Disposition

Training

Expense

Data conversion

Expense

Help desk

Expense

Enhancement

See “IUS Enhancements”

paragraph 270205.

Maintenance/Bug Fix

Expense

PROGRAM MANAGEMENT

The costs of program management and the PMO that may be incurred during each phase of

software development or acquisition are indirect costs. PMO indirect costs should be

expensed or capitalized, depending on: 1) their materiality to overall costs of individual

software development projects, and 2) in which phase the costs are incurred.

2.3.3. Software Development Methods. Software development methods are ever

evolving, with new methods and techniques being introduced over time. Included in the following

subparagraphs are several descriptive examples of common software development methods.

2.3.3.1. Linear/Waterfall Software Development Method. The linear/waterfall

software development method is a sequential design process, used in software development in

which progress is seen as flowing steadily downwards (like a waterfall) through the software

development phases. The linear/waterfall software development method follows the phases

outlined in Table 27-1 in sequence, whereas the other software development methods as described

in subparagraphs 270203.C.2 through 270203.C.4 can move between phases during the life of the

development. Regardless of the development method (e.g., waterfall, prototyping, agile, or spiral),

the capitalization decisions follow the tasks identified.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-13

2.3.3.2. Prototyping Software Development Method. The prototyping software

development method is a system development method in which a prototype (an early

approximation of a final system or product) is built, tested, and then reworked as necessary until

an acceptable prototype is finally achieved from which the complete system or product can be

developed. This model works best in scenarios where not all of the project requirements are known

in detail ahead of time. An iterative, trial-and-error process takes place between the developers

and the users.

2.3.3.3. Agile Software Development Method. The agile software development

method is a group of software development methods in which requirements and solutions evolve

through collaboration between self-organizing, cross-functional teams.

2.3.3.3.1. In an agile project, working software is deployed in iterations

of typically one to eight weeks in duration, each of which provides a segment of functionality.

Initial planning regarding cost, scope, and timing is usually conducted at a high level, and the

project status is primarily evaluated based on software demonstrations.

2.3.3.3.2. The IUS development phases listed in subparagraph 270203.B

could be applied to agile development projects on an iteration basis. If an iteration developed

meets the module or component asset description in accordance with subparagraph 270203.F.3

and the capitalization cut-off period described in subparagraph 270203.F.6, then it could be treated

as an individual IUS project. If the numbers of iterations are dependent on the outcomes of

multiple processes for a complete function, the cost incurred in these iterations should be grouped

together based on the nature of the activities (capital or expense) and treated as one project for the

purposes of recognition, measurement, and disclosure. Any future incremental releases that result

in additional functionality can be treated as an enhancement of the original IUS project and

accounted for in accordance with paragraph 270205.

2.3.3.4. Spiral Software Development Method. The spiral software development

method combines the features of the waterfall and prototyping incremental models, but with more

emphasis placed on risk analysis and management.

2.3.3.4.1. The spiral methodology projects are typically separated into

phases like the waterfall method: planning, risk analysis, engineering, and evaluation. However,

they are broken up into incremental releases of the product, or incremental refinement through

each time around the spiral and through continuously analyzing the requirements and improving

the definition and implementation. At each iteration around the cycle, the project is improved and

extended.

2.3.3.4.2. The IUS development phases listed in subparagraph 270203.B

could be applied to a spiral development project on a process iteration basis. If an iteration

developed meets the module or component asset description in accordance with subparagraph

270203.F.3 and the capitalization cut-off period described in subparagraph 270203.F.6, then it

could be treated as an individual IUS project. If the number of iterations are dependent on the

outcomes of multiple spiral processes for a complete function, the cost incurred in these iterations

should be grouped together based on the nature of the activities (capital or expense) and treated as

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-14

one project for the purposes of recognition, measurement, and disclosure. Any future incremental

releases that result in additional functionality can be treated as an enhancement of the original IUS

project and accounted for in accordance with paragraph 270205.

2.3.4. Cross-Functional IUS Reviews. Software development can be complex and

accounting decisions often require a measure of judgment and expertise found throughout an

organization. Examples of these decisions can include identifying assets that meet the IUS

definition, determining the point at which an IUS project is more likely than not to be completed,

whether an enhancement should be capitalized, and determining the useful life. DoD Components

will ensure that key stakeholders from the IUS program, acquisition, and accounting organizations

have adequate visibility into the major milestones throughout the acquisition process to make these

decisions. This could take the form of an IUS acquisition review board, consisting of

knowledgeable stakeholders who assess pending and active IUS projects to make such decisions.

It could also include leveraging portfolio management processes already in place at some

DoD Components. Stakeholders will meet periodically and with enough frequency to make timely

decisions concerning the IUS and the decisions will be documented. Additional cross-functional

decisions and deadlines for making them are found in Table 27-2. This review activity can also

serve as a key control.

Table 27-2. Cross-Functional Review Decisions and Timeline

Decision

Decision Timeline

Identify potential IUS

During the budget process and not later than

end of planning phase

Determine that it is more likely than not that

the IUS project will be completed

Prior to the completion of the planning

phase

Assign a useful life

Prior to the end of final technical acceptance

testing

Confirm that cost has been correctly

accumulated and assigned to the asset

Prior to the end of final technical acceptance

testing

Confirm that indirect costs have been

appropriately allocated

Prior to the end of final technical acceptance

testing

Assign an in-service date

Upon completion of final technical acceptance

testing

Determine if licenses meet capital lease

criteria

Upon license agreement execution

Decision

Decision Timeline

Identify potential capital enhancements

During the budget process and not later than

end of planning phase

Management Oversight Decisions

•

Impairment

•

Evaluation of suspended projects

o More likely than not that the project will

be completed

o More likely than not that the project

will be cancelled

On-going

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-15

2.3.5. Capital Versus Expense IUS Activities. Many IUS programs and contracts include

a variety of activities that are conducted by government and/or contractor personnel throughout

the software development life cycle. Some costs associated with these activities should be

capitalized as part of the cost of the IUS and some costs should be expensed. Regardless of the

software development method (e.g., waterfall, prototyping, agile, or spiral), the capitalization

decisions follow the activity. When reviewing contracts and budget documentation, care must be

taken to distinguish between activities that are to be capitalized and those that are to be expensed.

Refer to Table 27-1 for additional details on capital versus expense for IUS activities.

2.3.6. Capitalizable Cost

2.3.6.1. DoD Components must capitalize the cost of software when such

software meets the criteria for General PP&E (see subparagraph 270204.E).

2.3.6.2. Costs related to capitalized activities identified in Table 27-1 must be

accumulated in account 183200 (Internal Use Software in Development), but are not amortized

until the software is placed-in-service. Costs should begin accumulating in this account if the IUS

is anticipated to meet capital criteria and the criteria listed in subparagraph 270203.A.3 have been

met.

2.3.6.3. Accumulated costs must be transferred to account 183000 (Internal Use

Software) when the IUS is placed-in-service (see placed-in-service dates in subparagraph

270207.C). Many larger and more complex software systems, such as Enterprise Resource

Planning systems, are developed and placed-in-service over time. For each module or component

of a software project, costs must be moved from account 183200 (Internal Use Software in

Development) to account 183000 (Internal Use Software), and amortization must begin when a

module or component has been successfully tested. If the use of a module is dependent on the

completion of another module(s), the movement from 183200 to 183000 will take place and

amortization will begin when both that module and the other module(s) have successfully

completed testing. For example, a DoD Component may develop an accounting software system

containing three modules: a general ledger, an accounts payable sub-ledger, and an accounts

receivable sub-ledger. In this example, each module could be analyzed to determine whether it

could be treated as a separate IUS asset. Specifically, if the module provides economic benefit

through distinct, substantive functionality, and meets the tests for capitalization threshold,

ownership, and eligibility for capital treatment, then the module could be treated as a separate IUS

asset.

2.3.6.4. Capitalized IUS costs must have sufficient supporting documentation as

discussed in paragraph 270302, including support for costs incurred in the development of the IUS.

Documentation in the form of narratives, software architectural documentation, user manuals and

other similar documents supporting the functionality of the components/modules of a software

system must be available to substantiate whether the IUS should be treated as separate IUS assets.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-16

2.3.6.5. The full cost (direct and indirect cost as described in subparagraphs

270203.A.4.a through 270203.A.4.d) incurred during the software development phase must be

capitalized. Considering economic feasibility, a cost estimation technique could be developed to

trace the costs to outputs based on the SFFAS 4, paragraph 124, provision that “[in] principle,

costs should be assigned to outputs in one of the methods listed in the order of preference:

2.3.6.5.1. Directly tracing costs wherever economically feasible;

2.3.6.5.2. Assigning costs on a cause-and-effect basis; and

2.3.6.5.3. Allocating costs on a reasonable and consistent basis.

2.3.6.6. Costs incurred after final technical acceptance testing has been

successfully completed must be expensed (see Table 27-1). Technical acceptance testing is testing

undertaken to verify if a software product meets technical specifications. Technical acceptance

testing costs are capitalizable costs. Operational testing and evaluation and other functional testing

conducted after technical acceptance must be expensed. Similarly, if the software consists of

multiple individual components or modules, the capitalization phase must end for each

component/module after technical acceptance testing is complete for that component/module. In

some development practices, each iteration within an IUS development has its own acceptance

testing before moving forward to the next iteration and final acceptance testing may not always be

performed. The entity should identify a pre-determined agency milestone such as the go-live or

in-service date, which is equivalent to a final technical acceptance test for capitalization cut-off

purposes.

2.3.6.7. For COTS software, capitalized costs must include the amount paid to

the vendor for the software. For contractor-developed software, capitalized costs must include the

amount paid to a contractor to design, program, install, and implement the software. Material

internal costs incurred by the Federal Entity to implement the COTS or contractor-developed

software and otherwise to make it ready for use must be capitalized.

2.3.7. Documentation

2.3.7.1. When recording the acquisition of IUS in the Accountability Property

System of Record (APSR) and/or accounting system, the software must be assigned a dollar value

(i.e., recorded cost) as detailed in this chapter. Appropriate documentation must be available to

support the dollar value. Paragraph 270302 includes a complete discussion of supporting

documentation related to IUS.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-17

2.3.7.2. To establish proper PP&E financial control when acquiring IUS from

another DoD Component or Federal Agency, the acquiring DoD Component must request from

the losing DoD Component or other Federal Agency, the necessary source information and

financial transfer documents, to include unique identifier(s) for the software(s); location; original

acquisition cost(s); cost of enhancements; the date the software was developed, or acquired; the

estimated useful life; the amount of accumulated amortization; and other relevant information

linked to that software. If this information is not available, the gaining and losing entities must

develop and document a reasonable estimate to support the financial transfer of the software.

*2.4 Recognition (270204)

DoD Components must recognize all acquired IUS for accountability and financial

reporting purposes. Recognition requires the proper accounting treatment (expense or

capitalization with amortization) and the reporting of capitalized amounts and accumulated

amortization on the appropriate DoD Component’s financial statements. For financial reporting

purposes, all IUS that has a useful life of two years or more and meets the capitalization criteria

described in subparagraph 270204.E must be capitalized. IUS that does not meet the capitalization

threshold must be expensed.

2.4.1. Recognition Responsibility

2.4.1.1. The DoD Component’s financial reporting responsibility can be

determined using a two tier criteria:

2.4.1.1.1. Exclusive/sole Use. When a DoD Component is the

exclusive/sole user of capitalized IUS, it will report the IUS on its Balance Sheet. If there is no

exclusive/sole user, the DoD Component must apply the second criteria.

2.4.1.1.2. Control. If an exclusive/sole user does not exist, the

DoD Component that controls the IUS will have financial reporting responsibility. Evidence of

control can include funding the software maintenance, exercising access control, and prioritizing

enhancements.

2.4.1.2. DoD Components that possess and/or control IUS items that materially

contribute to the Component’s mission must maintain accounting and financial reporting for such

items, regardless of the organization that originally acquired or provided the funding for the items.

If a DoD Component prepares financial statements, such IUS items must be appropriately

recognized in its financial statements.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-18

2.4.2. Recognition Uncertainty

2.4.2.1. It is important that the overall accounting records of the DoD and the

Federal Government are not duplicative. In situations where doubt exists as to which

DoD Component should recognize an item, DoD Components involved must reach agreement

with the other applicable DoD Components or Federal agencies as to which entity will recognize

the item. The process used to reach this agreement and the terms of the agreement must be

documented in a memorandum of agreement and be considered supporting documentation.

2.4.2.2. If an agreement cannot be reached, the matter must be referred to the

Office of the Deputy Chief Financial Officer, Office of the Under Secretary of Defense

(Comptroller) for resolution. Requests for resolution must be accompanied by adequate supporting

documentation to assist in resolution of the matter and be submitted through the Financial

Management and Comptroller of the submitting Military Department or Defense Agency.

2.4.3. Recognition Timing

2.4.3.1. Recognition of the COTS IUS for financial reporting purposes must

occur no later than the technical acceptance of the software.

2.4.3.2. IUS in development must be recorded in the Internal Use Software in

Development account (USSGL 183200) during the design, development and testing, and

implementation phases. After technical acceptance testing is completed, an IUS asset will be

recognized, capital costs will be transferred to the Internal Use Software account

(USSGL 183000), and accountability must be established in the APSR.

2.4.3.3. For IUS assets acquired by a contractor on behalf of a DoD Component

(i.e., the DoD Component that will ultimately hold title/license to the assets), the software must be

recognized upon completion of the technical acceptance testing by the contractor performing the

service, or by the DoD Component. Contract financing payments (e.g., progress payments,

performance-based payments, and commercial interim payments) made to a contractor prior to

completion of final technical acceptance testing must be recorded in a Software in Development

account until the IUS is placed-in-service. Upon completion of technical acceptance testing, the

Contractor Acquired Property (CAP) must be capitalized in the appropriate USSGL account. See

subparagraph 270203.F for guidance on the use of the Software in Development account.

2.4.4. Capitalization Thresholds

2.4.4.1. The current IUS capitalization threshold for all DoD Components is

$250,000, except for the Office of the Director of National Intelligence, for which the

capitalization threshold is $1 million.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-19

2.4.4.2. IUS with a cost that equals or exceeds the appropriate capitalization

threshold must be capitalized according to subparagraph 270204.E as an asset in the appropriate

DoD Component’s accounting records and amortized over its useful life. IUS items with a cost

below the appropriate capitalization threshold must be expensed; with the exception of IUS items

acquired as part of a qualifying bulk purchase (see subparagraph 270204.G).

2.4.4.3. The capitalization threshold described in subparagraph 270204.D.1 is for

financial reporting purposes. The requirement for accountability of IUS is discussed in

subparagraph 270204.K.

2.4.5. Capitalization Criteria

2.4.5.1. IUS is recognized and capitalized if it meets the following criteria for

General PP&E:

2.4.5.1.1. Useful life of two years or more;

2.4.5.1.2. Intended for use or being available for use by the entity;

2.4.5.1.3. Not intended for sale in the normal course of business; and

2.4.5.1.4. Total cost is greater than DoD Component’s capitalization

threshold (as described in subparagraph 270204.D).

2.4.5.2. As development work accumulates, the costs must be entered into an

Internal Use Software In Development account (183200). When the IUS passes final technical

acceptance testing, the accumulated costs must be removed from the “In Development” account

and transferred to the Internal Use Software account (183000). Accounting entries for this account

are specified in the DoD USSGL Transaction Library.

2.4.6. Joint Ventures

If IUS is developed through a joint venture between two or more entities, including at least

one entity outside of the DoD, the DoD Component must capitalize the IUS asset if it meets the

criteria for capitalization, based on its portion of the development cost in relation to the

capitalization threshold. The DoD Component will only record the portion it funded which will

be capitalized if it meets the criteria for capitalization.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-20

2.4.7. Bulk Purchases of Software Applications/Programs

2.4.7.1. Bulk purchases must be considered if they may materially affect the

fiscal year financial statements during which they were purchased. The determination of whether

an item is material depends on the degree to which omitting or misstating information about the

item makes it probable that the judgment of a reasonable person relying on the information would

have been changed or influenced by the omission or the misstatement. To ensure that the

statements are not materially affected, new bulk purchases of software with an aggregate cost that

exceeds the capitalization threshold must be capitalized.

2.4.7.2. An exception to this requirement includes license agreements that do not

meet the criteria established for capital leases in subparagraph 270204.H. Costs related to such

purchases must be expensed in the period incurred.

2.4.7.3. When multiple acquisitions of the same IUS application(s)/programs

(for example spreadsheets, word processing programs, etc.) or modules or components of a

software system are made as part of a single contract within a fiscal year, the purchases must be

added together to determine whether they meet the capitalization threshold. Purchases made on a

single contract during separate fiscal years are to be considered separately. DoD Components

must not split bulk purchases into multiple transactions with the intent of avoiding capitalization.

2.4.7.4. Bulk purchases of licensed IUS with terms less than two years in length

do not need to be considered for capitalization. Table 27-3 provides capitalization guidelines for

bulk purchase licenses.

Table 27-3. Capitalization is Dependent on Term and Aggregate Purchase Amount

Bulk Purchased License Terms

Aggregate Purchase Amount

Guidance

License Term < 2 years

N/A

Expense

License Term = / > 2 years or Perpetual

Under capitalization threshold

Expense

License Term = / > 2 years or Perpetual

Equal to or exceeding capitalization

threshold*

Capitalize

*Maintenance agreements included in the purchase of licenses are not to be considered part of the

cost for this determination.

2.4.8. Software Licenses

2.4.8.1. Software licenses are defined as licenses for which the license holder is

only entitled to use the software for a specified time period, after which the right to use the software

expires and the license must be renewed or a new license purchased in order to continue using the

software. License agreements to use software come in many forms and vary in length of the license

period. Software licenses can be term or perpetual.

2.4.8.1.1. Term licenses provide the right to use the software for a

specified period of time. The determination of whether term licensed IUS will be capitalized or

not must be based on lease accounting concepts in which the criteria in Table 27-3 are applied.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-21

2.4.8.1.2. Perpetual software licenses give the DoD Component the right

to use the software in perpetuity in exchange for an upfront cost, which could be charged as a

one-time payment or financed over a set period of time. If the license is perpetual, then the entity

is purchasing the IUS and must apply the capitalization criteria to determine if the license must be

capitalized or expensed.

2.4.8.2. If one of the following criteria applies, the IUS can be expensed and the

lease criteria analysis does not need to be conducted:

2.4.8.2.1. The license term is less than two years;

2.4.8.2.2. The license cost (excluding any maintenance agreements) is

less than the capitalization threshold; or

2.4.8.2.3. The aggregate cost of a bulk license purchase (excluding any

maintenance agreements) is less than the capitalization threshold. See subparagraph 270204.G for

guidance related to bulk purchases of software.

2.4.8.3. If none of the criteria listed in subparagraph 270204.H.2 is applicable,

the capital lease criteria described in Table 27-4 must be applied. If any one or more of the criteria

listed in Table 27-4 apply, the IUS must be recorded as a capital lease.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-22

Table 27-4. Capital Lease Criteria as Applied to Licenses

Criteria

Comment

The license transfers ownership of the

property to the licensee by the end of the

license term.

For IUS, this would mean that the license transfers

ownership of the intellectual property (e.g., source

code) to the licensee by the end of the license term.

The license contains an option to purchase

the software at a bargain price.

For IUS, this would mean that the license contains an

option to purchase the software intellectual property

(e.g., source code) at a bargain price.

The present value of minimum license

payments, excluding that portion of the

payments representing executory cost, equa

or exceeds 90 percent of the fair value of the

software.*

It is very unusual for software to meet this criteria.

The value of the software itself typically far outweighs

a license to use a copy of it.

The license term is equal to or greater than

75 percent of the estimated economic life of

the software.*

Some licenses may meet this criteria. Economic life is

defined as the estimated remaining period during

which the property is expected to be economically

usable by one or more users, with normal repairs and

maintenance, for the purpose for which it was

intended at the inception of the lease, without

limitation by the lease term. For example, a perpetual

license will always be equal or greater than 75 percent

of the estimated economic life. A license term of 5

years for software that has an economic life of 10

years would not meet this criteria.

* The last two criteria are not applicable when the beginning of the license term falls within the last 25

percent of the total estimated economic life of the software.

2.4.8.4. A license agreement may include executory costs for maintenance and

technical support. DoD Component judgment should apply in determining what portions of

license fees are attributable to software capitalizable costs versus executory costs. Assuming lease

capitalization criteria and thresholds are met, software license capitalization amounts may be

derived from the payment schedule contained in the license agreement. As stated in SFFAS 5, if

the portion of the minimum lease payments representing executory cost is not determinable from

the lease provisions, the amount should be estimated. DoD Components may also want to consider

having each license agreement specifically identify the various costs throughout the license life

cycle, for example, initial license, maintenance, and enhancement.

2.4.8.5. Additional guidance regarding accounting for license agreements

includes:

2.4.8.5.1. Maintenance costs agreed to as part of the initial license

agreement are to be expensed in the period they are incurred;

2.4.8.5.2. “True-up” costs associated with unlimited license agreements

or enterprise licenses that may occur (depending on the agreement terms) at the end of each year

to reconcile and account for the actual quantity of users will also be expensed; and

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-23

2.4.8.5.3. Software upgrades that are included in annual maintenance

and security assurance agreements should be expensed, not be capitalized as enhancements or

separate assets.

2.4.8.6. License agreements that do not meet the criteria established for capital

leases set out in Table 27-4 must be expensed by the DoD Component in the period incurred.

2.4.9. Cloud and Other Subscription Based Services

2.4.9.1. A cloud computing service is any resource that is provided over the

Internet. It has the following essential characteristics: on-demand self-service, broad network

access, resource pooling, rapid elasticity, and measured service. The most common cloud service

resources are: software as a service, platform as a service, and infrastructure as a service. Cloud

services can take a number of forms. To determine whether the arrangement includes capitalized

IUS, the DoD Component will need to examine the nature of the arrangement and apply the

capitalization criteria.

2.4.9.2. When a DoD Component pays regular subscription fees to access and

use software that is funded, maintained, and owned by a non-DoD entity, the subscription costs

are to be expensed in the period incurred. This scenario is a service and does not constitute an IUS

asset for the DoD Component.

2.4.9.3. A subscription arrangement using a cloud with a non-DoD entity can

result in DoD-owned IUS if the using DoD Component takes possession, or has the ability to take

possession of a software application without incurring a significant penalty. DoD Components

must capitalize this IUS if it meets the capitalization criteria as described in subparagraphs

270204.D and 270204.E.

2.4.9.4. When a cloud or subscription arrangement exists between

DoD Components, the Component that owns the software (see subparagraph 270204.A) will report

it as IUS. The subscribing DoD Component(s) will expense any fees paid for the service in the

period incurred.

2.4.9.5. If a cloud computing arrangement includes a software license, the

customer must account for the software license element of the arrangement consistent with the

acquisition of other software licenses in accordance with the lease criteria discussed in

subparagraph 270204.H. SFFAS 10 is not applicable to a cloud computing arrangement that does

not convey a contractual right to the IUS or to ones that do not include an IUS license. The entity

that develops and owns the software, platform or infrastructure used in the cloud computing

arrangement would account for the software development in accordance with SFFAS 10. If the

funding to develop cloud computing is shared among entities without clear ownership, the service

provider entity that receives funding and is responsible for maintaining the software, platform or

infrastructure must account for the software in accordance with SFFAS 10 and the full

cost/inter-entity cost requirements of SFFAS 4.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-24

2.4.10. Shared Services

2.4.10.1. Shared services means a mission or support function provided by one

business unit to other business units within or between organizations. The funding and resourcing

of the service is shared and the providing entity effectively becomes an internal/external service

provider.

2.4.10.2. There are three types of shared service structures in the Federal

Government:

2.4.10.2.1. Intra-agency. Intra-agency shared services include those

provided within the boundaries of a specific organization such as a Federal Department or Agency,

to that organization’s internal units. Intra-agency shared services would be those between one

DoD Component and another DoD Component.

2.4.10.2.2. Inter-agency. Inter-agency shared services are those

provided by one Federal Organization to other Federal Organizations that are outside of the

provider’s organizational boundaries. Inter-agency shared services would be those between one

DoD Component and another Federal Agency/Organization outside of DoD.

2.4.10.2.3. Commercial. Commercial shared services are those provided

by private vendors.

2.4.10.3. For intra-agency shared services, a cost allocation methodology could

be developed in accordance with SFFAS 4, paragraphs 120-125. Additional guidance on cost

allocation methodology can be found in the Volume 4, Chapter 19. For inter-agency shared

services and commercial shared services, the service provider entity that owns

(receives funding/responsible for maintaining) the software must account for the software in

accordance with SFFAS 10. In the event that the entity receiving the service (the customer) has

the contractual right to take possession of the software at any time during the hosting period

without significant penalty, and it is feasible for the customer to either run the software on its own

hardware or contract with another party unrelated to the vendor to host the software, then the

customer must account for the software in accordance with SFFAS 10.

2.4.10.4. If the shared service arrangement includes a software license, the

DoD Component must account for the software license element of the arrangement consistent with

the acquisition of their other software licenses, as discussed in subparagraph 270204.H. SFFAS 10

is not applicable to a shared service arrangement that does not convey a contractual right to the

IUS or to ones that do not include an IUS license.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-25

2.4.11. Accountable Records of IUS

DoD Components must establish accountable records for all government IUS purchased or

otherwise obtained. IUS which meets the criteria for capitalization must be accounted for in an

APSR. IUS which does not meet the criteria for capitalization must be accounted for in either an

APSR or approved managerial system. Managerial systems must contain all general data elements

that would be contained in a data compliant APSR. In addition, managerial systems must have

documented controls and procedures in place that are sufficient to withstand potential audit

scrutiny and support the audit requirement of a complete universe of assets. The primary

Accountable Property Officer or designated delegate should grant managerial system approval.

See DoDI 5000.76.

*2.5 IUS Enhancements (270205)

2.5.1. An IUS enhancement is a modification to existing IUS that provides it with

significant additional capabilities and enables the software to perform tasks that it was previously

incapable of performing. DoD Components must capitalize an enhancement that increases the

capability of the IUS when its cost meets or exceeds the capitalization threshold. Criteria to

capitalize enhancements to IUS differs from that of other PP&E in that changes that merely extend

the useful life or improve efficiency are to be expensed, irrespective of the cost. (Even though the

costs associated with the extension of useful life are expensed, the amortization of any previously

capitalized amount must be extended to reflect that new useful life period.) Capitalizable

enhancements normally require new software specifications and may require a change to all or

part of the existing software specifications. For example, DoD Components should capitalize the

cost of modifying existing software for making ad hoc queries, if it required new software

specifications and/or changes to existing software specifications and it also exceeds the

capitalization threshold. In addition, the DoD Components should expense the nominal charges

paid for enhanced versions of software in the period incurred.

2.5.2. If one module is dependent upon another to function, then those modules must be

evaluated together as one enhancement. Components must amortize all costs of an enhancement

that have been capitalized based on the IUS capitalization criteria, including any costs carried over

or allocated from the original software, over the enhancements estimated useful life, which should

not exceed five years.

2.5.3. DoD Components must begin accumulating costs for enhancements when it is

determined that it is more likely than not that the enhancement will result in new capabilities; and

the project phase in which the costs are being incurred and the nature of the cost meets the criteria

for capitalization treatment set out in Table 27-1; and the estimated total cost of the enhancement

meets the IUS capitalization threshold. When the development of the enhancement takes place

over multiple periods, the costs will accumulate in account 183200 (Internal Use Software in

Development) until the completion of the enhancement (see subparagraph 270207.C on

placed-in-service dates), at which time the costs are moved to account 183000 (Internal Use

Software).

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-26

2.5.4. DoD Components must separately account for enhancements in a manner that

allows them to specifically identify and support each capitalized enhancement made to the IUS.

2.5.5. An enhancement to IUS that meets or exceeds the capitalization threshold to correct

a design flaw, and in effect doubles its useful life, must be expensed in the period incurred, unless

the enhancement adds new capabilities to the software. However, the useful life of the IUS is

subject to adjustment and must reflect the enhancement. Knowledgeable personnel must

determine and document the additional useful life, which should not exceed five years added to

the existing useful life.

2.5.6. The cost of minor enhancements resulting from ongoing systems maintenance or

incurred solely to repair a design flaw without adding additional capabilities must be expensed in

the period incurred. Examples of minor enhancements include updating data tables, web-enabling,

customizing reports, or changing graphic user interfaces. Enhancements that extend the useful life

of the software without adding significant capabilities are to be considered minor enhancements

and expensed. However, in instances where the useful life of the software is extended, the

amortization period must be adjusted as described in subparagraph 270205.E.

2.5.7. A specific software development project may include expenditures for

enhancements and maintenance that cannot be easily separated but may be reasonably and

consistently allocated. One approach that can be used is a ratio based on the projected work hours

for development phase activities relative to other types of work. Such a ratio can be applied to

determine the expenditures that should be capitalized when the expenses meet the other

capitalization criteria. The basis for allocating costs must be applied consistently and in

accordance with GAAP.

2.5.8. Documentation related to IUS enhancement decisions, such as the justification for

capitalizing the enhancement, a change of useful life, and the amount capitalized must be retained.

Specific documents that support these decisions can vary by organization and asset, but could

include an analysis from software developers or a cross-functional review team that defines the

enhancement’s impact on functionality and useful life.

2.5.9. The cost of enhancements to more than one IUS asset as identified by a unique

identifier, when performed under a single contract or work order that cannot be specifically

identified by asset must be capitalized only if the allocated cost per IUS equals or exceeds the

appropriate DoD capitalization threshold and the enhancements are determined more likely than

not to add additional capability to the existing software.

2.5.10. When a single IUS goes under more than one enhancement and the enhancements

are part of one overall effort to increase the software’s functionality, and/or useful life; the sum of

the costs of the enhancements must be capitalized, if the summed costs equal or exceed the

appropriate DoD capitalization threshold. This is required even when the enhancements are

funded separately. The enhancements must be capitalized when the determination has been made

that it is more likely than not that the enhancements will result in new significant capabilities.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-27

*2.6 Maintenance and Repair (270206)

2.6.1. Maintenance and repair costs are not considered capital enhancements, regardless

of whether the cost equals or exceeds DoD capitalization threshold. Maintenance and repairs are

activities directed toward keeping IUS asset in an acceptable condition so that it continues to

provide services and achieves its expected useful life. Maintenance and repair activities include

subsequent security accreditations (not included in user acceptance testing); software diagnostics;

repair processing and/or performance failures; updates to documentation; minor software updates;

minor corrections to design flaws; and other activities needed to preserve or maintain the software.

Maintenance and repairs, as distinguished from enhancements, exclude activities directed towards

expanding the capacity of IUS or otherwise upgrading it to serve needs different from, or

significantly greater than, its current use.

2.6.2. The costs of maintenance agreements purchased with a software license are not

included in the historical cost of IUS when determining whether to capitalize the IUS. If

maintenance costs are not distinguishable from the cost of the license itself, reasonable and

documented estimating methods must be used. Upgrades that are included in annual maintenance

and security assurance agreements will not be capitalized as enhancements or separate assets.

*2.7 Amortization (270207)

2.7.1. Amortization is the systematic and rational allocation of the acquisition cost of IUS,

over its estimated useful life. The DoD recovery periods (useful life) for IUS amortizable assets

are set out in Table 27-5. The useful life must be determined during the planning phase of the

software development, based on the length of time it is expected to have economic benefit or

service potential to the DoD Component. The decision on the useful life must be documented and

made with input from personnel familiar with the software’s technical characteristics and planned

use. Software acquired for research and development with no alternative future use will be

amortized over the period of the project as opposed to the normal life-cycle amortization.

2.7.2. The recorded cost of IUS and enhancements to IUS, which have been capitalized

according to the guidance in Table 27-1, must be amortized. Such capitalized amounts, as well as

associated amounts of accumulated amortization and amortization expense, must be reflected in

DoD Component’s financial statements.

2.7.3. DoD Components must document the placed-in-service dates for both acquired

IUS and developed IUS. Documented placed-in-service dates are critical in determining when to

start amortization of capitalized IUS costs. IUS is considered placed-in-service when final

technical acceptance testing is completed. The point at which this milestone is reached can vary

for different types of software acquisitions.

2.7.3.1. For IUS acquired through a Major Automated Information System

acquisition program, the Full Deployment Decision date made by the Milestone Decision

Authority will serve as the placed-in-service date.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-28

2.7.3.2. For other IUS system acquisitions, the Initial Operational Capability

(IOC) date will be used as the placed-in-service date. System’s Capability Development

Document (CDD) and/or Capability Production Document (CPD) often define the IOC.

DoD Components can use other supporting documents for acquisitions that do not require a CDD

or CPD.

2.7.3.3. If knowledgeable parties within a DoD Component determine that a

placed-in-service date other than the ones listed in subparagraphs 270207.C.1 and C.2 better align

to the completion of final technical acceptance testing for a specific software acquisition, the

alternate placed-in-service date can be used. However, the DoD Components must document and

justify the decision.

2.7.4. Before beginning amortization, the IUS must have successfully completed final

acceptance testing. This criteria is necessary, especially for internally developed software but also

for contractor-developed and COTS software because testing plays a major role for software assets

by demonstrating that the software product can meet the requirements and of the need for a clear

point for ending the developmental phase.

2.7.5. When IUS is replaced with new software, the unamortized cost of the old software

must be expensed when the new software successfully completes testing. No adjustments will be

made to the previously recorded amortization. Any additions to the book value or changes in

useful life must be treated prospectively. The change should be accounted for during the period

of the change and future periods.

2.7.6. All IUS must be accounted for in an APSR. Figure 27-2 provides a decision tree

to assist in determining what elements of an IUS project should be capitalized for financial

reporting purposes.

2.7.7. Proper supporting documentation must be retained by the program office to justify

the estimated useful life of the program. Examples of proper documentation are engineering

estimates, operational requirements documents, mission needs statements, commercial

industry-equivalent information, contracts, and acquisition documents (such as the

Select Acquisition Report). See paragraph 270302 for additional information on supporting

documentation requirements.

2.7.8. In the case of IUS assets, after the successful completion of the final technical

acceptance testing described in subparagraph 270270.D, the event that triggers the calculation of

amortization is the date the asset is installed and placed-in-service (regardless of whether it is

actually used). In the case of internally developed IUS, the costs of developing the IUS that are

capitalizable should be recorded in the Internal Use Software in Development account (183200)

but are not amortized until the software is placed-in-service, at which time the balance

(total capitalizable development costs) should be transferred to the Internal Use Software

account (183000). Amortization should begin when a module or component has been successfully

tested. If the use of a module is dependent on the completion of another module(s), the movement

from account 183200 to account 183000 will take place and amortization will begin when both

that module and the other module(s) have successfully completed testing and are placed-in-service.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-29

2.7.9. DoD policy permits the use of only the straight-line method of amortization.

Straight-line amortization expense is calculated based on the recorded cost divided equally among

accounting periods during the software’s useful life based on recovery periods in Table 27-5. The

salvage value for all capitalized IUS for the DoD Components should be zero.

2.7.10. If an IUS asset remains in use longer than its estimated useful life, it must be

retained in the APSR, as well as the accounting records, and reflect both its recorded cost and

accumulated amortization until disposition of the software.

2.7.11. WCF activities are required to recognize and amortize IUS assets in accordance

with the guidance in this chapter without regard to whether such assets are procured through a

WCF activity’s Capital Purchase/Investment Program budget or whether amortization for such

assets is included in rates charged to customers. The recognition of IUS assets and the amortization

of such assets by WCF activities therefore may be different for financial statement reporting

purposes than the amortization amounts used for WCF rate development and budget presentation.

All IUS asset amortization of WCF activities must be recognized as an expense on the Statement

of Net Cost, reflected in the Statement of Changes in Net Position, included in accumulated

amortization amounts on the Balance Sheet, and reported in the “Defense Working Capital Fund

Accounting Report [Accounting Report (Monthly) 1307] (AR(M)1307).” Accounting Report 1307

is described in Volume 6a Chapter 15. Amortization recorded on IUS assets that was not acquired

nor will be replaced through use of Defense WCF resources must be classified as non-recoverable

for rate setting purposes and reported appropriately on the AR(M)1307. Defense WCF rates

charged to customers are based on guidance in Volume 2B and Volume 11B.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-30

Table 27-5. DoD Recovery Periods for Amortizable IUS Assets

DOD RECOVERY PERIODS FOR AMORTIZABLE IUS ASSETS

(IUS is capitalized only if it meets the capitalization threshold)

Description of IUS Assets

Recovery Period

Capitalized IUS

2, 3, 4, 5 or 10 Years*

Licenses

Term of the license agreement

Perpetual Licenses

5 Years

IUS Upgrades

Not capitalized**

Enhancements

Not more than 5 years***

* The useful life will be determined during the planning phase of the asset’s development based on the

length of time it is expected to have economic benefit or service potential to the DoD Component.

** The amortization period of an IUS must be adjusted (not extending more than 5 years) if minor

upgrades resulting from ongoing systems maintenance or repair of a design flaw extend the useful life

of the software without adding additional capabilities. The cost of the upgrades should be expensed in

the period incurred. Also note

the upgrades that do add additional capabilities would be considered

enhancements and would be capitalized and amortized if they meet the capitalization criteria in

subparagraph 270204.E.

***See paragraph 270205 on the criteria for capitalizing versus expensing of IUS enhancements.

*2.8 Impairment (270208)

2.8.1. Impairment must be recognized and measured when one of the following occurs

and is related to post-implementation/operational software:

2.8.1.1. The software is no longer expected to provide substantive service

potential and will be removed from service; or

2.8.1.2. A significant reduction occurs in the software’s or software module’s

capabilities, functions, or uses.

2.8.2. If the impaired software is to remain in use, the loss due to impairment must be

measured as the difference between the book value and either:

2.8.2.1. The cost to acquire software that would perform similar remaining

functions (i.e., the unimpaired functions) or, if that is not feasible;

2.8.2.2. The portion of the book value attributable to the remaining functional

elements of the software.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-31

2.8.3. The loss must be recognized upon impairment, and the book value of the asset

reduced accordingly. If neither criteria listed in subparagraph 270208.B can be determined, the

DoD Component should continue to amortize the book value over the remaining useful life of the

software. However, this decision and associated analyses must be documented and retained.

2.8.4. If the impaired software is to be removed from use, the loss due to impairment must

be measured as the difference between the book value and the NRV, if any. The loss must be

recognized upon impairment, and the book value of the asset reduced accordingly. The NRV, if

any, must be transferred to an appropriate asset account until the software is disposed of and the

amount is realized.

2.8.5. When it is more likely than not that a developmental software project will not be

completed, no further costs are to be capitalized and any costs that have been capitalized must be

expensed. Indications that the software development may no longer be completed include:

2.8.5.1. The expenditures are neither budgeted nor incurred to fund further

development;

2.8.5.2. The discontinuance of the business segment for which the software was

designed;

2.8.5.3. The inability to resolve programming difficulties timely;

2.8.5.4. A decision to obtain COTS software instead and abandon the current

software development; or

2.8.5.5. Major cost overruns occur.

2.8.6. When a developmental software project is suspended pending management’s

evaluation as to whether to resume or terminate the project, the software development cost may

remain capitalized in an Internal Use Software in Development account (USSGL 183200) as long

as it is more likely than not that the developmental software project will eventually be completed

and the cost incurred or expected to be incurred meets the capitalization threshold. The status of

the project must be reevaluated periodically and the capitalized cost must be written off if

management concludes that it is more likely than not that the software will not be placed-in-service

in the future.

2.8.7. The loss from impairment, if any, must be recognized and reported in the Statement

of Net Cost in the period in which the DoD Component concludes that the impairment is both

(1) a significant decline in service utility and (2) expected to be permanent. Such losses may be

included in program costs or costs not assigned to programs. A general description of the IUS for

which an impairment loss is recognized, the nature (e.g., damage or obsolescence) and amount of

the impairment and the financial statement classification of the impairment loss must be disclosed

in the notes to the financial statements in the period the impairment loss is recognized if the amount

is significant to the financial statements.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-32

2.8.8. The impairment loss must be reported net of any associated recovery of the net

realizable value when the recovery and loss occur in the same fiscal year. Recoveries reported in

subsequent fiscal years must be reported as revenue or other financing source as appropriate. The

amount and financial statement classification of recoveries must be disclosed in the notes to the

financial statements.

2.8.9. The costs incurred to replace or restore the lost service utility of impaired IUS

remaining in use must be accounted for in accordance with applicable standards (i.e., recognized

according to the nature of the costs incurred and the appropriate capitalization threshold).

*2.9 Removal/Disposal (270209)

2.9.1. In TR 14, FASAB defines removal from service as an event that terminates the use

of a General PP&E asset. Removal from service may occur because of a change in the manner or

duration of use, change in technology or obsolescence, damage by natural disaster, or identification

as excess to mission needs. Removal from service must be considered other than permanent unless

(1) the asset’s use is terminated and (2) there is documented evidence of the DoD Component’s

decision to permanently remove the asset from service. If only one of the two business events has

occurred, permanent removal from service has not occurred (i.e., the removal is considered other

than permanent).

2.9.2. If an IUS’s normal use is terminated (i.e., it no longer provides service in the

operations of the entity) but the DoD Component has not yet decided to permanently remove the

IUS from service, the removal from service is considered other than permanent. Other than

permanent removal from service is evidenced by activities such as continuing low-level

maintenance to sustain the IUS in a recoverable status or until reutilization efforts are exhausted.

For example, IUS taken out of service on a temporary basis is considered other than permanently

removed from service. In such cases, the recorded cost of the IUS will remain in the Internal Use

Software account (USSGL 183000). There is no change in the reported value for IUS that have

been other than permanently removed from service and the IUS must continue to be amortized.

Amortization charges to expense for IUS will continue to be recorded in USSGL 183900.

2.9.3. If (1) an IUS’s use is terminated and (2) the DoD Component has documented its

decision to permanently remove the IUS from service, the removal from service must be accounted

for as permanent. Permanent removal from service is evident from the DoD Component’s

documented decision to dispose of an IUS by selling, recycling, or donating the IUS. The recorded

cost as well as the accumulated amortization of an IUS permanently removed from service must

be removed from the accounts in which they are reported, and the IUS must be recorded at its NRV

in a General Property, Plant and Equipment Permanently Removed But not Yet Disposed account

(USSGL 199500). USSGL account 199500 is defined in the DoD Standard Reporting

Chart of Accounts under the DoD Account Definitions tab as the NRV of General PP&E that is

permanently removed from service but not yet disposed and is reclassified in accordance with

FASAB TR 14, paragraphs 10 and 12. NRV is the estimated amount that can be recovered from

disposing of the asset less estimated costs of completion, holding, and disposal. Any difference

between the net book value of the asset and its expected NRV must be recognized as a gain or loss.

Any gain should be recorded in the Gains on Disposition of Assets – Other account

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-33

(USSGL 711000); any loss should be recorded in the Losses on Disposition of Assets – Other

account (USSGL 721000). The expected NRV should be evaluated at the end of each fiscal year

and any change in NRV should be recognized as a gain or loss. IUS permanently removed from

service is no longer amortized.

2.9.4. When an IUS is disposed of (e.g., by selling, recycling, donating, or destruction)

the IUS must be written off from the financial records and financial statements and the difference

between any disposal proceeds and the IUS’s net book value must be recognized as a gain or loss

as described in subparagraph 270209.C. In such case, if the DoD Component receives a

consideration (e.g., cash) for the disposal, a receipt of cash should be recorded in the Fund Balance

with Treasury account (USSGL 101000). If the funds (consideration received) are not apportioned

to the DoD Component, the fund must be transferred to miscellaneous receipts of the Treasury.

There will be no consideration received for a donation. The disposal start date is the calendar date

of a legally enforceable and recognizable obligation to complete the disposal action. For transfers

and sales, this represents the date on which the instrument is endorsed or operation is ceased,

whichever comes later. For natural disasters, this represents the actual date of the incident.

3.0 ADDITIONAL CONSIDERATIONS (2703)

*3.1 Use of Canceled Treasury Account Symbol (270301)

3.1.1. The Department of Treasury's Governmentwide Treasury Account Symbol

Adjusted Trial Balance System (GTAS) is a data collection system that replaces the reporting

functionalities of Federal Agencies Centralized Trial-Balance System I and II, Intragovernmental

Fiduciary Confirmation System and Intragovernmental Reporting and Analysis System as the

primary means for DoD Components to report their trial balance data to the Department of

Treasury. Capitalized assets are required to be reported and remain in GTAS after the original

purchasing Treasury Account Symbol (TAS) has expired and been canceled. If a capitalized asset

has not been moved to a “C” TAS as described in 270301.B. GTAS will provide a “C” TAS on

the GTAS Super Master Account File (SMAF) for each fund family represented on the SMAF.

The system generated “C” TAS will have three components: the three-digit agency identifier,

availability type "C", and a four-digit main account.

3.1.2. All DoD Components must use the “C” availability type TAS to report capitalized

assets. Assets may be moved to a C TAS at any time from the purchase date to the date the original

purchasing fund cancels. (Refer to the TFM, Part 2, Chapter 4700 for additional information.)

3.1.3. To transfer an asset to a C TAS:

3.1.3.1. Use USSGL account transaction E510 to transfer-out the asset from the

purchasing fund account.

3.1.3.2. Use USSGL account transaction E606 to transfer-in the asset into the

appropriate C TAS.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-34

3.2 Supporting Documentation (270302)

Entries to record financial transactions in accounting system general ledger accounts

and/or the supporting subsidiary accountable property records and/or systems must:

3.2.1. Be supported by source documents that reflect all transactions affecting the

DoD Component’s investment in the IUS.

3.2.1.1. All acquisitions, whether by purchase, transfer from other agencies,

donation, or other means, must be supported as of the date the DoD Component takes custody of

the IUS. The documents listed in Table 27-6, where applicable, must be readily available to

support the changes in asset value or physical attributes as a result of new acquisition or capital

enhancement.

Table 27-6. Supporting Documentation for IUS Acquisition

Evidence

Examples

Unique Identification

Assignment of unique identifier

Project Approval

Such as, but not limited to, a Work Order

Obligation on Behalf of

the Government

Such as, but not limited to:

1. For contracts, contract modifications, or change orders:

• Statement of Work;

• Dollar Amount of Contract;

• Location;

• Source of Funds;

• Parties to the Contract; and

• Signature Page [Signature of All Parties].

2. Documentation of labor hours;

3. Approved Work Order.

Payment Submitted

Such as, but not limited to:

Approved last invoice reflecting the total amount submitted for

payment and received to date;

2. Evidence of in-house development costs, including labor;

Indirect Costs incurred internally by the gaining activity that relate

to the new acquisition or capital enhancement.

Acceptance

Such as, but not limited to:

1. DoD (DD) Form 250, Material Inspection and Receiving Report;

2. Executed acquisition document and appraisal results for the donated

IUS;

3. Signed agreement for software licenses;

A signoff document confirming key development milestones such

as technical acceptance tests are met;

5. Documents to support the amount that has been expensed versus

capitalized during the software development phase.

6. Executed reversionary document; and

7. Transfer letter and documents for transferred assets.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-35

3.2.1.2. All disposals or retirements must be supported as of the date the IUS

leaves the custody of the DoD Component to provide an adequate audit trail for the disposal of an

asset. The execution of certain disposal events will generate financial or administrative

accountability transactions. These documents, where applicable, must be readily available to

support disposals:

3.2.1.2.1. ‘Declaration of excess’ document;

3.2.1.2.2. Approval documentation for the disposal;

3.2.1.2.3. Original acquisition documents;

3.2.1.2.4. Legal instruments (such as a license agreement or contract) to

indicate legal obligation to dispose of an asset;

3.2.1.2.5. Document showing the disposal start date;

3.2.1.2.6. Receipt documentation; and

3.2.1.2.7. Transfer documents for transferred assets or as otherwise

stated.

3.2.1.3. Documents that support the recorded cost of IUS assets must be retained

by the DoD Component in accordance with the requirements contained in Volume 1, Chapter 9 or

as otherwise stated. Documentation (original documents and/or hard and electronic copies of

original documentation) must be maintained in a readily available location during the applicable

retention period to permit the validation of information pertaining to the asset such as the purchase

cost, purchase date, and cost of enhancements. The documentation must also be linked to the

appropriate unique identifier(s). Supporting documentation may include, but is not limited to, the

documentation as outlined in this subparagraph. DoD Component asset managers will maintain

all applicable documentation for the retention period outlined in Volume 1, Chapter 9.

3.2.2. Include sufficient information indicating the quantity (as applicable would include

the number of seats for which the IUS asset is loaded; the number of licenses; and/or the number

of copies of a computer disk purchased), location and unit cost (as measured consistently with the

criteria for quantification) of the IUS. The accountable property records must be designed to be

of maximum assistance in making procurement and utilization decisions, including decisions

related to identifying potential excess IUS that may be available for reuse, transfer to other

DoD Components, or made available for disposal in accordance with current DoD regulations and

other regulatory requirements.

3.2.3. Identify and classify IUS that was capitalized, recorded in the APSR and

accounting system, and reported in the financial statements.

3.2.4. Be based on the same documents, to ensure that entries to the accounting and

accountable property records are the same. This will ensure that the property accountability

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-36

records are integrated and subsidiary to the accounting system and those records can be reconciled

with the accounting system.

3.2.5. Include documents used to accumulate the cost of developmental projects. Each

document must link to the appropriate asset unique identifier. For a listing of those costs that may

be incurred during the development, see Table 27-1.

3.2.6. Include all IUS possessed by the Department (to include property held by others)

and IUS of others held by DoD through seizure, forfeiture, loss, or abandonment.

3.2.7. Provide information to identify and account for licenses, regardless of whether the

license meets the capital lease criteria or whether the value of the licenses exceeds DoD

capitalization thresholds.

3.2.8. Provide information to identify and account for capitalized enhancements to IUS.

*3.3 Reporting Requirements (270303)

DoD Components with IUS should reference a note on the Balance Sheet that discloses

information about the reported IUS assets. See Volume 6B, Chapter 10 for the specific reporting

requirements.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27

* August 2018

27-37

*Figure 27-2. Capitalization Decision Tree for IUS Purchased from Commercial Off-the-Shelf

Vendors; IUS Internally Developed by DoD and IUS Developed by a Third Party on Behalf of

DoD

Is the software an

application?

Is software purchased,

internally developed or

licensed?

Does the

license meet

capital lease

criteria?

Is the software

intended for internal

use?

Start

Does the software have a

useful life of 2 or

more years?

Evaluate the accounting

treatment based on the

intended purpose of the

software (i.e., not

internal use)

Expense license

amount

Capitalize license

amount + any

modifications

Does the historical

cost of the software + any

modifications exceed

the cap threshold?

Capitalize cost of

software + any

modifications

Yes

Purchase or

internally

developed

License

Add to

equipment cost

or expense based

on SFFAS 6

Expense

Yes

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27, Annex 1

* Date

A1-1

*Annex 1. Definitions and Examples

The following table contains common terms as they are generally defined by information

technology and software programming professionals. It also includes scenarios relevant to IUS.

Definition

Classified as IUS?

Capitalization

DoD Examples*

Access Control Software

This type of software, which is

external to the operating system,

provides a means of specifying who

has access to a system and the

specific capabilities authorized users

are granted.

Include with

equipment costs

CA-ACF2,

RACF

Application Software

A software program that performs a

specific function directly for a user

and can be executed without access

to system control, monitoring, or

administrative privileges.

Yes

Yes - When

capitalization

criteria is met

Microsoft Excel,

Adobe

Photoshop

Cloud – Public

A cloud based environment that is

generally external to the Department

with infrastructure owned and

managed by a third party. Public

cloud services are generally

subscription based.

Dropbox

Cloud – Private

A cloud based environment that is

generally internal to the Department

and used solely by DoD

Components.

Yes

Yes – When the

capitalization

criteria is met,

the DoD

Component that

controls the IUS

has financial

reporting

responsibility

DISA milCloud

Database Management System (DBMS)

Computer software applications that

interact with the user, other

applications, and the database itself

to capture and analyze data.

Yes

Yes - When

capitalization

criteria is met

Oracle

Enterprise

Manager

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27, Annex 1

* Date

A1-2

Definition

Classified as IUS?

Capitalization

DoD Examples*

Enterprise Resource Planning System

Commercial software that integrates

business information flowing through

the Component. ERP systems contain

functional modules (e.g., financial,

accounting, human resources, supply

chain, and customer information) that

are integrated within the core system

interfaced to external systems.

Yes – portions of

ERP systems are

IUS (excluding

any hardware

acquired as part of

the system)

Yes – portions of

ERP systems are

capitalized

Navy ERP,

GFEBS, LMP,

DAI

Firmware

A program recorded in permanent or

semi-permanent computer memory.

No – may be

capitalized as part

of equipment

May be capitalized

a part of equipment

Radar system

software,

lathe

Freeware / Open Source Software (OSS)

Software that is offered at no cost.

Internet browser

Hardware

The physical components of IT,

including the computers, peripheral

devices such as printers, disks, and

scanners, and cables, switches, and

other IT equipment.

May be capitalized

as general

equipment

depending on

applicable

capitalization

criteria being met

Router,

Server,

Modem,

Switch

License – Annual

A software license that must be

renewed annually to continue using

the software.

Yes

No - an annual

license does not

meet the useful life

criteria of 2 years

for capitalization

Microsoft

Lync,

VMWARE

vSphere

License – Enterprise

A license that allows use of the

software throughout an organization

or for a specified number of users.

Yes

Only if it meets

capitalization

threshold and

capital lease

criteria

Microsoft

Office, Oracle

License – Perpetual

A software license that gives the

Department the right to use the

software in perpetuity.

Yes

Only if it meets

capitalization

threshold

SAP

Chrystal

Reports

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27, Annex 1

* Date

A1-3

*DoD examples provided may or may not be capitalized

Definition

Classified as IUS?

Capitalization

DoD Examples*

Middleware

Computer software that provides

services to software applications

beyond those available from the

operating system.

Yes

Yes - If the system

it is part of meets

capital criteria

Linux Kernel

Portal

Web-based application that provides

personalization, single sign-on, and

content aggregation from different

sources, and hosts the presentation

layer of information systems.

Yes

Yes – When

capitalization

criteria is met

Audit Response

Center (ARC)

Tool

Simulation Software

Based on the process of modeling a real

proposed system with a set of

mathematical

formulas that allows the

user

to observe an operation before

performing

it.

Yes

Yes – When

capitalization

criteria

is met

F-35 Lightning II

Training

Software

Operating System

The software that controls the

execution of other computer

programs, schedules tasks, allocates

storage, manages the interface to

peripheral hardware, and presents a

default interface to the user when no

application program is running.

Include in

equipment costs

Windows, Linux

System / IT System

The term “system” by itself is not

limited to any specific resource. A

system may be any two resources

that work together to produce a

specific outcome. Internal use

software may or may not be one

component of an overall “system”.

Yes – software

components of a

system or IT

system are IUS

Yes - When

capitalization

criteria is met

Navy ERP,

GFEBS, DAI,

CAMIS, MC4

Utility Program

System software designed to perform

a particular function or system

maintenance.

Include in

equipment costs

CD burner, Disk

defragmenter,

virus scan

Web Application

An application that is accessed via

the web over a network.

Yes (assuming it

is owned by a DoD

Component)

Yes - When

capitalization

criteria is met

Outlook

Webmail

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27, Annex 1

* Date

A2-2

*Annex 2. Alternative Valuation Methodology for Establishing Opening Balances for

Internal Use Software

1.0 Establishing Opening Balances for Internal Use Software (A20101)

1.1 The alternative valuation method for establishing opening balances for Internal Use

Software (IUS) described in Federal Accounting Standards Advisory Board (FASAB) Statement

of Federal Financial Accounting Standards (SFFAS) 50, “Establishing Opening Balances for

General Property, Plant and Equipment: Amending Statement of Federal Financial Accounting

Standards (SFFAS) 6, SFFAS 10, SFFAS 23, and Rescinding SFFAS 35” is available only once

to each reporting entity. Therefore, prior to the establishment of IUS opening balances,

DoD Components must validate that they are prepared to account for and comply with the

recognition, measurement, presentation and disclosure requirements for IUS in accordance with

FASAB SFFAS 10, “Accounting for Internal Use Software.”

1.2 DoD Components must identify any IUS that they have capitalized prior to establishing

opening balances, including capitalized development costs. All DoD Components that have not

previously undergone a financial statement audit where they received an unmodified (i.e., “clean”)

audit opinion will exclude the value of all IUS, including development costs, from opening

balances of General Property, Plant, and Equipment on their Balance Sheet. This means that

DoD Components who have not undergone a financial statement audit where they received a

“clean” audit opinion will adjust their capitalized IUS, including development costs, opening

balances to zero. A DoD Component that has received a “clean” audit opinion should continue to

account for IUS, including development costs, in accordance with FASAB SFFAS 10 and will not

reduce their balances to zero.

1.3 Entries in the DoD Component accounting systems/records to record IUS opening

balances at zero are subject to the reporting requirements under paragraph 13 of FASAB SFFAS

21, “Reporting Corrections of Errors and Changes in Accounting Principles, Amendment of

SFFAS 7, Accounting for Revenue and Other Financing Sources”. Accordingly, the entries will

be reflected as a change in accounting principle. Any adjustments must be properly documented

and supported to assist ongoing audit efforts.

2.0 Financial Statement Disclosure Requirements (A20102)

DoD Components who adjust their opening IUS balances, including development costs, in

accordance with subparagraphs A.20101.B and A.20101.C, must disclose in their financial

statements that an alternative valuation method was applied in establishing their opening balances.

This disclosure must describe the alternative valuation method 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 Generally Accepted Accounting

Principles. An unreserved assertion is an unconditional statement.

2BDoD 7000.14-R Financial Management Regulation Volume 4, Chapter 27, Annex 1

* Date

A2-2

3.0 Prospective Accounting for Internal Use Software (A20103)

3.1 Once the opening balances for IUS have been recorded at zero as described in paragraph

A.20101.B, the DoD Components shall capitalize IUS costs for IUS placed-in-service and IUS in

development in accordance with the provisions of FASAB SFFAS 10 for which guidance is

provided in Chapter 27. This capitalization requirement includes IUS development costs incurred

after the establishment of opening balances for projects started prior to the establishment of

opening balances. The DoD Components must have sufficient source documentation to support

the capitalized amounts of IUS based on actual historical cost. The DoD Components must apply

the provisions of FASAB SFFAS 10 regarding amortization and impairment to any unamortized

capitalized cost of the IUS.

3.2 The DoD Components should also fully implement the systems, internal controls,

processes and procedures to be compliant with accounting for IUS under FASAB SSFAS 10.

They must also periodically review and update the documentation of the systems, processes, and

procedures as needed.