Software Cost Accounting

What Software Development Costs Can Be Capitalized?

What software development costs can be capitalized depends first on the accounting framework, the purpose of the software, and the point at which the project moves from investigation to a sufficiently committed and probable development effort. In practical terms, businesses usually capitalize directly attributable costs that create or prepare a qualifying software asset for use, while expensing research, preliminary evaluation, training, routine maintenance, support, and general administrative work.

The central mistake is to treat an entire project budget as either capital or expense. A software programme normally contains both. Product discovery, technical feasibility work, coding, configuration, testing, data migration, employee training, post-launch support, and upgrades may occur in the same sprint or vendor invoice, but they do not necessarily receive the same accounting treatment.

This guide separates the decision by software type, project activity, and reporting framework. It covers internal-use software, software developed for sale, cloud and SaaS implementation, agile delivery, payroll and contractor costs, testing, upgrades, amortization, impairment, documentation, and the important distinction between financial reporting and tax treatment.

Quick Answer: Which Software Costs Qualify?

Capitalize software development costs only when the applicable recognition threshold has been met and the spending is directly attributable to creating, configuring, testing, or preparing the software for its intended use. Common candidates include qualifying developer payroll, contractor coding fees, directly related testing, and certain implementation costs incurred during the development phase.

Expense preliminary research, alternative evaluation, proof-of-concept work before feasibility is established, training, routine maintenance, customer support, data cleansing, general overhead, and costs of abandoned functionality. Cloud arrangements need a separate contract analysis because the customer may be buying access to a service rather than controlling a software asset.

Before posting entries, classify the project as internal-use, software to be sold or marketed, or a cloud-service implementation; identify the relevant US GAAP or IFRS guidance; establish the capitalization start and stop dates; and document how payroll, vendor invoices, and mixed activities are allocated.

Key Takeaways

• Purpose changes the rule: internal-use software, software sold to customers, and SaaS implementation costs follow different accounting models.
• Timing matters: qualifying costs are capitalized only after the relevant recognition threshold is met and before the software is ready for use.
• Activity matters more than job title: a developer's coding time may qualify, while the same person's research, support, or maintenance time may not.
• Mixed invoices require allocation: vendor contracts and agile sprints often contain both capitalizable and expensed work.
• Cloud projects need control analysis: configuration does not automatically create an intangible software asset for the customer.
• Book and tax rules are separate: financial-reporting treatment does not determine the tax deduction or amortization period.
• Evidence is essential: authorization, feasibility, time records, ticket classifications, testing, and placed-in-service approval support the accounting conclusion.

Table of Contents

1. Start with the software accounting framework
2. Capitalizable and expensed cost categories
3. Internal-use software under US GAAP
4. Software developed for sale
5. Development costs under IFRS
6. Cloud and SaaS implementation costs
7. Agile teams, payroll, and contractors
8. Practical capitalization examples
9. Documentation, amortization, and controls
10. Summary

Start with the Software Accounting Framework

The first decision is not whether a cost “sounds technical.” It is which accounting model applies. The same coding activity can be treated differently depending on whether the software is built for the entity's own operations, licensed or sold to customers, or delivered through a hosting arrangement.

Under IFRS, IAS 38 on intangible assets separates research expenditure, which is expensed, from development expenditure that meets recognition criteria. For internally generated websites, SIC-32 on website costs clarifies that a website may qualify as an internally generated intangible asset, but a site developed mainly for advertising is expensed.

Which Costs Are Capitalizable or Expensed?

Use the following table as a classification starting point, not as a substitute for reviewing the governing standard and the facts of the project.

A practical policy should define examples for the company's delivery method. “Development” is too broad; coding a new payments module, researching an unproven AI approach, and correcting a production incident are different accounting activities even when performed by the same team.

Internal-Use Software Under US GAAP

