Automating Xero Invoice Processing in New Zealand

Before you scope anything, two things are worth settling, because they decide most of the design and almost nobody states them up front.

The first: Xero already does more of this than most articles admit. A large share of what gets sold as "invoice automation" is a feature you are already paying for, switched off.

The second: approval is not a bottleneck to be automated away. In a New Zealand practice the approval step is where GST treatment, coding and authorisation actually get decided, and the goal of a build is to make that decision fast and well-informed — not to remove it.

Work out what Xero already covers, draw the line where a person signs off, and the remaining build is much smaller and much easier to justify.

Start with what Xero already does

Check each of these before scoping anything, because paying to rebuild them is the most common way money goes missing on this kind of project.

Document capture. Hubdoc pulls bills and receipts in, extracts key fields, and pushes them to Xero with the source document attached. It is included with most Xero business plans. If your proposal’s headline feature is "capture supplier invoices automatically", ask what it adds over this.

Bank rules. Bank rules code recurring transactions on your terms without any third-party tooling.

Approval workflow. Xero has bill and invoice approval built in, with a draft-to-awaiting-approval-to-approved path and permissions behind it.

eInvoicing. This is the one most often missed. New Zealand has a government-backed eInvoicing programme on the Peppol network, where invoice data moves directly between accounting systems instead of being emailed as a PDF and re-keyed at the other end. Inland Revenue explicitly recognises this as a way sellers can provide taxable supply information — see its guidance on how taxable supply information works. If both ends support it, no amount of optical character recognition beats not needing any.

Whatever survives that list is your actual project.

The GST constraint, from primary law

This is a design constraint before it is a compliance question, and getting it from the source matters — most content on this topic restates tax rules from somewhere else, often from another country.

Under the Goods and Services Tax Act 1985, "taxable supply information" is a defined term, and what it must contain varies with the value of the supply. Inland Revenue’s guidance states that taxable supply information must be provided to GST-registered buyers within 28 days of a request, or by an alternative date the parties agree, for supplies over the relevant threshold — see how taxable supply information works.

Two design consequences follow.

The old "tax invoice" framing is out of date. Inland Revenue’s current guidance is that a single physical document is no longer required, and that records such as invoices, bank statements, supplier agreements and contracts can support the figures in a GST return, individually or in combination. A workflow built to hunt for one canonical document per transaction is solving a problem that has moved. What matters is that the required information is held and can be produced.

Thresholds change what must be captured. Because the required content depends on the value of the supply, a capture step that pulls the same fields regardless of value will over-capture on small items and under-capture on large ones. Build the threshold into the extraction rather than discovering it at the end of a quarter.

This is the point at which to say the obvious: this is a description of published guidance, not tax advice. Confirm the treatment for your own practice with your accountant or with Inland Revenue directly, and note that business.govt.nz’s guide to GST is the plainer starting point.

Two New Zealand cases most builds get wrong

These are the two places where a workflow designed against overseas content quietly stops matching New Zealand practice. Both are ordinary here and neither has an equivalent in most of the material you will find on this topic.

Buyer-created taxable supply information

In some trades the buyer raises the document, not the seller — common in primary industry, and anywhere the buyer knows the quantity or grade before the supplier does. Inland Revenue treats this as its own case, buyer-created taxable supply information, and it is recognised in the Goods and Services Tax Act 1985’s definition of the term.

For a build this inverts the direction of travel. Your workflow is not receiving and extracting a document; it is generating one, with your own details as the issuer, from data you hold. Extraction logic is the wrong tool for it, and a design that assumes every document arrives from outside will handle these by failing.

Supply correction information

Credit and debit notes are, in current New Zealand terminology, supply correction information. Inland Revenue’s guidance sets out what buyers and sellers must retain: the seller’s name or trade name and GST number, the date the correction was provided, details identifying the original taxable supply information such as an invoice number, and the correction itself including any change to the tax charged.

The design consequence is the link. A correction is meaningless without the record it corrects, so your workflow needs to carry the reference through — not just file the credit note. Inland Revenue’s guidance is also that supply correction information for a particular supply should only be provided once, though a copy may be supplied if the buyer loses theirs, which is worth knowing before you build anything that re-sends on a schedule.

Where the automation must stop

Draw this line deliberately, on paper, before anything is built. Four places where a person signs off, and the reason in each case is different.

GST treatment on anything non-obvious. Standard-rated, zero-rated, exempt, and imported supplies are not a classification a capture tool should guess at. Route the obvious cases automatically and send the rest to a person — the split itself is the design decision.

Payment authorisation. Approving a bill and paying it are separate acts and should stay separate. An automation that does both has removed the only control that catches a fraudulent invoice, and invoice fraud is convincing precisely because it looks like routine work.

Anything a supplier changed. A new bank account on an existing supplier is the highest-risk event in the whole process. It should stop the workflow and require a human confirmation through a channel other than the email the invoice arrived on.

Anything the extraction was unsure about. Confidence scores exist to be used. A field the model was uncertain about is the field that will be wrong, and routing low-confidence extractions to review is the difference between a workflow that helps and one that quietly corrupts a ledger.

The test for a good design is not how few approvals remain. It is whether each remaining approval is a real decision, presented with everything needed to make it in seconds rather than minutes.

What is actually left to build

After the two sections above, the genuine gaps in most New Zealand practices are narrow and specific.

Getting documents out of the places Hubdoc does not reach. A supplier portal that only issues invoices through a login, a client who sends photographs to a shared mailbox, a system that emails a summary rather than an invoice.

Pushing data into the systems Xero does not integrate with. Practice management, job costing, or an industry system that holds the job number the invoice needs coding against. Xero’s accounting API is the interface; both n8n and Zapier have Xero nodes that speak to it.

Chasing the exceptions. Not chasing invoices — Xero does reminders. Chasing the bills stuck awaiting approval, the extractions sitting in review, the supplier who has not moved to eInvoicing. This is usually the highest-value piece and it is almost never what gets proposed.

Making the failures visible. An automated step fails quietly. Something has to notice and tell a person, with enough context to act. Error handling is not an optional extra on a workflow that touches financial records; a silent failure in a ledger is discovered at the worst possible time, by the worst possible person.

How to scope it without wasting the budget

A sensible order of work.

1. Turn on what you already have. Hubdoc, bank rules, approval permissions. Run it for a full cycle before deciding anything else.
2. Ask your largest suppliers and clients whether they support eInvoicing. Every one that does removes a transaction from the problem entirely.
3. Count what is left, by type, for one month. Not by feeling — by count. This is the specification.
4. Draw the approval line on paper, using the four cases above.
5. Only then scope a build, against the counted exceptions and the drawn line.

Most practices find the answer at step three is far narrower than the one they imagined at step zero. That is the point of doing it in this order: the cheapest automation project is the one the first two steps made unnecessary.

If you want the wider framing, our guide to business process automation in New Zealand covers what these builds involve generally. If you have reached step five and want it built, who to talk to about building n8n workflows in New Zealand covers the three routes, and our automation service is one of them.

Common questions