Software development costs: maximizing ROI

Assembling a software development team and initiating a new digital project represents not only operational milestones, but also significant strategic investments. 

For CFOs and Directors, deciding how research and development costs related to new software projects should be reflected in the financial statements is a key aspect of financial stewardship.

Under AASB 138 Intangible Assets (AASB 138), the treatment of software development costs directly shapes how an organisation communicates its investment priorities, financial resilience, and future growth potential. In an environment of heightened transparency expectations from boards, investors, and regulators, CFOs must balance compliance with the strategic storytelling that financial reporting enables.

Software development costs vary widely across projects and industries.  This means finance leaders need a pragmatic, commercially grounded framework to determine when expenditure represents a long term asset or an immediate expense. Applying this framework consistently ensures governance bodies can rely on the financial statements as an accurate reflection of the organisation’s innovation strategy and capital allocation decisions.

So, how can CFOs ensure compliance while strategically addressing these challenges?

Background & context

Software development projects typically consist of two key phases: (i) research; and (ii) development. Research focuses on exploring new concepts, technologies, or methodologies, while development involves the application of these findings to create software that will generate future economic benefits. AASB 138 provides CFOs and Directors with the framework needed to make informed, defensible decisions on when software investment should be expensed versus recognised as a long‑term asset.

Key Accounting Requirements

AASB 138 provides the framework for recognising, measuring, and presenting intangible assets in financial statements. Clear and consistent application of these requirements strengthens the organisation’s financial narrative and supports governance oversight.

Research Phase Costs

• Costs incurred during the early project stages, like planning and research, must be expensed as incurred under AASB 138. These costs may include:
• Investigating potential alternatives for software functionality;
• Undertaking feasibility studies;
• Conducting preliminary market research; and
• Exploring new technologies or platforms.

The rationale behind expensing research costs is that their future economic benefits are uncertain at this stage. Recognising these costs in the income statement ensures transparency and avoids overstating assets.

For CFOs, recognising research costs immediately also provides earlier visibility into the true cost of innovation and avoids inflating asset values prematurely.

Development Phase Costs

As the project moves into the development phase, the decision whether to expense or capitalise costs becomes more complex.  Generally, in order for the development phase to commence, if the entity has identified a specific project that it wishes to undertake, and commences with building it.

Reaching the development phase does not automatically mean that costs can now be capitalised.  Costs incurred during the development phase may be capitalised if they meet the recognition criteria outlined in AASB 138. These costs may include:

• Design, coding, and testing of the software;
• Direct labour costs for development activities;
• Costs of tools and infrastructure specifically utilised for development; and
• Technical testing and deployment preparation.

Finance leaders play a critical role in determining when a project has progressed sufficiently to meet capitalisation criteria and when investment should be treated as operational expenditure.

Capitalisation Criteria

For CFOs and TCWG, the distinction between expensing and capitalising development costs is more than a technical accounting question - it directly influences perceptions of investment strategy, asset growth, and long‑term value creation. An expense is a cost that you pay for immediate use in this period. On the other hand, an intangible asset, like software developed for internal use, brings future economic benefits. This means it is likely to help make money or save costs for over a year.

When software development costs are expense, they are taken to the profit or loss statement. This lowers the profit in the current period. When these costs are capitalised, they are recorded as an asset on the balance sheet. With the asset then being reduced over the estimated useful life of the software through amortisation or depreciation.

The decision between these two methods has a major effect on a company's financial reports. This also influences how people view the company's financial health and performance.

Deciding whether to expense or capitalise software development costs requires an understanding of the recognition criteria set by accounting standards. These rules depend on things like the purpose of the software, what stage it is in, and how it can generate future economic benefits.

To qualify for capitalisation, development costs must meet the following conditions:

