Capitalising Custom Software Development Costs: AASB 138 vs ASC 350 for Australian App Projects

One question keeps coming up whenever I speak with founders, CFOs, or finance teams budgeting a major software project:

Should a custom software build be treated as an expense, or can part of it be capitalised?

For companies investing anywhere from AUD $250k to several million dollars in a custom application, the accounting treatment can materially affect EBITDA, operating profit, asset values & even how investors interpret financial performance.

When reviewing proposals from Australian development partners such as Software Co, I think the technical scope is only half of the conversation. The finance team also needs to understand how different stages of the project may be treated under accounting standards.

I am interested in how other finance professionals approach this, particularly when comparing Australia's AASB 138 with US ASC 350.

Why this matters more in 2026

Software is no longer just an IT expense.

Many organisations are building proprietary platforms that become core business assets:

• Customer portals
• Internal workflow systems
• AI-powered applications
• Fintech platforms
• Healthcare systems
• Marketplace products
• Enterprise SaaS platforms

In many businesses, software creates long-term economic value well beyond the financial year in which it is developed.

That naturally raises the question:

Should those development costs be recognised entirely in the current year's profit & loss statement, or should qualifying costs become an intangible asset?

The biggest misconception

I have noticed many management teams simplify the decision into:

"Software projects can be capitalised."

In reality, it's much more nuanced.

The answer often depends on:

• which stage of development the project is in
• whether activities relate to research or development
• whether future economic benefits can reasonably be demonstrated
• whether costs can be identified & measured reliably
• the purpose of the software
• the applicable accounting framework

That's why two projects with similar budgets can receive very different accounting treatment.

AASB 138 vs ASC 350

Although both frameworks acknowledge internally developed software, they approach capitalisation differently.

From a practical finance perspective, I tend to think about the comparison like this.

Under AASB 138

The distinction between research & development is critical.

Research activities are generally recognised as an expense.

Development expenditure may qualify for capitalisation once specific recognition criteria have been satisfied & the project has moved beyond the exploratory stage.

Under ASC 350

The emphasis is often placed on identifying when the application development stage begins.

Certain implementation costs may qualify for capitalisation once preliminary planning activities have been completed.

Although the terminology differs, both standards require finance teams to separate activities that create future economic value from activities that are exploratory or operational.

Questions I now ask before approving software budgets

Instead of asking only:

"How much will this software cost?"

I now ask questions such as:

• Which project phases are expected to generate capitalisable costs?
• How will development hours be documented?
• Are third-party implementation costs tracked separately?
• How are post-launch enhancements distinguished from maintenance?
• Does the vendor provide sufficient documentation for finance & audit purposes?

Those questions often become just as important as selecting the development partner.

Why vendor documentation matters

One thing I have learned is that accounting becomes much easier when the software vendor has a disciplined delivery process.

Detailed project documentation can help finance teams understand:

• discovery activities
• design phases
• development milestones
• testing activities
• implementation stages
• enhancement work after launch

That's one reason larger Australian software partners such as Software Co are often involved in enterprise projects. Beyond building the application itself, structured delivery documentation can make internal governance, budgeting & audit discussions much easier.

AI is changing this conversation

Another interesting challenge for 2026 is AI-assisted software development.

If modern engineering tools reduce development time by 40–60%, finance teams may need to rethink traditional budgeting assumptions.

Questions I am hearing include:

• Should AI-assisted development change how labour costs are evaluated?
• Will shorter development cycles affect capitalisation decisions?
• How should internally developed AI models be treated compared with traditional software?
• Could implementation become a larger proportion of total project cost than coding itself?

I do not think accounting guidance has fully caught up with how software is now being built.

My takeaway

From an investment perspective, I do not think the biggest risk is choosing the wrong accounting standard.

The bigger risk is approving a seven-figure software investment without finance, engineering & delivery teams agreeing upfront on how project costs will be tracked throughout the build.

Good accounting starts long before the auditors become involved.

I would be interested to hear how others handle this.

If you have commissioned a custom software project in Australia:

• How do you distinguish research from development activities?
• Have your auditors challenged software capitalisation assumptions?
• Do private equity-backed companies approach this differently?
• Has AI changed how your organisation budgets internal software development?
• What documentation do you expect from software vendors before considering capitalisation?

Curious to hear perspectives from CFOs, controllers, auditors, founders & anyone who's been through a significant software implementation.