Why Australian ERPs Keep Failing New Zealand Businesses

We have spent a lot of time this year migrating New Zealand businesses off platforms that were never really designed for them. The platforms are technically capable. The problem is elsewhere.

TL;DR: New Zealand small-and-medium businesses think, quote, and invoice in GST-inclusive amounts. Xero does this natively. Most Australian-origin cloud ERPs do not, they force tax-exclusive entry and compute the tax on top. This mismatch is not a rounding error. It is the difference between a finance team trusting the system and spending half their week reconciling workarounds. We recently closed this gap in NexWave, an ERP we maintain for NZ and AU businesses. Here is what we learned along the way, and why we think this is a genuinely underrated reason NZ businesses get stuck on the wrong platform.

---

The Part That Does Not Show Up in Demos

Cloud ERP demos are good. Someone walks you through a sales invoice, shows you the dashboards, shows you the inventory module, shows you the bank reconciliation. You nod. It looks powerful. You sign up.

Six weeks into implementation, your accounts team quietly asks you a question: “why do we have to enter prices exclusive of tax? We’ve always worked inclusive.”

You ask the implementation partner. They shrug. “That’s how the system works.” Your accountant is now mentally translating every price from inclusive (how your sales team quotes them) to exclusive (how the system stores them), on every single transaction. The mental overhead is small per transaction. Multiplied across two hundred invoices a month, it is the thing that makes them dislike the new system.

This is not unique to any one platform. It is endemic to ERPs built for markets that default to tax-exclusive pricing, which means most of them. Australian platforms are generally tax-exclusive. British platforms split between the two. American platforms often do not handle consumption tax at all in any sensible way.

New Zealand is different. NZ businesses almost universally quote, price, and sell in GST-inclusive terms. Even the receipts on your coffee and your lunch show you the inclusive price first.

Why This Matters More Than It Should

Consider a furniture retailer. They have a showroom. Prices are on swing tags. The tag says $1,150. A customer pays, the sales staff enter the transaction, and the system asks for the unit price. Do they enter $1,150 or $1,000?

On Xero, it does not matter. Xero lets them toggle “Amounts are: Tax Inclusive” or “Tax Exclusive” per invoice, with a sensible per-organisation default. The inclusive price is the natural input and Xero stores both. No cognitive load.

On most other ERPs, the answer is “enter the unit price tax-exclusive, the system will add GST.” That means the sales staff, who have the swing tag in their hand reading $1,150, now have to do mental arithmetic: 1,150 / 1.15 = 1,000. Then re-enter it. Every line. Every transaction.

The sales staff will not do this. They will enter 1,150. The accountant will find out at month-end when GST returns do not reconcile. There will be a manual fix. Then another. Then an Excel spreadsheet. Then a growing sense that the ERP is not really doing its job.

This is the friction that drives NZ businesses back to Xero after expensive ERP implementations. Not missing features. Not bad reporting. This small, structural mismatch between how the business thinks and how the software requires you to think.

The Journal Entry Problem, Which Is Worse

Invoices are the visible case. Journal entries are worse.

A bookkeeper in New Zealand recording a manual correction often works from a bank statement or a receipt. They know the total amount (inclusive) and the GST rate, and they need to split the entry into its net and GST components. On Xero, the bookkeeper can enter the gross amount, tick an inclusive flag, and Xero computes the GST line automatically.

On a tax-exclusive ERP, they cannot. They have to compute the GST themselves (gross ÷ 1.15 × 0.15), enter the net line, enter the GST line, make sure both sides balance, and pick the right GST account for the correction. The maths is not hard but it is mentally taxing, and the error rate on repetitive manual work is higher than anyone wants to admit.

Why Australian ERPs Struggle Here

Australia has GST too, 10% instead of NZ’s 15%, so you might expect Australian ERPs to handle inclusive pricing gracefully. In our experience, they do not. Most default to tax-exclusive, partly because it is easier to calculate tax on top of a net amount than to back-compute it from a gross, and partly because Australian B2B transactions often cite net-of-GST pricing.

But NZ SMBs are not primarily B2B. They are retailers, trades, hospitality, professional services selling direct to end customers. They talk in gross numbers. Their accounting software has to meet them there.