• Technical Feasibility: The entity must demonstrate the technical feasibility of completing the software so it will be available for use.
• Intention to Complete: There must be a clear intention to complete the development and to use or sell the software once finished.
• Ability to Use or Sell the Asset: The entity must be able to use the software internally or sell it externally, confirming that the completed asset will be operational and capable of delivering benefits.
• Future Economic Benefits: The software must be expected to generate future economic benefits, such as cost savings, revenue generation, or operational efficiencies.
• Resources to Complete: The entity must have adequate technical, financial, and other resources to complete the development and bring the asset into use.
• Reliable Measurement: Development costs must be capable of being measured reliably, ensuring accurate capitalisation.

Applying these principles ensures compliance with AASB 138, enhances financial statement credibility, mitigates reporting risks, and supports informed decision-making.

When to Expense Costs

Expensing software development costs is usually the right choice if the software won’t bring future economic benefits, has a very short life, or the costs are not high enough to justify making them part of the assets.

Expensing costs may be the more prudent course where economic benefits are uncertain, short‑lived, or immaterial. This approach can support transparent reporting and prevent overstating the organisation’s asset base.

Several situations require the development costs to be immediately expensed.

• First, costs from the early stages of the development process, like feasibility studies and requirement analysis, are usually accounted for as expenses right away. At this stage, it is often hard to prove a direct link between these costs and an identifiable asset during this time.  Furthermore, the project may not yet have reached a stage where its technical feasibility or commercial viability are able to be assessed.
• Second, if the software is expected to be useful for less than a year, expensing the costs makes sense. This situation often happens for software made for a specific short-term project or as a quick fix to a temporary challenge.
• Lastly, if the costs for developing the software are small, it can be easier to expense them instead of trying to capitalise. Materiality is an accounting idea that lets companies simplify their records by expensing tiny costs that don't really affect the users of financial statements.

Impact on Financial Statements and Tax Implications

CFOs should consider how these choices align with broader capital allocation strategies, tax planning, and the organisation’s financial performance narrative.
Expensing software development costs affects a company's financial statements. It leads to a drop in net income for the period when those costs are recognised. As a result, the reported profit is lower.

From a tax point of view, expensing software development costs can give a quicker deduction. This might lower a company's tax debt for the current period. Earlier deductions can help businesses that want to reduce their tax burden in the short run.

However, it is important to understand that whether you expense or capitalise does not change the real cash flow of the business. The cash is spent when the expenses are paid, no matter how the costs are recorded. The only difference is when these costs show up in the profit and loss statement, which affects how profitable the company appears.

Further, management should consider if they are eligible for R&D Tax Incentives.

RSM’s specialist R&D tax team can assist with the lodgement of R&D tax incentive claims, including advice on which types of expenditure are eligible.

Our National Technical Director, Ralph Martin, has also provided advice on the Accounting for the R&D Tax Incentive.

Real-World Examples of Software Development Cost Treatment

Looking at real-world examples can help management understand how companies decide whether to treat software development costs as expenses or as investments. Each example shows how the details of a project and the right accounting rules affect the decisions made.
Let's think about two different situations: one where an Australian IT company successfully capitalised its costs, and another where a start-up chose to recognise expenses instead.
These examples illustrate how CFOs can tailor their approach depending on commercial realities, resource availability, and long term value expectations.

Case Study: Successful Capitalisation in an Australian IT Firm

A well-known Australian IT firm that operates worldwide created a special mobile app. This app aims to make logistics and supply chain management easier for big companies. Developing the app took a lot of investment. This included having a dedicated development team, project management, and ongoing support.

The company found that the cost of living in Australia, along with the special skills needed for the project, made it best to treat the software development costs in this way. They listed the software as an intangible asset on their balance sheet. Then, they spread the costs over its estimated life of five years.

This way of doing things showed the long-term benefits of the mobile app. It was expected to bring in a lot of money through licensing deals with these big clients. Also, treating the costs this way gave a clearer view of the company's assets and profits over time.

Case Study: Expense Recognition by a Start-Up

A new start-up focused on creating online educational resources took a different path. They built a web platform with interactive lessons, quizzes, and features to track progress. While the UI design and user experience were very important, the start-up chose to record the development costs as they happened.