For entities applying US GAAP, internal-use software is generally addressed by ASC 350-40. Under the traditional project-stage model, preliminary-project activities are expensed, qualifying application-development costs are capitalized, and training and post-implementation operation are expensed. Capitalization stops when the software is substantially complete and ready for intended use.

FASB issued ASU 2025-06 on internal-use software, effective for annual periods beginning after 15 December 2027, with early adoption permitted. The amendments remove references to project stages and require capitalization when management has authorized and committed funding and it is probable the project will be completed and used as intended. Entities must also consider significant uncertainty in the development activities.

Software Developed for Sale or Licensing

Software that will be sold, leased, or otherwise marketed to customers is not automatically accounted for like internal-use software. Under US GAAP, research and development costs are generally expensed until technological feasibility is established. Qualifying production costs incurred after technological feasibility and before the product is available for general release are capitalized.

This creates a narrower capitalization window than many product teams expect. Market research, product discovery, prototypes, and unresolved technical experimentation often occur before technological feasibility. Once the product is available for general release, customer support, maintenance, and routine updates are generally operating expenses, while significant new versions or functionality require a fresh assessment.

Product leaders should align accounting milestones with evidence the engineering process already creates: approved specifications, resolved high-risk technical uncertainties, release criteria, source-control records, test results, and general-availability approval.

IFRS Requires a Research-to-Development Assessment

IAS 38 requires research expenditure to be expensed. Development expenditure is capitalized only when the entity can demonstrate the required criteria, including technical feasibility, intention and ability to complete and use or sell the asset, probable future economic benefits, adequate resources, and reliable measurement of attributable expenditure.

The threshold is therefore evidence-based. A management desire to build a product is not enough. The company needs a supportable route to completion, use, or sale; adequate technical and financial resources; and reliable cost measurement. Capitalization begins when all criteria are met, not from the first day of the programme, and previously expensed research costs are not reinstated merely because the project later succeeds.

For websites, SIC-32 adds an important distinction: costs may qualify when the site can generate probable future economic benefits, but expenditure on a website developed solely or primarily to promote and advertise the entity's own products or services is expensed.

Cloud and SaaS Costs Need Contract Analysis

Cloud projects are frequently misclassified because “implementation” may describe many different items. First determine whether the contract conveys control of a software asset or only a right to access the supplier's hosted application. Then assess configuration, customization, integration, interfaces, data migration, training, and support separately.

The IFRS Interpretations Committee's cloud configuration and customization decision explains that when a SaaS arrangement is a service, an intangible asset is recognized only if the configuration or customization itself creates a resource controlled by the customer. Otherwise, the customer considers whether it receives a distinct service and when that service is recognized.

For US GAAP, hosting arrangements and implementation costs also require specific analysis. Avoid capitalizing every implementation invoice under a generic “software asset” account. The accounting memo should identify the hosting conclusion, each service, who performs it, whether it is distinct, and the period over which any deferred implementation asset is recognized.

Agile Teams Need Activity-Based Evidence

Agile delivery does not prevent capitalization, but sprint boundaries do not replace accounting analysis. A sprint can contain discovery, technical spikes, design, coding, testing, defect remediation, deployment, training, and support. The entity needs a repeatable way to distinguish activities.

Payroll and employee time

Capitalize payroll and related costs only for documented time spent on qualifying activities. Suitable evidence may include time records, ticket types, cost-centre coding, approved allocations, and periodic manager review. Broad percentages based on job title are weak when engineers divide time among new development, maintenance, customer incidents, and internal administration.

Contractors and vendor invoices

Contracts should separate discovery, build, testing, migration, training, hosting, and support. When a fixed-fee milestone combines several activities, use a reasonable allocation supported by statements of work, deliverables, hours, or other evidence. Do not capitalize nonqualifying components merely because the vendor describes the invoice as “implementation.”

Upgrades and bug fixes

Routine bug fixes and maintenance are generally expensed. A major enhancement may be capitalized when it adds significant new functionality or future economic benefits and meets the relevant recognition criteria. Teams should distinguish corrective tickets from new capability and document when a release is ready for use.