The gap has a second source: tax compliance rules differ. NZ IRD expects GST returns to tie back to specific tax codes and reporting categories that are slightly different from Australian BAS. If the ERP was built to pass BAS cleanly, it did not necessarily get the NZ side right the first time. Every shortcut taken in the early design shows up later when an accountant starts closing GST periods.

What “Getting It Right” Looks Like

We recently rebuilt this end-to-end for NexWave, the NZ/AU ERP we maintain. The design goal was to match Xero’s mental model for anyone who is used to it, without breaking the tax-exclusive workflows that some AU businesses prefer.

The core feature is a per-document “Amounts Are” toggle, Inclusive or Exclusive, on every document where tax matters: Sales Invoices, Purchase Invoices, Sales Orders, Purchase Orders, Quotations. The toggle flows through conversions (Sales Order to Sales Invoice preserves the choice, Purchase Order to Purchase Invoice preserves the choice, returns preserve the choice). There is a per-company default so that businesses that always work inclusive just never have to touch it.

For journal entries, we did something more interesting. Users can set a GST rate per line on a manual JE. When the JE is saved in draft, it balances at gross amounts, the way a bookkeeper would naturally want to see it, matching Xero’s behaviour. When the JE is submitted, the system automatically splits each line into its net and GST components and posts the companion GST rows to the correct account. The account is determined by the line’s root_type, expenses and assets route to GST Paid, income routes to GST Collected.

If that sounds like a lot of machinery for a small feature, that is because a lot was required to make it feel simple. The combined feature went through functional consulting for NZ GST compliance, architecture design for the document flow, 53 test cases covering amend scenarios, multi-currency, manual GST override, orphan cleanup, and three rounds of code review. Half of the cases only exist because real businesses do weird things with returns and amendments.

The Broader Point

We are not writing this to sell NexWave. We are writing it because “your cloud ERP doesn’t handle GST the NZ way” is a surprisingly common reason we see NZ businesses bouncing between platforms.

If you are evaluating an ERP, the test is not “does it compute GST correctly.” Every system does. The test is:

1. Can I enter a sales price inclusive of GST without mental arithmetic?
2. Can I record a manual journal entry from a bank statement (gross) and have the system split it for me?
3. When I convert a quote to an invoice, does my inclusive/exclusive choice travel with it?
4. Does the GST account get picked automatically based on the account I am posting to?
5. Is the workflow natural enough that my non-accountant staff will do it right the first time?

These are the questions that separate “technically GST-capable” from “actually usable in New Zealand.” We have seen too many implementations fail the usability test despite passing the technical one.

What NZ Businesses Actually Need

New Zealand SMBs do not need a more capable ERP. They need an ERP that matches how their business actually operates:

• Inclusive pricing as a first-class citizen. Per-invoice toggle, per-company default, end-to-end flow.
• GST-aware journal entries. Gross input, automatic split, correct account routing.
• NZ bank formats built in. ANZ, ASB, BNZ, Westpac, Kiwibank, not add-ons, not plugins.
• NZ payroll compliance. IRD filing formats, KiwiSaver handling, student loan deductions.
• Xero parity where it matters. If a finance person came from Xero, the conceptual switch should be small.
• NZ IRD GST return tie-back. Every transaction tagged with the right GST code, tied to the right line on the GST return.

None of this is exotic. It is the stuff most NZ businesses assumed was already there when they signed up.

The Bottom Line

The reason NZ businesses churn off ERP platforms is rarely dramatic. It is not that the software does not work. It is that every day, small pieces of friction compound: inclusive prices entered as exclusive, journal entries split by hand, bank feeds that need a plugin to work with ASB, payroll that needs a manual export to IRD.

Cloud ERPs built for other markets can be made to work for NZ. The question is whether they were designed for it. The difference shows up on day 30, not day 1.

If you are running an NZ business and your current ERP keeps asking you to translate how you think into how it thinks, you are not the problem. The software is. We are easy to reach if you would like to talk through alternatives that were built for the way NZ businesses actually operate.

---

About HighFlyer

HighFlyer is an Auckland-based technology company specialising in custom software, AI automation, and ERP implementation for New Zealand businesses. We maintain NexWave, an ERP platform designed for the NZ and AU market, and we build the integrations that connect business systems to Xero, Shopify, WooCommerce, Stripe, and NZ bank feeds.

Learn about our services or get in touch if you want to talk through what “built for New Zealand” actually looks like.