Internal-Use Software (ASC 350-40)

Definition

Internal-use software is software a business acquires or develops for its own operations rather than to sell or licence. Under US GAAP, ASC 350-40 sets a stage-based model. Costs in the preliminary project stage — evaluating alternatives, selecting a vendor — are expensed. Costs in the application development stage, covering coding, configuration, installation and testing, are capitalised once management has authorised and committed funding to the project and it is probable the project will be completed and the software used as intended. Post-implementation costs, including training and most maintenance, are expensed, and later upgrades are capitalised only where it is probable they will result in additional functionality. Worked example: a business spends £500,000 developing an internal order-management system, of which £60,000 is evaluating options, £370,000 is building and testing, and £70,000 is training staff and running the system after go-live. Under ASC 350-40 the middle tranche is the capitalised population. Jurisdiction contrast: IFRS has no separate internal-use software standard, so the same project is assessed under IAS 38, with research-phase spend written off under IAS 38.54 and development-phase spend tested against the six conditions in IAS 38.57. The answers often converge, but the reasoning differs, and a group reporting under both frameworks should expect to document the bridge. The judgement management makes is where each stage began and ended.

Taking a defensible position

The position

ASC 350-40 divides an internal-use software project into three stages. Preliminary-project costs are expensed. Application-development costs are capitalised from the point management authorises and commits funding and completion is probable. Post-implementation costs, including training and most maintenance, are expensed, and later upgrades are capitalised only where additional functionality is probable. Under IFRS the same project is assessed under IAS 38.54 and IAS 38.57.

A defensible posture

A management team can support capitalisation from a dated, minuted funding decision and a project plan showing the application-development stage beginning at that point. The defensible version tracks internal time and supplier cost by stage as the work happens. Capitalising a whole project because it was ultimately delivered, and identifying the stages afterwards, is the version that tends to be reduced on review.

Evidence to hold

A dated management authorisation and funding commitment for the project.
Timesheets or engineering records attributing effort to development activity rather than to a cost centre.
Supplier contracts and invoices identifying the work performed and when it was performed.
A documented go-live date, so post-implementation costs are separable.
For upgrades, a specification describing the additional functionality expected.

The challenge you may face

Expect a reviewer to test the start and end dates. The most common findings are capitalisation beginning before the funding decision, training and data conversion sitting inside the capitalised total, and maintenance presented as enhancement. Groups reporting under both frameworks are also asked to reconcile the ASC 350-40 position with the IAS 38 assessment of the same project.

Complementary Terms

Concepts that frequently appear alongside Internal-Use Software (ASC 350-40) in practice.

ASC 350 (Intangibles — Goodwill and Other)

The US GAAP standard governing the subsequent measurement of goodwill and other intangible assets after initial recognition in a business combination. ASC 350 requires annual impairment testing of goodwill and indefinite-lived intangible assets, permits an optional qualitative assessment before performing the quantitative impairment test, and provides guidance on the amortisation of finite-lived intangible assets.

ASC 730

The US GAAP standard requiring immediate expensing of research and development costs as incurred. ASC 730 is the structural source of the gap between statutory and capitalisation-reclassified EBITDA for US-headquartered companies: virtually no R&D is permitted on the balance sheet, regardless of stage, evidence quality, or commercial proximity.

Development Costs (IAS 38)

Development costs are the expenditure incurred applying research findings to a plan or design for a new or substantially improved product, service, process or system before it enters commercial production or use. Under IAS 38 (IFRS — the default framework for UK groups reporting under adopted IFRS), the standard divides the work into two phases and treats them differently.

Software Capital

The value embedded in a company's proprietary software assets, including applications, platforms, tools, and codebases. Software capital is a major intangible asset category that drives automation, scalability, and competitive differentiation in technology-enabled businesses.

Cloud Configuration Costs

Cloud configuration costs are the amounts a business spends setting up software it accesses as a service rather than owns — configuring a platform to its own processes, customising it, migrating data into it, and training its people. The accounting question is whether that spend creates an intangible asset for the customer.