This choice came from the fact that the start-up was still young and hadn't made much money yet. Plus, the fast-changing education technology sector meant that the platform would need many updates soon. This created uncertainty about how long the platform would remain valuable.

By recording the costs this way, the start-up took a careful accounting approach. This reflected the problems that come with being new in a fast-moving industry. It also made accounting easier, which was helpful because the start-up had limited resources and a basic operational setup.

Compliance and Audit Readiness

Keeping accurate and complete records is not just a statutory obligation.  It is also very important for following accounting rules and supporting transparency, governance expectations, and long term value creation. This means writing down everything that happens during the software development process, from the first idea to the last steps of getting it working and keeping it running.

Good documentation makes audits easier. It also gives a useful guide for future projects. This way, the company can use what it learned from past work to make better choices.

Documentation and Record-Keeping Best Practices

Effective documentation and record-keeping are very important to explain how a company handles software development costs. Good documentation makes financial reports more clear. It also helps create a clear trail for audits, making the audit process easier and lowering the chance of future disagreements.

Here are some key things to include in your documentation process:

• Project Proposal and Approval: This should include what the project is about, its goals, and the estimated budget. It should show how the software will be used and what benefits it will bring.
• Development Contracts and Agreements: If you work with outside parties, keep contracts that outline the work, payment details, and any rights to the created software.
• Cost Records: You need a detailed list of all costs related to the project, such as staff salaries, software licenses, and equipment expenses. Make sure to keep these records clear and organized (nothing that costs between research and development phases need to be distinguishable).

Navigating Audits with Capitalised Software Costs

Preparing for audits, particularly when dealing with capitalised software costs requires meticulous audit readiness. Auditors will typically request supporting documentation to verify the accuracy and compliance of the capitalisation.

Below is a table outlining key considerations for audit readiness related to capitalised software:

By maintaining comprehensive records and proactively addressing potential audit inquiries, companies can streamline the audit process and enhance their financial reporting transparency and credibility.

Impairment Considerations

For CFOs and TCWG, impairment assessment is not just a compliance requirement it is a key governance checkpoint that ensures capitalised software assets continue to reflect their true economic value.

Software under development which is not yet amortised, heightens the need for an annual impairment review. This assessment should go beyond a procedural exercise and instead form part of the organisation’s broader financial oversight and investment monitoring.

In practice, impairment indicators for software assets often arise from strategic, operational, and commercial changes. For example:

• Shifts in technology or architecture (e.g., moving from an on premise build to cloud-native infrastructure) that render legacy components obsolete.
• Material changes in project scope, timelines, or budget that signal reduced likelihood of completion or diminished expected benefits.
• Changes in regulatory requirements (such as cybersecurity or data residency obligations) that make the original design unviable.
• Commercial developments, such as loss of a key customer segment or updated pricing strategies, that reduce the projected economic return from the software.
• Internal capacity constraints, including loss of key development resources or delays that push the project past expected payback periods.

CFOs should also consider whether the original business case assumptions remain valid. This includes revisiting:

• Forecasted cash inflows or cost saving expectations
• The assumed useful life of the software
• Whether competing solutions (internal or external) have entered the market
• Whether the project still aligns with corporate strategy and priorities

If impairment is identified, the carrying value should be written down to the asset’s recoverable amount, ensuring the balance sheet continues to accurately reflect the software’s economic potential. Early identification of impairment also allows TCWG to reassess project viability, reallocate resources more effectively, and maintain stakeholder confidence in financial reporting.

For further guidance on impairment considerations refer to Assessing impairment of assets in practice

Conclusion

In conclusion, it is important to know the difference between expensing and capitalising software development costs. This knowledge is vital for correctly reporting finances and understanding tax effects. How costs are managed and recorded is key for following rules and getting ready for audits. By using the right guidelines for each cost method and finding smart ways to manage costs, companies can make their accounting work better. Examples from real life show how these choices affect financial statements. To keep everything clear and efficient, businesses should follow good practices and be ready for audits about capitalized software development costs. Stay updated to make choices that fit your organisational goals.