You’ve just closed a quarter where your engineering team shipped three major features, refactored your authentication system, and started building a new customer portal. Your finance lead asks: “Which of these costs should we capitalise?”
The question sounds simple. However, the answer reshapes your balance sheet, influences investor conversations, and determines how much you’ll claim through the R&D Tax Incentive. For finance leaders at scaling software companies, software R&D accounting remains one of the most ambiguous and consequential decisions you’ll make.
Capitalise your development costs and you’ll show stronger profits this quarter, something investors love to see. Expense everything upfront, and your profit takes a hit now, but you avoid years of complicated paperwork tracking those assets. Choose poorly and you risk audit headaches or missed opportunities to strengthen your financial position.
Here’s how these decisions play out in practice, and what you need to know to get them right.
Understanding the Research vs Development Split
Under AASB 138 Intangible Assets, you can only capitalise development phase costs when strict criteria are met. Research phase costs always hit your profit and loss immediately.
Applying this to modern software development, especially when your team ships code continuously, gets complicated. The Australian Government’s guidance on internally-developed software separates software generation into two phases: research (all costs expensed) and development (costs capitalised only if recognition criteria are met).
Research means exploration. You’re figuring out what’s possible, testing ideas, and investigating options. Development means building something specific that you know will work.
Think of it this way: when your team is trying out three different database architectures to see which performs best, that’s research. When they’re building out the one you’ve chosen because you know it meets your requirements, that’s development.
The Capitalisation Criteria
To capitalise development costs, you need to meet four specific criteria.
First, demonstrate technical feasibility. You’re confident the software can actually be built. You’ve moved past “can we do this?” and into “here’s how we’ll do it.”
Second, show clear intention and ability to use or sell what you’re building. Resources are committed, there’s a plan in place, and you have a genuine intent to complete the project, not just explore possibilities.
Third, prove it will generate real economic benefits, like increased revenue or measurable efficiency gains. Vague hopes don’t cut it. You need to show how this software will actually make or save money.
Fourth, reliably measure and track the specific costs involved, keeping them separate from general overheads. That means no guessing at hours or lumping everything together.
Meeting these criteria in practice gets complicated quickly. BDO Australia points out that measuring and allocating software R&D costs, especially staff time and overheads, creates real challenges for most companies.
Take a typical two-week sprint. Your team fixes bugs, experiments with a new AI feature, improves the user interface, and lays the groundwork for future functionality. Now, try splitting those hours into research, capitalised development, and maintenance that must be expensed. Most companies quickly realise their time-tracking isn’t detailed enough to make these calls confidently. You need clear documentation about what everyone’s working on and systems that can separate different types of work reliably.
What Always Gets Expensed
Everything in the research phase goes straight to your profit and loss:
- Early feasibility studies and proof-of-concepts, where you’re still figuring out if something is possible
- Investigating different technical approaches before committing to one
- Initial prototyping before you’re confident the chosen approach will work
- Post-launch maintenance, bug fixes, and improvements, even substantial ones
Work that feels like development might still fail to qualify if you haven’t met all the criteria. The Australian National Audit Office makes clear that under AASB 138, software costs either qualify as an asset because they’ll generate future economic benefit, or they’re expensed immediately.
This is where many finance teams get tripped up. Your developers might be deep into coding, but if you can’t yet demonstrate technical feasibility or prove economic benefit, those costs still need to be expensed. The work feels like development, but for accounting purposes, it’s still research.
The Financial Impact of Your Choice
Your software R&D accounting approach changes how your business looks on paper. Each path carries distinct advantages and burdens that extend well beyond the current quarter.
Choosing to Capitalise
Capitalisation increases your assets, decreases current expenses, and improves profit margins. For companies raising capital or applying for loans, a stronger balance sheet makes a tangible difference in negotiations.
Investors often prefer seeing capitalised development costs because it balances your profit trajectory. Instead of massive losses during build phases followed by profitability, you show more consistent performance. Your asset base looks stronger, which can improve debt serviceability ratios and make you more attractive for financing.
The trade-off here is ongoing obligations. You’ll spread capitalised costs over several years through amortisation and regularly assess their current value. Auditors scrutinise these decisions closely because they involve judgement calls about future benefits.
Every quarter or year brings fresh assessments. Product pivots or discontinued features might trigger write-downs. Auditors want solid documentation backing your capitalisation choices, particularly around how you’ve allocated project costs.
The administrative burden compounds over time. You need to maintain detailed asset registers, track useful lives, calculate amortisation schedules, and conduct impairment reviews. For smaller finance teams, this ongoing work can become surprisingly time-consuming.
There’s also the risk of getting it wrong. If you capitalise costs that should have been expensed, you’ll face corrections during audits. These restatements can undermine investor confidence and complicate future financing rounds. The stakes are high enough that conservative finance leaders often prefer to expense borderline cases rather than risk capitalising incorrectly.
Choosing to Expense
Immediate expensing offers straightforward transparency at the cost of short-term profit. Your EBITDA and return on assets take a hit upfront. Companies without pressure to hit specific financial metrics often prefer this simpler path.
Expensing everything means your financials clearly show what you’re spending on development. There’s no ambiguity, no judgment calls about what qualifies for capitalisation, and no ongoing tracking of capitalised assets. Your balance sheet stays cleaner and your audit process stays simpler.
For bootstrapped companies or those with patient capital, this transparency can actually be an advantage. Some investors appreciate the conservative approach because it provides a clearer picture of cash burn and operating reality. They know exactly how much you’re spending on development each period without needing to dig into amortisation schedules.
Expensing also mirrors how modern software development actually works. Features evolve continuously. Deciding when something is truly “finished” becomes arbitrary. For teams shipping improvements every week, capitalisation, originally designed for projects with clear start and end dates, feels forced.
The main downside is obvious: your profit takes a beating during heavy development periods. If you’re trying to show profitability to raise capital or qualify for debt, expensing everything can make this harder to achieve. Your metrics look worse on paper, even if the underlying business is sound.
How Different Scenarios Change the Equation
The theory makes sense on paper. Real-world application demands understanding how your specific situation changes the calculus. Let’s walk through three common scenarios that illustrate the practical considerations.
H3: Building a SaaS Platform for External Customers
You’re developing a new SaaS product that will generate subscription revenue. Once you’re past experimenting and confident that the technology works, you can start thinking about capitalisation.
The foundational work that makes your product function and generate revenue typically qualifies. Building your authentication system, setting up your database architecture, creating your API infrastructure, and developing the core features customers will pay for all potentially qualify for capitalisation once you’ve established technical feasibility. You’ll need to document that all AASB 138 criteria are met, but the case for capitalising backend architecture, user management, billing systems, and customer-facing functionality is usually straightforward.
What always gets expensed? Initial market research, early prototypes, post-launch feature additions, bug fixes, and routine maintenance. The early months of exploring whether your product idea is viable never qualify for capitalisation. Even substantial development work after launch usually falls into the expense category because you’re improving an existing product rather than building a new asset. If you’re working on features that might not ship or where the business benefit isn’t clear yet, expense those too.
The strategic value of capitalisation shows up most clearly during your build phase. Smoothing profit figures during heavy development makes your financials more attractive to investors. When you’re raising capital or seeking debt financing, showing a stronger asset base and more controlled losses can be the difference between securing funding and being passed over.
Making this work requires excellent project tracking. You need systems that distinguish between building new core functionality and improving existing features. This means aligning how you track costs and substantiate them for both accounting and R&D purposes.
Most SaaS companies find capitalisation makes sense during their initial build phase, from establishing technical feasibility through to launch. After that, work shifts toward enhancement and maintenance, and most costs naturally become expenses.
Building Internal Tools and Operational Software
Your team is building custom internal tools, a bespoke CRM, inventory system, or analytics dashboard designed to improve operational efficiency.
Internal tools present a trickier capitalisation question than customer-facing products. You need to demonstrate clear efficiency gains or cost reductions. If your custom CRM saves your sales team 10 hours per week and you can document this reliably, you might have a case for capitalisation. The benefits need to be real and quantifiable, not hopeful projections.
Most internal development doesn’t clear this bar. The quick script your developer writes to automate a process, the dashboard built for the marketing team, the tweaks to existing systems, these typically get expensed. Exploratory work, small tools and scripts, and minor improvements all fall into the expense category because the business benefit is hard to pin down precisely.
For internal tools, the practical reality often tips toward expensing. Proving future economic benefits requires solid documentation and ongoing defence during audits. Unless your internal tool delivers substantial, measurable value, the extra work involved in capitalising rarely justifies the balance sheet benefit.
Internal tools also tend to have shorter lifespans than customer-facing products. Business needs change, priorities shift, and you might replace a custom analytics system after just two years. Shorter useful lives mean faster amortisation, which erodes much of the financial advantage of capitalising in the first place.
Most companies take a pragmatic approach, which means capitalising only the truly significant internal projects with clear, documented benefits. For everything else, the simpler path of expensing makes more sense.
Continuously Improving an Established Product
Your mature product evolves constantly, adding features, improving performance, responding to customer feedback, and maintaining security. The question is whether any of this qualifies for capitalisation.
Most of it doesn’t. Iterative improvements, technical debt reduction, performance tweaks, security patches, and regular maintenance all get expensed. Once your product is established, the bulk of work falls into maintenance and enhancement. Adding requested features, improving existing functionality, fixing bugs, updating dependencies, refactoring code, all of this typically gets expensed even when it represents substantial development effort.
The exception is when you’re building something that genuinely extends your product’s capabilities. Think of substantial new functionality that could almost be a separate product. For instance, adding a complete reporting suite to your existing application, building a mobile app when you’ve only had web, or creating an enterprise tier with significantly different functionality, these might qualify for capitalisation because they represent distinct new capabilities you could separately identify and value.
The line between enhancement and maintenance gets blurry with established products. Conservative interpretation means expensing most work unless you’re building something distinctly new and substantial. This is why many mature software companies incur most of their ongoing development costs. The nature of work has shifted from building new assets to maintaining and enhancing existing ones. While this hits current profitability, it reflects the economic reality of the business.
Some companies argue that continuous improvements build value in the existing asset and should be capitalised. This approach invites audit scrutiny and rarely holds up. The safer path is capitalising only when you’re genuinely building something new and substantial that extends beyond normal product evolution.
How the R&D Tax Incentive Changes Things
Your accounting treatment doesn’t determine R&D Tax Incentive eligibility. Both expensed and capitalised R&D qualify for claims.
This surprises many finance leaders who assume the two systems align. They don’t. You can capitalise development costs for accounting purposes and still claim them for the R&D Tax Incentive. You can also expense everything in your accounts whilst claiming substantial R&D incentive benefits.
Eligibility hinges on what your team actually does, experimental work, creating new knowledge, solving technical uncertainties, and whether you can prove it. How costs appear in your accounts matters for financial reporting, not for R&D claims.
The ATO’s guidance on in-house software explains how deductions and depreciation work when costs are capitalised but remain eligible for R&D claims. You can optimise software R&D accounting for financial reporting whilst maximising R&D Tax Incentive benefits.
This separation means you need two different documentation systems working together. Your accounting records track costs, according to AASB 138 criteria. Your R&D documentation tracks eligible activities, according to ATO requirements. The two systems capture the same spending from different angles.
Good documentation becomes critical. Track what your team works on separately from accounting classifications. Developers’ sprint notes, technical decision records, and experiment logs provide essential evidence when satisfying both accounting requirements and R&D eligibility for the same spending.
Many companies make the mistake of assuming their accounting classifications automatically support their R&D claims. They don’t. You need separate documentation showing the experimental nature of the work, the technical uncertainties addressed, and the new knowledge generated. Your engineering team’s existing documentation often provides this if you know what to look for.
The practical implication: don’t let your accounting treatment dictate your R&D claims strategy. Make capitalisation decisions based on financial reporting needs and investor considerations. Make R&D claim decisions based on the actual nature of your development activities. Maintain documentation that supports both.
Finding the Right Approach for Your Company
The right approach depends on your specific circumstances. Several factors should influence your decision.
What you’re building matters. Customer-facing revenue-generating products make stronger capitalisation cases than internal tools or infrastructure because the economic benefit is clearer and easier to document. How you’re building it matters too. Traditional waterfall projects with defined stages and clear deliverables fit naturally with capitalisation; you have obvious points where technical feasibility is established. Agile environments with continuous deployment create ambiguity because work flows without clear completion points.
Your operational reality shapes the decision. Can you reliably track and allocate costs at a detailed level? Many companies discover their time-tracking isn’t granular enough to support confident capitalisation decisions, and building these systems takes time and ongoing discipline. Does your finance team have bandwidth for the ongoing admin work, maintaining asset registers, conducting regular reviews, and supporting audits? Smaller teams might prefer expensing everything to free up time for more strategic work.
Your funding situation and risk appetite come into play as well. If you’re raising capital where balance sheet strength matters, capitalisation can help. Showing higher assets and smoother profit trajectories makes a difference in investor presentations and debt applications. But capitalisation attracts closer auditor scrutiny. You need solid controls and documentation to back up decisions, and getting it wrong means restatements that damage credibility. Some finance leaders prefer the simplicity and safety of expensing most costs rather than defending capitalisation decisions. If you have patient capital that values transparency, straightforward expensing might suit you better.
Most scaling software companies end up with a hybrid approach. Capitalise your initial platform build once technical feasibility is established, and do the same with significant new product lines or modules that clearly extend capabilities. Then expense ongoing improvements, maintenance, and anything that falls in the grey areas. This gives you some balance sheet benefit without the full complexity of trying to capitalise everything.
Being selective makes the approach workable. You get financial reporting benefits where they matter most, during major build phases, while keeping most of your ongoing development accounting simple and defensible.
Making Informed Decisions
Software R&D accounting presents genuine complexity. AASB 138’s technical requirements weren’t designed for modern agile development and continuous deployment, yet finance leaders must apply them to how software is actually built today.
The standard assumes projects with clear beginning and end points, distinct phases, and obvious completion markers. Modern software development often looks nothing like this. Features ship incrementally, products evolve continuously, and “done” is a moving target. Forcing these accounting rules onto this reality requires judgment, documentation, and often a fair bit of pragmatism.
Success requires understanding more than accounting standards. You need to grasp how software development works, how R&D Tax Incentive rules interact with capitalisation decisions, and how different approaches affect your funding and growth plans.
The best approach often comes from collaboration between finance and engineering. Your finance team understands the accounting requirements and financial implications. Your engineering team understands what’s actually being built and how the work breaks down. Bringing these perspectives together helps you make decisions that are both compliant and practical.
By understanding the nuances of accounting standards and your business goals, you can ensure compliance while optimising financial outcomes. If your team is investing heavily in software development, Rocking Horse Group may be able to help your company unlock funding and maximise benefits through the R&D Tax Incentive.