Employee Allowances


Undeveloped software taxation

Tax Alert - August 2016

By Troy Andrews

The tax position of software developers hits at the heart of New Zealand’s 3.0 export economy: technology.  Inland Revenue has released an Issues Paper: Income tax treatment of software development expenditure[1].  The purpose of the paper is to revisit the guidance they provided in 1993.  To give you some context, this was the year that Encarta was first released on CD Rom.  The new issues paper asks the industry a number of questions to – hopefully – help frame the right policy settings to support this future economy.  Inland Revenue have asked for submissions to these difficult - but important - concepts by 25 August 2016.

The issues paper is a continuation of Inland Revenue’s ‘inclusive’ approach to policy setting which is to be commended.  The inevitable difficulty is that its starting point is to test whether the 1993 ‘settings’ are correct in today’s environment when concepts like software as a service (SaaS) and ‘the cloud’ or an App, were still futuristic ‘to be’ discoveries.  We would prefer a blank canvas starting point.  The reality is that we need policy settings that are very clear to apply and generous to taxpayers to ensure New Zealand is a global leader.  This is relevant to our pioneering giants (like Xero, Orion Health and Vista Entertainment Solutions) and to make sure our SME / start ups follow their success.

The issues paper asks a number of questions looking at three areas:

1)   Trading stock

2)   The depreciation regime

3)   R&D

Trading stock

The 1993 guidance created uncertainty for software developers that continues today. This is because it discussed applying the trading stock rules where software was developed for sale or licence.  Being within the trading stock rules could be seen as concessionary as it let taxpayers take a deduction for their costs of developing software.  However, these were difficult concepts to then apply.  The guidance continued that if the software was sold once, then it had a ‘nil’ closing stock (but with no legislation to support this).  An inevitable tension would also arise if the taxpayer had an opportunity to ‘exit’ as trading stock is taxable when sold in an M&A context.

The current issues paper still starts with an open question of when the trading stock rules should be applied, and how.  The proposal is a much narrower application – suggesting that maybe it is only when “it is being produced for sale by way of assignment of all or part of the copyright rights”.  This still feels like an unnatural application of the trading stock rules and will create uncertainty.  Whenever there is continuing copyright or intellectual property that the software developer could use again, the more comfortable regime is the depreciation regime which also has challenges.

Taxpayers should work through their business model and a detailed analysis of the rights that they provide customers and those that they maintain, to help with Inland Revenue’s education.  Taxpayers should also consider their current tax position and whether there might be transitional rules that could impact them – if they have taken a position that it was trading stock, but won’t be going forward.

The depreciation regime

In our view, the depreciation regime is likely to be the more natural regime to tax most software companies.  This is on the basis that they build and develop an asset that is capable of being “sold” and “resold” to their customers in different legal forms.  The nature of these legal forms will be varied and might include full or limited copyrights – depending on the nature of the software.  A good example is ‘open source’ software or the increasingly ‘customisable’ platform licences (where customers can take solutions from a number of developers, to modify and potentially use or resell  a new solution).  The depreciation regime does have difficulties for taxpayers to work through. For example:

  • Internal costs – small developers do not have sophisticated financial reporting systems to capture internal costs that should be ‘capitalised’.  The development team’s wages and overheads are often recognised as an expense for accounting purposes and often deducted for tax purposes.  These internal costs should be capitalised and depreciated which does increase compliance.
  • What depreciation rate to use – software and software rights fall within the ‘tangible’ depreciable property regime (with a generous 50% DV depreciation rate) and within the intangible depreciable property regime (with a less generous depreciation deduction spread over its legal life).  It would be useful for Inland Revenue to clarify in legislation when each rate should be used – or confirm whether it might be a choice.
  • Upgrades v maintenance – where continued development might comprise a capital upgrade compared to deductible ‘maintenance’ is another unclear area.  The paper suggests that a test might be whether it materially increases the capacity or performance of the software?  It gives examples of bug fixing or making minor changes, compared to adding new features.  In practice, this can be difficult to apply when development teams have a continual improvement methodology – or don’t track and allocate their activity.  Inevitably this has a compliance cost for the taxpayer.
  • Feasibility - the paper also raises whether some expenditure that would otherwise be capital in nature might be deductible as feasibility expenditure.  Traditionally this has been expenditure that is incurred ‘before’ there is a commitment to pursue a particular course of action.  This particular discussion will have to be suspended while Inland Revenue considers how to digest its “new” position following the Trustpower[2]  case where it succeeded in the Supreme Court, that such expenditure was not deductible.

Research and Development

The research and development (R&D) rules are another discussion area the paper raises.  These rules provide a specific deduction (that overrides the capital limitation) where expenditure qualifies as “research” or “development” and is expensed under the appropriate accounting standard (now IAS 38).  There are also a number of other benefits from falling within these rules, such as potentially cashing out losses or deferring the tax deduction (which can be a benefit for taxpayers in losses). 

The principle behind the R&D rules is positive.  However, the reality of how they are applied in practice is often complicated with high compliance costs.  For a taxpayer to use the rules, they need to apply the full IAS 38 accounting standard (as an IFRS taxpayer).  This has traditionally not been the case for taxpayers that apply the differential reporting concessions, or today, for taxpayers that do not prepare financial accounts that adopt IFRS/IAS38.  Essentially, the R&D rules often become unavailable for those that need them most (startups and SMEs).

Another compliance issue – which the issues paper confirms – is that recognising an amount as an expense for accounting purposes under IAS 38 is not sufficient to be R&D.  The issue is that IAS 38 is the accounting standard for ‘intangibles’ which is a much wider concept than “research or development”.  In addition to being recognised as an expense under IAS 38 a software developer will also need to review their expenditure to ensure that it qualifies as “sufficiently innovative”.  The paper sets out that judgement will be required and will be determined on a case by case basis which only adds to taxpayer uncertainty.

The evolution and revolution of software development as an industry will continue and probably speed up.  New Zealand heralds its opportunity to finally export to a world market with a product that isn’t limited by shipping logistics.  The industry already has many issues around attracting and retaining talent while trying to promote increased technology education into schools.  The increase of innovation hubs and generous technology grants are all great progress for the future.  Inland Revenue needs to also modernise its policy settings and approach.  Rather than providing taxpayers with a complex compliance challenge, a blank canvas approach could help uncover a specific and generous regime where software developers of all types are supported to build New Zealand 3.0.

[1] IRRUIP10

[2] Trustpower v Commissioner of Inland Revenue SC 74/2015

Did you find this useful?