Software development and SaaS expenditure under the policy spotlight

By Joe Hope, Brendan Ng and Robyn Walker

Back in 1993, the internet was something you dialled into (if you’d even heard of it), the cloud referred to actual clouds, and software came on floppy disks. Needless to say, a lot has changed since then.

Yet surprisingly, New Zealand’s tax laws and guidance for software still carry traces of that bygone era. Recognising the need for change, Inland Revenue has launched consultation on the income tax treatment of software development expenditure and the costs of configuring and customising Software-as-a-Service (SaaS).

What’s on the table?

At this stage… not much in terms of proposals. The consultation isn’t advancing specific policy options yet. Instead, it seeks to identify the challenges businesses face when determining the tax treatment of software-related expenditure and clarify which costs should be immediately deductible and which should be capitalised and depreciated. Detailed policy proposals are expected in a later round of consultation.

That said, the paper does hint at Inland Revenue’s thinking on software development and SaaS customisation costs. Here’s what you need to know.

Software development expenditure

The paper first looks at expenditure on software developed for sale or licensing, asking whether current approaches provide an appropriate basis for deductibility or depreciation. It outlines three main approaches currently in use:

1. Trading stock approach

In 1993, Inland Revenue’s position was that software development costs should be immediately deductible as the cost of producing trading stock. This made sense when software was sold on disks or CDs. Today, with software typically licensed or delivered as a service, Inland Revenue considers this approach outdated except where there is a full copyright assignment as part of an outright sale.

2. Depreciation approach

These days, software is typically distributed under non-exclusive licences or as a service, rather than sold outright, meaning it no longer qualifies as trading stock. Recognising this, Inland Revenue issued an issues paper in 2016 stating that software development expenditure should generally be capitalised as depreciable intangible property, with depreciation deductions applying when the software is available for use.

Under this approach:

• The applicable depreciation rates are 50% (diminishing value) or 40% (straight line).
• Upgrades can be capitalised and depreciated.
• Abandoned projects may qualify for a deduction under section DB 40B of the Income Tax Act 2007.
• Timing depends on asset recognition and whether the R&D rules apply.

Notably, this 2016 view was never finalised as Inland Revenue and tax administrations around the world continued to grapple with tax implications of software. However, most taxpayers would be using the depreciation approach (or the R&D approach described below), which often leads to questions of what expenditure, how much expenditure, and when expenditure should be capitalised. These questions are particularly relevant when considering the iterative nature of software development, especially in relation to maintenance and upgrades, and whether there is actually an upgrade or an improvement to the software.

3. R&D approach

Under section DB 34 of the Income Tax Act 2007, expenditure meeting the IFRS accounting definition of research or development (see NZ IAS 38 ‘Intangible Assets’) can be fully deducted in the year incurred or carried forward until an intangible asset must be recognised. Depreciation then applies to any remaining capital expenditure not covered by this section.

The paper acknowledges that applying section DB 34 can be challenging in practice. From our experience section DB 34 can provide businesses with a lot of clarity and reduce their compliance costs, however it is important to consider all the requirements for applying NZ IAS 38 and make sure that appropriate processes are put into place to be certain the appropriate position is taken.

The consultation paper also highlights that section DB 34 can result in asymmetric results. That is, expenditure can be deducted under section DB 34 but gains from the sale of assets created from the R&D may be non-taxable capital gains. Inland Revenue suggest a more symmetrical approach is justified, indicating this is likely something Inland Revenue will look at in more detail in the next round of consultation.

Inland Revenue’s view

Inland Revenue concludes that the current approaches to determining deductibility are broadly acceptable. However, they are seeking feedback on whether the unique nature of software development creates incorrect outcomes and whether alternative methods are warranted.

Software-as-a-Service (SaaS)

The second half of the consultation paper addresses configuration and customisation costs incurred by taxpayers licensed to use a SaaS application owned by a third party. In these arrangements, the SaaS provider hosts the software on its own cloud infrastructure and grants customers the right to use it. Business customers often require changes to the standard application of this software, which fall into two categories:

• Configuration: Adjusting settings within existing code.
• Customisation: Modifying or adding code to create new functionality.

For accounting purposes, the key question is whether any configuration or customisation creates an intangible asset. If no intangible asset is recognised (because the customer doesn’t control the software or no new resource separate from the software and controlled by the customer is created), costs are generally expensed.

For tax purposes, Inland Revenue’s 2023 interpretation guideline (covered in a previous Tax Alert) clarified that SaaS configuration and customisation costs may, depending on circumstances, be deductible as development expenditure or treated as relating to depreciable intangible property. But issues have emerged.

Under current law, deductions are allowed only if they meet section DA 1 (the general permission) and aren’t denied by the capital limitation in section DA 2(1). Inland Revenue considers the general permission to be met, but the capital limitation likely to apply, with the result being that the costs must be capitalised. Depending on the terms of the SaaS arrangement, a taxpayer may then be able to depreciate the right to use software under either the depreciable intangible property or fixed life intangible property rules.

Alternatively, even if the capital limitation does apply, section DB 34 could override this limitation if the costs qualify as “research” or “development” under NZ IAS 38, allowing the costs to be immediately expensed. The guidelines conclude that SaaS C&C costs are unlikely to be research but could be development; but would only fall under section DB 34 where the development work is undertaken in-house (i.e. not by a third party such as the SaaS provider).

From here, the consultation paper concludes that allowing SaaS C&C costs to be deductible under section DB 34 is not “tenable” from a policy perspective, though gives no reasoning other than the compliance burden. Instead, the paper suggests the best approach is for taxpayers to capitalise and depreciate all SaaS C&C costs—though officials are open to feedback on other approaches that may minimise compliance costs.

Deloitte’s view

Deloitte disagrees with Inland Revenue’s conclusion that allowing SaaS C&C costs to be deductible is untenable. Aligning the tax treatment with the IFRS treatment would be simpler, as SaaS costs expensed for accounting purposes are often hard to identify and capitalise for tax. Divergence between accounting and tax treatment creates unnecessary compliance costs for what is a minor timing difference (depreciation over roughly two and a half years given high depreciation rates for software). A separate rule / de minimis rule for those taxpayers who do not follow IFRS would also help.

Next steps

Submissions on the consultation close on 30 January 2026.

If you have questions about software or SaaS tax treatment, or if you would like to make a submission, please contact your usual Deloitte advisor.