Software Development Cost Capitalization

When a company develops software for internal use or for sale, software development cost capitalization applies a three-stage test to decide whether costs build an asset or vanish as expense. Under IAS 38 and similar GAAP rules, only costs incurred in the application development phase after feasibility is proven qualify for capitalization as intangible-assets.

The three-stage framework

Preliminary stage covers concept evaluation, feasibility studies, and determination of technical and economic viability. These costs are nearly always expensed. Preliminary work includes vendor selection, requirements gathering, and prototyping. Even if prototyping proves the concept sound, the costs are not capitalized—they are research in nature and have not yet led to a binding commitment to develop. Most companies expense preliminary costs entirely; attempting to capitalize them creates audit friction and is rarely worth the documentation burden.

Application development stage begins once the company has approved the project and committed resources. At this point, the software is probable and technically feasible. Costs incurred during active coding, testing, and integration of the developed software qualify for capitalization. This includes direct labour (developer wages), purchased components integrated into the software, and directly attributable overhead (a portion of systems administration supporting the project). Capitalization continues through the point the software is ready for use—either internal deployment or commercial release.

Post-implementation stage includes data migration, user training, and maintenance after the software is live. These costs are expensed. Maintenance updates and minor bug fixes are always expensed; they do not enhance the asset or extend its useful life materially. Major enhancements that add new functionality or extend the asset’s useful life may be capitalized as a separate project, but the bar is high and must be documented clearly.

The feasibility threshold

The crux of the three-stage model is feasibility. Feasibility is not a confidence in success; it is a technical and economic assessment that the company can and will complete the project, and that the software is probable to generate future economic benefit. For internally developed software, benefit flows from cost reduction or improved efficiency. For software sold commercially, benefit flows from revenue. The assessment must be documented—a memo from the CIO, a business case, or board approval all serve as evidence.

Once feasibility is established, the clock starts on capitalization. If the project stalls or is abandoned before completion, capitalized costs may need to be written off. If the software is modified or re-purposed after deployment in a way that extends its useful life or expands its functionality, the cost of that modification may be capitalized as a separate intangible asset, but this is uncommon and must meet the same feasibility test.

Amortization and impairment

Capitalized software is recorded as an intangible asset and amortized over its estimated useful life. For most business software, that is 3 to 5 years; for platforms or frameworks with longer relevance, 7 to 10 years. The amortization schedule is straight-line unless circumstances suggest otherwise. At each reporting date, the company assesses whether the asset is impaired—whether future economic benefit has been reduced below the carrying amount. Obsolescence, abandonment, or regulatory changes can trigger impairment, and the asset is written down to fair-value.

Under IFRS, capitalized development costs are not revalued; they remain at cost less accumulated amortization. Under US GAAP, similar rules apply, though guidance is less prescriptive, and auditors often apply stricter capitalization thresholds to reduce risk. Some companies choose not to capitalize software costs at all, instead expensing them immediately; this is not prohibited, but it creates more conservative reported earnings.

The cloud and SaaS complication

Cloud software and Software-as-a-Service (SaaS) arrangements complicate capitalization. A company paying an annual subscription to Salesforce, HubSpot, or another vendor is leasing a service, not acquiring an asset, and costs are expensed as incurred. However, if a company pays for customization, data migration, or integration of a SaaS platform to its unique processes, some of those costs may be capitalized under the three-stage model—but only if they result in a separately identifiable asset or right of use. This is increasingly common and increasingly disputed; the FASB and IASB continue to refine guidance in this area.

Why auditors care

Software capitalization is one of the most audited cost classifications. Auditors are trained to be skeptical: preliminary costs masquerading as development, maintenance wrongly capitalized as enhancement, or a failed project’s costs lingering on the balance sheet rather than being written off. A company overstate software assets by even 10% can materially misstate earnings over multiple years if the asset is amortized slowly. Audit time and management negotiation around software capitalization is often disproportionate to the dollar amount, because the stakes are high for both credibility and tax treatment.

See also