Three Practical Capitalization Examples

Startup building its first commercial platform

A startup spends three months validating demand and testing several architectures, then approves a funded plan after resolving the principal technical uncertainty. The initial research and discarded prototypes are expensed. Under an applicable development-capitalization model, directly attributable coding and testing after the threshold may be capitalized. The finance team should not backdate capitalization to the earliest prototype.

Enterprise replacing an internal workflow system

An enterprise evaluates vendors, maps processes, and selects a platform. Evaluation and process-study costs are expensed. Qualifying configuration, interface development, and pre-launch testing may be capitalized, while employee training, data cleansing, and post-launch support are expensed. Vendor invoices are split using contract deliverables rather than capitalized in full.

Ecommerce business adding a major mobile feature

An ecommerce business adds a materially new fulfilment and loyalty capability to an existing application. Routine defect correction remains expense. The new module's directly attributable development and pre-use testing may qualify as an enhancement asset if recognition criteria are met. Management documents the new functionality, approval date, placed-in-service date, useful life, and any retirement of replaced components.

Documentation, Amortization, and Control

Capitalization is sustainable only when the records explain why the asset exists, when capitalization began, which costs were included, and when amortization started. The minimum evidence should include:

• project charter, purpose, ownership, budget, and management authorization;
• evidence of feasibility, probability of completion, resources, and intended use or sale;
• capitalization start and stop dates linked to project milestones;
• employee time records, ticket classifications, vendor contracts, invoices, and allocation methods;
• testing and acceptance evidence, release approval, and ready-for-use date;
• useful-life rationale, amortization method, impairment review, and abandonment procedures; and
• reconciliation of the project ledger to the general ledger and fixed-asset register.

Amortization normally begins when the software is ready for its intended use, not when users achieve full adoption. The useful life should reflect expected technological change, product cycles, contractual limits, maintenance strategy, and replacement plans. Review impairment indicators when projects are paused, functionality is abandoned, performance is below expectations, or a replacement decision is made.

Financial-reporting and tax records must also be reconciled separately. The IRS guidance on domestic research expenditures after 2024 reflects recent US tax changes, including treatment of domestic and foreign software-development research. Tax treatment depends on the tax year, jurisdiction, elections, and whether spending meets the relevant tax definition; it should not be inferred from the book capitalization entry.

Need a Clearer Development Cost Trail?

Accounting conclusions are stronger when software requirements, work breakdowns, time records, testing, and release approvals are structured from the start. Rudrriv can support technical discovery, defined software-development projects, quality assurance, and ongoing development capacity through development services or dedicated specialist support. Your accounting advisers should make the final financial-reporting and tax determinations.

Summary

Software costs are capitalized when they meet the applicable asset-recognition threshold and are directly attributable to creating or preparing qualifying software for use or sale. Coding, configuration, integration, and pre-use testing may qualify; research, preliminary evaluation, training, routine maintenance, support, data cleansing, and general overhead are commonly expensed.

The correct decision depends on whether the software is for internal use, marketed to customers, or accessed through a cloud service, and whether the entity applies US GAAP or IFRS. Establish the capitalization dates, classify mixed activities, document payroll and vendor allocations, and begin amortization when the asset is ready for intended use.

Before closing the period, reconcile book and tax treatment, review impairment or abandonment indicators, and confirm that the project file supports authorization, feasibility, completion probability, useful life, ownership, quality assurance, and handover.

FAQs on Software Development Cost Capitalization

What software development costs can be capitalized?

Costs may be capitalized when the applicable accounting framework treats them as directly attributable to creating, configuring, testing, or preparing a software asset for its intended use, and the recognition threshold has been met. Typical candidates include qualifying developer payroll, third-party coding fees, directly related testing, and certain implementation costs. Research, preliminary evaluation, training, routine maintenance, data conversion, and general overhead are commonly expensed. The exact answer depends on whether the software is for internal use, for sale, or accessed through a cloud arrangement, and on whether the entity reports under US GAAP or IFRS.

