Rescinded [2017-04-01] - Accounting Standard 3.1.1 - Treasury Board - Software

This Accounting Standard is an extension of the Treasury Board Accounting Standard (TBAS) 3.1 on Capital Assets and provides clarification on the treatment of software.
Date modified: 2001-04-01

This page has been archived on the Web

Information identified as archived is provided for reference, research or recordkeeping purposes. It is not subject to the Government of Canada Web Standards and has not been altered or updated since it was archived. Please contact us to request a format other than those available.

More information




This standard is replaced by:

View all inactive instruments
Print-friendly XML

Note to reader

This section should be read in conjunction with TBAS 3.1 "Capital Assets" and PSA Handbook Section 3150 and CICA Sections 3060.


1. This Accounting Standard is an extension of the Treasury Board Accounting Standard (TBAS) 3.1 on Capital Assets and provides clarification on the treatment of software.


2. There are three basic stages to an information technology project:

  1. Preliminary project stage.

    Activities include the determination of existence of needed technology, conceptual formulation of alternatives, and evaluation and selection of alternatives. All internal and external costs will be expensed.

  2. Application development and implementation.

    Activities include design of software configuration, coding, installation to hardware and testing, training specific to implementation, etc.

    Direct internal and external costs will be capitalized. Direct costs of materials and services consumed in obtaining or developing internal-use computer software include: fees paid to third parties for services provided to develop the software during the application development stage; costs incurred to obtain computer software from third parties; and travel expenses incurred by individuals in their duties directly associated with developing software. Payroll and payroll related costs (for example, costs of employee benefits) for employees who are directly associated with the project will be capitalized to the extent of the time spent directly on the project. Direct overhead costs incurred during the development activity will also be capitalized. Examples of direct overhead costs include the cost of additional leased space required to accommodate staff dedicated to a project and the expenses associated with this leased space.

  3. Post-implementation/operations.

    Activities include internal training (e.g. end-user training) and ongoing support and maintenance costs. All internal and external costs will be expensed

3. Departments must have a suitably rigorous process for identifying costs to be capitalized that can withstand audit (i.e. time records, review and approval of costs charged by management of the project, etc.).

4. Where software is included in the purchase price of hardware (e.g. operating system software) and the cost of the software cannot be reliably calculated, the software should be capitalized and amortized as part of hardware. Guidance on accounting for information technology systems (i.e. hardware and software) as one asset versus accounting for these as individual components is found in TBAS 3.1.

5. If the department pays a one-off licensing fee in order to use the software, the department can be said to have acquired service potential or future economic benefits relating to that software, so the cost of the license fee should be capitalized as part of the software. Any licensing fee that is not a one-off (e.g. a yearly licensing fee which typically covers maintenance and upgrades automatically provided by the vendor) indicates that any service potential or future economic benefits obtained will normally expire when the next payment is due and should therefore be expensed.

6. Data is the information input into, manipulated or otherwise treated by and output by hardware and software. Data will not be considered a capital asset. Costs associated with data conversion should be expensed.

New versions, upgrades and enhancements

7. Upgrades and enhancements are defined as modifications to enable the software to perform tasks that it was previously incapable of performing (i.e. new functionality). Upgrades and enhancements normally require new software specifications and may require a change to all or part of the existing software specifications. These costs are considered betterments and will be capitalized if they increase the functionality or service potential of the software. Examples include when the modifications result in an increase to the previously assessed service capacity, lower the associated operating costs, extend the useful life, or improve the quality of output.

8. The cost incurred in the maintenance of the service potential of a capital asset is a repair and will be expensed. Examples of maintenance include coding changes required for the software to remain current to meet user needs (such as to meet changes in legislative requirements), or changes required for systems to remain compatible. The department must use professional judgement to assess whether an upgrade or enhancement needs to be capitalized or expensed. Where a cost can not easily be differentiated between a repair and betterment, the cost will be expensed respecting the accounting principle of conservatism.

9. New versions of software may be accounted for as an expense or capitalized depending on nature of the release. The cost of implementing and/or installing new versions of software which contain primarily "bug fixes" (i.e., do not deliver new functionality, merely correct errors in previously promised functionality) will be expensed.

10. The nature of new versions of software should be reviewed in determining the appropriate accounting treatment. If a new version replaces the functionality of the old version, then the latter should be expensed and the new version amortized over its anticipated useful life. If the new version simply adds to the functionality of the old version (e.g. adds additional modules), then the old version and the new version would be amortized over the original useful life or revised useful life if significantly different.


11. When a department incurs any costs for computer software, but it is not probable that any service potential or future economic benefits from this software will occur at the time of financial statement preparation, the Department must not recognize an asset in the financial statements. In the case of software under development, if development of the product ceases and a product is not anticipated, the costs capitalized to date shall be immediately expensed.

12. Assets must be expensed if they are not expected to provide any future service potential. Any computer software that, after use or testing, fails to deliver the expected future economic benefits or service potential should be expensed. This is more likely to occur with in-house developed software than purchased software as the suitability of the latter is assessed prior to its acquisition.


13. Departments should cease capitalization of costs and start amortization when the software project is substantially completed and in use.

14. Software should be amortized on a straight-line basis unless another method can be demonstrated to be more appropriate. Table 1 provides indicative useful lives for different types of software that departments may consider for amortization.

15. Amortization shall be recorded monthly commencing on the first day of the month following the month that the software is put into use.

Table 1: Indicative Useful Life by Type of Software



Life span


Replaced by new version, unmodifiable. User unable to request changes

1-3 years

Infrastructure (operating system, middleware)

Vendor provides upgrades, usually annually. Transparent to end-users.

3-7 years


Modifiable by vendor only, upgrades/fixes annually, enhancements via user group.

3-7 years

Tailored to order

Developed for one customer only, customer-driven requirements formally requested.

5-10 years


Developed internally. Likely to be continually maintained and enhanced.

5-10 years


16. Disclosure of the prospective application of this policy would be made in the significant accounting policies note to the financial statements. Suggested note disclosure is as follows:

"The capitalization of software costs has been performed prospectively as of April 1, 2001. Any costs incurred prior to this date have been expensed."

Effective date

17. The application of this Treasury Board Accounting Standard is to be performed prospectively as of April 1, 2001. Departments and agencies are not to include an opening balance for software on their 2001/2002 CFMRS trial balances. Where software is under development as at April 1, 2001, only those costs incurred after March 31, 2001, should be capitalized.

Date modified: