Funding models: Moving beyond Projects
Leading product organisations operate fundamentally differently from the rest. While most Australian businesses remain stuck in project delivery cycles, the best product organisations have moved beyond projects entirely. They've discovered this shift unlocks powerful financial strategies that transform how their businesses appear to investors, auditors, and acquirers.
What separates leading product organisations isn't just how they build software. It's how they allocate capital to reflect the continuous value creation that product development actually represents. Traditional businesses treat software development as operational expenditure that disappears into the P&L. Leading product organisations recognise it as the strategic asset it is.
This article explores why leading product organisations move away from project thinking and how they implement capital allocation strategies that reflect the true value of software development. We examine practical approaches adopted by successful Australian companies, compliance considerations, and opportunities to maximise R&D Tax Incentive benefits.
What gets me excited about this isn't just the accounting angle (though that's substantial). It's watching businesses finally align their operating model with how value actually gets created. I've seen this transformation firsthand at some of Australia's leading product organisations, where moving to Product Operating Models combined with strategic capital allocation has fundamentally changed their financial position.
Important: This is general information only, not financial, accounting, tax, or legal advice. Seek advice from qualified professionals, including your accountant, auditor, tax advisor, and legal counsel, before implementing any capital allocation strategy.
Why Move Away From Projects in the First Place?
Traditional project-based delivery is failing at rates that should terrify any CFO. The Australian government's own digital projects show 37% reporting medium or lower delivery confidence, representing $3.5 billion in at-risk spending. The Digital Transformation Agency identifies consistent issues: pressure to start delivery quickly instead of developing robust business cases, schedules that don't represent the full complexity of tasks, and optimism bias in cost estimates.
Here's what really bothers me about project thinking: it optimises for the wrong outcomes. Teams focus on "on time, on budget, on scope" and lose sight of delivering customer value. I've seen this play out repeatedly. During my time at an Australian bank, we looked retrospectively at historical business cases. The results were staggering. They were 28 times off on what should have been their profit if those business cases had been achieved. Flat out, they are fantasy.
Projects create another problem: they build features nobody uses. Research shows that 80% of features are rarely or never used. You're investing millions in capabilities that sit dormant in your codebase, creating maintenance burden and complexity without delivering value.
The alternative delivers better results. When you shift to iterative product development, you can test, learn, and kill features that don't deliver value before they become expensive technical debt. Organisations with mature Product Operating Models achieve significantly higher returns, better margins, and faster development cycles.
Why Project Thinking Limits Your Balance Sheet
Project thinking constrains your financial position in ways most executives don't appreciate. When you treat software development as purely operational expenditure, every dollar spent immediately reduces your profitability on paper. This creates pressure to minimise investment in capabilities that drive competitive advantage.
Australian businesses that shift to durable product teams unlock a powerful financial lever. By treating software as the intangible fixed asset it is, you spread costs over the useful life of those assets. This strengthens your balance sheet while accurately reflecting the long-term value your software creates.
Understanding CAPEX vs OPEX for Software Development
Software programmes qualify as intangible fixed assets when your entity controls those assets through custody or legal rights like patents or copyright. They normally provide benefits for longer than one year, making them capital assets.
This allows you to capitalise costs and spread them over the asset's useful life. CAPEX spend doesn't appear on your P&L as an expense. OPEX, by contrast, immediately reduces profitability while contributing to your business assets. This is powerful when maximising the apparent value of your business for investors or acquirers.
The distinction: CAPEX represents investment in building and improving your product capabilities. OPEX covers ongoing operational costs of running your business. Software development that enhances product capabilities qualifies for capitalisation.
Two Approaches: Simple vs Complex
Australian businesses have experimented with two models for allocating costs between CAPEX and OPEX. The simpler approach wins, and I'm not being diplomatic about this.
Role-based allocation treats entire positions as either capital or operational based on their primary function. Each area maintains a CAPEX budget based on forecasted team composition. You write papers each half to track spend: plan versus actual and projections going forward. This sits on your balance sheet and requires governance to provide assurance for auditors.
Timesheet-based tracking requires employees to submit monthly timesheets with codes for CAPEX and OPEX. This feeds quarterly review processes. While theoretically more precise, this creates significant administrative burden. Not recommended based on Australian company experience.
Governance needed for either approach: audit committee and programme management that informs the committee of changes. Critical practice: keep reports and records current. Retrospectively tracking this information becomes a massive job.
Which Roles Get Capitalised?
A clear rule guides allocation: stakeholders and support staff are OPEX, while builders are CAPEX.
CAPEX roles:
Software Engineers
Product Managers
Analysts
Project Managers
Testers
These roles directly contribute to building and improving your software assets. Product Managers deserve particular attention given the modern function of the role. Worth challenging with your auditor based on your specific context.
OPEX roles:
Business stakeholders
Support staff
Operational teams
Budget planning uses proxy percentages based on role type, with budgets based on the ratio within a given team. This creates predictability while maintaining accuracy at the portfolio level.
Maximising R&D Tax Benefits
Australian businesses can layer R&D Tax Incentive benefits on top of capitalisation strategies. The R&D tax incentive provides tax offsets for eligible R&D activities that benefit Australia.
For companies with aggregated turnover under $20 million that aren't controlled by tax-exempt entities, the refundable tax offset applies at an 18.5% premium above the company's tax rate. For a company with a 25% tax rate, this means a 43.5% refundable offset. Larger companies access non-refundable offsets through a progressive tiered structure based on R&D intensity.
The programme rewards businesses conducting experimental activities to generate new knowledge or create new or improved products, processes, or services. Software development frequently qualifies when you're solving technical uncertainties rather than applying known techniques to new contexts.
Compliance matters. You must register R&D activities with AusIndustry and claim the offset through your annual company tax return. Maintain detailed records of experimental activities, technical uncertainties, and how you addressed them. Many Australian businesses engage specialist advisors to optimise claims and ensure compliance.
Working With Your Auditor
Your auditor must be your partner in implementing capitalisation approaches. Major Australian accounting firms have extensive experience with these practices.
Engage your auditor following this sequence:
Inform upfront. Don't surprise your auditor mid-year with a new capitalisation approach
Provide structure. Present your proposed model with identified risks and mitigations
Seek advice. Ask what they think, don't tell them how it is. Auditors can push back and create significant friction if they don't understand or haven't been consulted
Reference standards. Ask what standards they've used with similar firms
Maintain communication. Keep an open flow of dialogue about your approach and reasoning throughout implementation
The governance structures you establish (audit committees, programme management, and regular reporting) provide the assurance your auditor needs.
Conclusion
Moving beyond project thinking accurately represents the value your software creates while optimising your financial position. When you combine the Product Operating Model with strategic capital allocation, you position your business for sustainable competitive advantage.
Your action plan
Assess your project outcomes honestly. Review recent initiatives against actual business value delivered, not just whether they hit time and budget targets
Model the financial opportunity. Engage your CFO to assess the balance sheet impact of capitalising software development
Choose role-based allocation. Avoid timesheet-based models unless you have compelling reasons and significant administrative capacity
Define role classifications clearly. Categorise which roles qualify as CAPEX versus OPEX and document your rationale
Explore R&D Tax Incentive benefits. Review whether your software development activities qualify for R&D tax offsets[3]
Engage your auditor early. Inform them before implementing changes, present your model with risks and mitigations, and seek their advice
Build governance structures. Establish audit committees and programme management oversight. Keep records current, not retrospective
Remember, seek professional advice from your accountant, auditor, tax advisor, and legal counsel before implementing any capital allocation strategy. Your specific circumstances matter significantly.
FAQ
Q: Will capitalising software development manipulate our financials?
No. You're recognising software as the asset it is. If your software provides value beyond one year and you control it through legal rights, it qualifies as an intangible fixed asset under accounting standards. This isn't creative accounting; it's accurate accounting.
Q: What if we're still running some projects alongside product work?
Start with role-based allocation for your product teams. As you transition away from project delivery, your capitalisation approach will naturally expand. Don't wait for perfection.
Q: How long should we depreciate capitalised software?
This depends on the useful life of your software assets. Common ranges are 3-5 years for technology assets, but discuss with your auditor based on your specific context and industry norms.
Q: Can we capitalise costs retrospectively?
Theoretically, yes, but practically, it becomes a massive job. Start from a clean slate going forward. Your auditor will thank you, and you'll save significant effort.
Q: Does capitalisation work for SaaS businesses?
Yes. SaaS businesses build software assets that generate recurring revenue. The continuous improvement model of product development aligns particularly well with capitalisation strategies.
Q: What about maintenance and bug fixes?
General maintenance and bug fixes are typically OPEX. Enhancements that improve functionality or extend useful life qualify as CAPEX. The distinction: are you maintaining existing capability or building new capability?
Q: How does this interact with cloud costs?
Infrastructure costs (AWS, Azure, GCP) typically remain OPEX. You're capitalising the labour costs of building software, not the hosting costs of running it.
Q: Will this approach increase our audit costs?
Potentially slightly in the first year as your auditor validates your model. Ongoing costs should be minimal if you maintain good governance and documentation. The balance sheet benefits typically far outweigh any incremental audit fees.
References
