Two weeks ago I came across an article on interest.co.nz: BNZ is taking a NZ$253 million hit to its half-year profit because of a change to how it accounts for software it has built internally.1 The gist is that AI is making software obsolete faster, so BNZ now spreads the cost of that software over a shorter period. More cost flows through sooner. Big number, one period.
My first reaction was "fair enough, sounds like a sensible call." My second reaction, about ten minutes later, was something I hadn't expected: I realised I had never thought about what AI-assisted development actually does to the finance side of building software. Not the cost of the compute. Not the licensing. The accounting treatment of the software itself.
I used to be an accountant before I ended up in data engineering. I am rusty enough that I would not offer this as professional advice to anyone, but I am not so rusty that the thread I started pulling did not lead somewhere interesting. Consider this food for thought rather than a technical briefing.
Why Does It Matter How You Account for Software?
Most people outside finance have a vague sense that companies can treat some costs differently depending on whether they are "capital" or "operating" expenses. The short version: some costs get spread over multiple years on the balance sheet (capital), and some hit your profit and loss immediately (operating). Same money, very different story in the numbers.
Software a company builds itself can sometimes be treated as a capital asset. You put the development cost on the balance sheet, then spread it forward over the years you expect to use the software. Your reported profits look better in the short term because you are only expensing a slice each year rather than the whole thing at once.
But here is the rule that governs how long you spread it: you have to be honest about how long that software is actually going to be useful. And when AI is making software faster to build and faster to replace, "how long is this software going to be useful" becomes a much more uncomfortable question than it used to be.
The international accounting standard on this (IAS 38, which NZ follows) is actually pretty direct about it. Paragraph 92, sitting right in the mandatory standard text, says:2
"Given the history of rapid changes in technology, computer software and many other intangible assets are susceptible to technological obsolescence. Therefore, it will often be the case that their useful life is short."
That was written in the 1990s. The IASB presumably had no idea that by 2026 a developer with an AI coding assistant could go from idea to production in days. But the principle is right there, baked into the standard: software ages fast, plan accordingly.
What BNZ appears to have done is conclude that AI is accelerating this enough that their previous assumptions about useful life were too optimistic. So they revised them down, and the catch-up cost landed in one period. That is my reading of the announcement based on publicly available information. The actual half-year financial statements had not been published at time of writing, so the exact mechanism will be clearer once they are.1
Quick analogy if you are not an accounting person: Imagine you bought a work laptop and planned to depreciate it over five years. Suddenly laptops are being replaced every 18 months in your industry. You should probably update your assumption. If you do, the remaining cost hits your books faster. That is essentially what BNZ did, just with hundreds of millions in internally built software rather than laptops.
Why This Is Interesting Right Now
There is a thing happening in the tech industry that people are calling the SaaSpocalypse. The basic story: for the past fifteen years, companies bought software rather than building it. Monthly subscriptions, cloud-hosted, someone else's problem to maintain. It was the rational choice because building was slow and expensive.
AI coding tools have started flipping that calculation. Klarna replaced Salesforce's CRM with an internally built AI system.3 Thoughtworks eliminated three SaaS platforms from its own marketing stack, replacing them with custom-built workflows.4 According to Forrester's analysis, over a trillion dollars in SaaS market capitalisation disappeared in a single week in February 2026 as investors started pricing in this risk.5
The conversation around this has been almost entirely about technology strategy: does it make sense to build rather than buy if AI makes building cheaper? That is a legitimate question. But there is a finance angle to it that I have not seen anyone discuss, and the BNZ article made me think about it properly for the first time.
When you pay for SaaS, the cost hits your books immediately as an expense. Subscription fee this month, expense this month. Nothing sits on your balance sheet. Simple.
When you build your own software, the initial development cost can potentially sit on your balance sheet as an asset, spread forward over the software's useful life. That sounds like a win. But the accounting rules have a few catches that the SaaSpocalypse conversation completely glosses over.
Three Things That Make the "Build = Better Balance Sheet" Story More Complicated
I want to be clear: I am not saying building is a bad idea. For a lot of organisations it is probably the right call. But if part of the rationale is "we will move spend from operating expenses to capital assets," the accounting reality is messier than that framing suggests. Here are three reasons why.
The first catch: not all development costs actually qualify
To put development costs on your balance sheet rather than expensing them immediately, you have to clear a reasonably high bar. The international standard requires you to demonstrate six things simultaneously: that the software is technically feasible to complete, that you intend to finish and use it, that you can actually use or sell it, that it will generate real economic benefits, that you have the resources to complete it, and that you can reliably measure the costs.2
Miss any one of those and the cost goes straight to the P&L. No partial credit. The standard is explicit: an intangible asset from development "shall be recognised if, and only if" all the criteria are met (IAS 38.57).2
And here is the part that matters just as much: only costs in the development phase qualify for this. Earlier exploratory work, the stuff you do to figure out whether something is even worth building, has to be expensed regardless. The standard calls this the "research phase," and paragraph 54 is completely unambiguous about it:
"No intangible asset arising from research (or from the research phase of an internal project) shall be recognised. Expenditure on research (or on the research phase of an internal project) shall be recognised as an expense when it is incurred."
There is also a one-way trapdoor built in. Paragraph 53 says that if you cannot clearly distinguish which of your work is research and which is development, you must treat all of it as research and expense the lot.2 The standard does not let you give yourself the benefit of the doubt on the boundary.
With traditional software projects there was usually a clear moment when you moved from "figuring out if this is possible" to "we are definitely building this, here is the spec." That transition was meaningful because it was often when you started spending serious money on development.
With AI coding tools, that line gets blurry. You can go from vague idea to working prototype in an afternoon. Is a prototype research or development? If you then iterate on it rapidly for three months before it looks anything like a finished product, when exactly did the capitalisable development phase start? I do not think this has a clean answer yet, and it is the kind of question that auditors are going to be wrestling with more as AI-assisted development becomes the norm.
The second catch: ongoing development mostly still hits your P&L
Say you clear the bar and capitalise your initial build. The standard then says something that tends to get overlooked: most money you spend on that software after the initial build cannot be added to the asset. It still has to be expensed as you go. The exact wording from IAS 38 paragraph 20:2
"Most subsequent expenditure on an intangible asset is likely to maintain rather than meet the definition of an intangible asset and the recognition criteria... Therefore, only rarely will subsequent expenditure be recognised in the carrying amount of an asset."
In plain language: bug fixes, incremental features, performance improvements, all the things a real software team does continuously, are almost certainly expenses in the period you do them, not additions to your balance sheet asset.
This raises a question that I think is genuinely unresolved: modern software, especially software built with AI tools, is rarely delivered as a finished product on day one. Teams ship something minimal, fast, then iterate continuously. Wireframe to production in days. Features added in sprints for months or years afterward. The whole agile philosophy is built around continuous delivery rather than big-bang releases.
If that is the reality of how AI-built software actually gets delivered, is the "initial build" phase even a meaningful category anymore? Or does most of the work fall under the "ongoing iteration" that paragraph 20 says should be expensed? I am raising this as a genuine question rather than a conclusion. But it seems worth thinking about if you are a company planning to build a lot of internal software and expecting accounting treatment to work in your favour.
The third catch: the "useful life" question just got harder
Even for the portion that does get capitalised, you have to make a call about how long the software will remain useful. Get that estimate wrong on the optimistic side and your reported profits are inflated relative to reality. The BNZ announcement is a signal that AI is making "how long will this software last" a harder question to answer honestly, and that at least one major institution has decided to revise its estimate in the direction of shorter rather than longer.
The SaaSpocalypse is real as a technology strategy. Whether it delivers the accounting benefit that some people assume is a different question.
Who Might Have an Incentive to Get This Wrong
None of the above is about fraud. Companies and their auditors make judgement calls on these questions all the time, and most of them are made in good faith. But the accounting rules do involve significant judgement, and judgement tends to bend toward incentive.
There is a specific situation where the incentive bends hard: companies that are about to be sold or going through an IPO.
When a company is being valued for sale, the number that often matters most is EBITDA: earnings before interest, taxes, depreciation, and amortisation. The amortisation of capitalised software reduces EBITDA. So a company that capitalises its development costs aggressively, and assigns long useful lives to the software it builds, will show a higher EBITDA than a company that is more conservative. Same money spent. Very different headline number on the investment banker's slide.
PE-backed company, heading for exit
Building lots of software with AI tools. Has every incentive to capitalise as much as possible, assign long useful lives, and treat ongoing iteration as capitalisable enhancement rather than ongoing expense. Each individual judgement is defensible. Whether optimism tends to cluster around exit timelines is a fair question to ask.
Pre-IPO growth company
Needs a compelling story for institutional investors. Capitalising development costs improves reported profitability. Useful life assumptions tend not to get scrutinised hard until after the listing. If they turn out to be wrong, the write-down happens on someone else's watch.
Listed company with external audit
Analyst scrutiny, audit committee pressure, disclosure requirements. BNZ proactively taking a $253m hit rather than letting the problem compound is a good example of what governance pressure produces. Not perfect, but much harder to quietly inflate.
SME with no exit in sight
Often takes the simplest approach, which is usually the most conservative one. More likely to expense everything than to over-engineer a capitalisation policy. Not a concern from a misrepresentation angle.
If you are buying a company or evaluating one before it lists, it is worth looking at how they account for internally developed software. The financial statements have to disclose the useful life assumptions they use. If a company building AI-assisted software in 2026 is disclosing five-to-seven year useful lives, that is a claim worth questioning.
One caveat worth adding: PE-backed companies still get audited, and auditors are supposed to test useful life assumptions for reasonableness. The governance pressure is real, just less intense than on a listed entity. Audit quality varies, and the assumptions are genuinely judgemental enough that a motivated CFO has room to move. But this is not a free run either.
And to be fair to the broader picture: accounting treatment is rarely the main reason a company decides to build or buy software. Most of the time the primary drivers are risk, support model, integration complexity, vendor lock-in, and whether the team can actually maintain what they build over time. The accounting angle is a secondary effect, not a primary one. I am raising it because it seems underappreciated, not because I think it dominates the decision.
Does This Apply the Same Way Everywhere?
Mostly yes, with one notable exception. New Zealand, Australia, the UK, the EU, and most of Asia all follow IFRS (or a local equivalent that is functionally identical). The same rules apply. The 2021 ruling that made SaaS implementation costs harder to capitalise applies across all of them too.
The exception worth knowing about is the United States, which uses its own accounting rules (US GAAP). The US treats software costs through a different framework with three prescribed phases. The capitalisation window tends to be slightly broader than under IFRS, which means US companies can sometimes capitalise more of their development costs than an equivalent IFRS company would. This matters if you are comparing companies across markets:
| Where | What standard | Roughly how it differs |
|---|---|---|
| 🇳🇿 NZ, 🇦🇺 AU, 🇬🇧 UK, 🇪🇺 EU, most of Asia | IFRS (IAS 38) | Baseline. High bar to capitalise development costs. 2021 SaaS ruling applies. Ongoing iteration mostly expensed. |
| 🇺🇸 United States | US GAAP (ASC 350-40) | Three prescribed phases. The "application development" phase is somewhat broader than IFRS allows, meaning US companies may capitalise more. Useful life rules still apply. Balance sheet comparison with IFRS companies needs adjustment. |
| 🇬🇧 Smaller UK companies | FRS 102 | Smaller entities can choose to expense all development costs rather than capitalise any of it. Simpler but means balance sheets look different from large IFRS reporters. |
The practical takeaway: if you are comparing two tech companies, one listed in New Zealand and one in the US, their software asset balances are not directly comparable. The US company might have more on the balance sheet not because they built more, but because their accounting standard allowed them to capitalise more of what they built.
What I Actually Think About All of This
I did not expect to spend an evening thinking about accounting standards when I clicked on that BNZ article. But here we are.
The thing I keep coming back to is this: the build-versus-buy conversation has shifted dramatically because of AI, and that shift is probably real and probably rational for a lot of organisations. Building your own software, with AI tools making it faster and cheaper, genuinely does give you ownership, flexibility, and the ability to iterate on your own terms. I have written about this from a technical angle before. But from experience, building being cheap upfront is not the same as building being cheap overall. Maintenance, governance, security, and the slow accumulation of technical debt are all still very much your problem once you own the code.
But the finance story is more complicated than "we move from OPEX to CAPEX and our balance sheet looks better." The accounting rules limit what you can capitalise, require you to be honest about how long the software will last, and push most of the ongoing iteration work back through the P&L anyway. BNZ's $253 million hit is a reminder that companies which were generous with their useful life assumptions are now facing a reckoning.
The companies I would watch most carefully are the ones building a lot of internal software with AI tools while also preparing for a sale or a public listing. The incentive to be optimistic about useful lives and aggressive about what gets capitalised is real, and the consequences of getting it wrong tend to show up on someone else's watch. The disclosures are there if you look for them. The useful life assumptions are in the intangible assets note of the financial statements. Worth a read before you trust the EBITDA headline.
Anyway. Not professional advice. Just something that got me thinking.