When does capitalization begin for internal-use software under US GAAP?

Under current US GAAP, capitalization generally begins after the preliminary project stage is complete, management authorizes and commits to funding, and completion and use are probable. FASB ASU 2025-06 changes the model for periods beginning after December 15, 2027, unless adopted early: entities capitalize when management has authorized and committed funding and it is probable the project will be completed and used as intended. Companies should document which guidance and adoption date they apply.

Are software developer salaries capitalized?

Developer salaries and related payroll costs can be capitalized to the extent employees spend time on qualifying development activities after the recognition threshold is met. Time spent on research, vendor selection, training, maintenance, support, or abandoned work is usually expensed. A reliable time-tracking method and documented allocation policy are essential; capitalizing a broad percentage without evidence creates audit risk.

Can agile sprint costs be capitalized?

Yes, but not automatically. Agile work must be assessed by the nature of the activity, not merely by sprint labels. Coding and testing that create or materially enhance qualifying functionality may be capitalizable, while discovery, backlog grooming, research spikes, defect correction after implementation, training, and routine maintenance may be expensed. Teams should map ticket types and time records to the accounting policy.

Are cloud implementation and SaaS configuration costs capitalized?

Sometimes. If the arrangement includes a software asset controlled by the customer, qualifying implementation costs may be capitalized with that asset. If the SaaS arrangement is a service and no software asset is controlled, treatment depends on who performs the work and whether the service is distinct; some costs are expensed as received, while certain advance payments may be recognized over the service period. Contract terms and deliverables must be reviewed carefully.

Are testing and quality-assurance costs capitalized?

Testing costs can be capitalized when they are directly attributable to preparing qualifying software for its intended use before implementation. User acceptance testing, integration testing, and directly related defect remediation may qualify. Testing performed after the software is ready for use, ongoing monitoring, support testing, and routine regression testing for maintenance releases are generally expensed.

Are data conversion and training costs capitalized?

Training is generally expensed because it prepares employees, not the software asset. Data conversion is also commonly expensed, especially data cleansing, reconciliation, migration, and validation. Limited costs of developing or obtaining software that enables data conversion may qualify if they create a separate or integral software asset, but the underlying conversion labour usually does not.

How are capitalized software costs amortized?

Capitalized software costs are normally amortized over the asset's estimated useful life once the software is ready for its intended use. The method should reflect how economic benefits are consumed; straight-line amortization is common when that pattern cannot be reliably determined. Useful lives, residual values, impairment indicators, major upgrades, and abandonment decisions should be reassessed under the applicable framework.

What is the difference between book and tax treatment?

Financial-reporting capitalization and tax capitalization are separate analyses. In the United States, current tax rules for software development and research expenditures changed for tax years beginning after December 31, 2024, including new treatment for domestic and foreign research. A cost may be capitalized for books but deducted for tax, or the reverse, creating deferred-tax effects. Tax advice should be based on the entity's jurisdiction and filing year.

What documentation supports software-cost capitalization?

Maintain an approved project charter, funding authorization, evidence that completion and use are probable, project dates, architecture and functionality decisions, vendor contracts, invoices, payroll allocations, time records, ticket classifications, testing evidence, placed-in-service approval, useful-life support, and a reconciliation from project ledgers to the general ledger. The policy should also explain treatment of upgrades, maintenance, cloud arrangements, abandoned projects, and impairment.

Plan Software Work with Better Cost Visibility

Define the product scope, development activities, testing responsibilities, ownership, release criteria, maintenance model, and reporting structure before work begins. Clear delivery records make it easier for finance teams and advisers to assess costs consistently.

Explore development support

At Rudrriv, we make it easier for businesses to access the right expertise, execute important work, and scale with confidence.