Verify Supplier NZBN Before Paying an Invoice (NZ Workflow)

To verify a supplier NZBN before paying an invoice in New Zealand, run three checks on the NZBN Register: the NZBN is active and registered to a real entity, the supplier is GST-registered if GST is charged on the invoice, and the entity name or recorded trade name matches the name on the invoice. For one-off lookups, nzbn.govt.nz is the public web search; for a supplier master with hundreds or thousands of NZBNs, the free NZBN Register API runs the same checks as a quarterly batch. NZBN verification authenticates the supplier's tax and business identity. It does not authenticate the supplier's bank-account details on the remittance line, which is a separate fraud-control layer.

Most coverage of the NZBN treats it as a single binary lookup: paste the number, see whether it resolves, move on. That is a starting point, not a control. Each of the three checks has a distinct failure mode and a distinct response. The active-entity check fails when the NZBN has been struck off, deregistered, or never issued. The GST-registration check fails when the supplier is charging GST without being registered, or when the supply date sits before the GST registration start date. The name-match check fails when the trading name on the invoice has no counterpart on the register. Merged into one lookup, the failures blur together; run as three checks, each one points at a specific action.

The discipline of running the three checks together — and treating their results as separate signals — is what turns NZBN lookup into a pre-payment AP control rather than a habit one person performs from memory. It also means that when GST registration moves, when a trade name changes, or when an entity is wound up between supplier onboarding and the next invoice, the AP team catches it instead of paying through it.

NZBN vs Companies Office number, and why the supplier master keys on NZBN

The NZBN and the Companies Office (Companies Register) number are not interchangeable. The NZBN is the universal identifier issued to every kind of entity that does business in New Zealand — sole traders, partnerships, companies, trusts, incorporated societies, and bodies corporate all carry one. The Companies Register number, by contrast, only exists for companies. An AP supplier master keyed on the company number works for some suppliers and silently fails for the rest; a supplier master keyed on NZBN gives you one field that fits every supplier regardless of structure, and one identifier to verify.

A second confusion worth clearing now: the NZBN Register, not IRD, is the practical surface for verifying GST registration status. New Zealand does not issue a formal GST-registration certificate, so there is no document to ask the supplier for. The NZBN record carries the GST registration data, and that is where the GST check in this workflow is run.

Check 1 — the NZBN is active and registered to a real entity

Open nzbn.govt.nz, paste the 13-digit NZBN from the invoice into the search field, and read the entity record that comes back. The fields you care about for this check sit at the top of the result: the entity's legal name, its entity type, and its current status. A check that stops at "the number resolved" is not enough; the status field is the part that matters.

Three patterns turn up in practice, and each one calls for a different response:

• Active entity returned, details aligned with the supplier you expect. First check passed. Move to the GST check.
• NZBN resolves, but the status reads inactive, deregistered, struck off, or removed. Hold the payment. The supplier may be operating with a stale NZBN — they have wound up an entity, restructured, or moved to a new identifier, and the invoice has been issued under the old one. It may also mean the entity was always unrelated to the supplier you thought you were paying.
• NZBN does not resolve at all. A typo, a fabricated number, or a number that was never issued. Hold the payment. Confirm the supplier's actual NZBN through a channel you trust — a phone number you already have on file, an email thread that predates the invoice, a contract — rather than a number on the document under question.

Save a PDF or timestamped screenshot of the search result against the supplier record. The saved register page is your evidence that the check ran, and ran on the date the payment was approved. If the supplier disputes the hold or a regulator later asks how the supplier was vetted, the saved record is the answer.

An inactive NZBN does not, on its own, prove fraud. Suppliers reorganise, dissolve old entities, and start trading under new ones for ordinary commercial reasons; sometimes the AP team simply needs the supplier's current NZBN. Either way, the action is the same: hold, confirm through a known channel, document the result.

Check 2 — the supplier is GST-registered when GST appears on the invoice

If GST sits on a New Zealand supplier invoice, the supplier needs to be GST-registered for the GST charged to be claimable as input tax. The NZBN Register is where that gets checked. Following the NZBN Register's expansion of Primary Business Data to include GST numbers in April 2019, GST registration status is visible alongside the NZBN itself, which is what makes the GST status check possible without ringing IRD or asking the supplier for a non-existent certificate.

On the entity record, locate the GST registration field. If the supplier is currently GST-registered, the field shows the GST number and the registration start date (and, where applicable, an end date). If the field is empty or shows that registration has ended, and the invoice nevertheless charges GST, the GST line is not claimable. Hold and query before paying.

The check that the SERP largely skips is the date one. When matching the NZBN to GST registration before paying the supplier, read the dates carefully: if the supply date on the invoice predates the supplier's GST registration start date, the GST charged on that supply is not claimable as input tax, even if the supplier is GST-registered now. The rule is simple enough to write on a sticky note above the AP screen — the supplier must have been registered for GST on the date of supply, not just on the date the invoice arrived. Suppliers occasionally cross the GST registration threshold mid-period, register going forward, and then issue an invoice for earlier work that incorrectly carries GST. The NZBN Register surfaces the dates that catch this.

The GST check assumes the document in front of you is a valid New Zealand tax invoice in the first place. The post-April-2023 rules use the term taxable supply information rather than tax invoice, and the fields the document needs to carry differ slightly from the older form. If those fields are missing, the input-tax claim is at risk regardless of GST registration status — that is a separate piece of the puzzle, covered in what fields a NZ taxable supply information document must carry.

One boundary case worth naming. If the supplier is a non-resident charging for imported services, the GST workflow inverts: the New Zealand recipient accounts for the GST under the reverse-charge mechanism, and the supplier's GST registration status on the NZBN Register is no longer the determining check. That workflow has its own article — GST reverse charge for non-resident supplier invoices in NZ — and is not the same as the supplier-side GST registration check this section walks.

Check 3 — the registered entity or trade name matches the invoice

The NZBN record carries the supplier's legal entity name and any trade names the entity has registered with the NZBN Register. The third check is straightforward: the trading name on the invoice should match one of those names. Where it does, the supplier's identity is consistent with what the register holds. Where it does not, you have a question to answer before payment.

The most common legitimate pattern is a supplier whose legal entity name and trading name genuinely differ. A company called Mainland Logistics Limited might trade as "Mainland Freight" — the limited-company name appears in contracts and on the Companies Register, and the trade name appears on the website, the truck livery, and the invoice. As long as both names appear on the NZBN record, the match is clean. The supplier master should record both names against the NZBN so the same name-mismatch question does not surface every time an invoice arrives. A note on the supplier record — legal name X, trade name Y, both registered against NZBN Z — saves the next AP person from running the disambiguation again.

The patterns that should not pass:

• A name on the invoice that matches neither the legal entity name nor any trade name on the NZBN record. The NZBN belongs to a different business, or the invoice has been issued by someone with no connection to the entity that holds the NZBN.
• A sudden change in the trading name on a known supplier's invoice, with no corresponding update on the NZBN record. Suppliers do rebrand, but a rebrand will normally show up on the register; an invoice-only change suggests the change is happening somewhere other than the supplier's actual operations.
• A small character-substitution variation on a familiar name — Mainland Frieght instead of Mainland Freight, or a homoglyph swap that is hard to notice at a glance. This is the typosquat pattern that business email compromise plays on, and it survives a casual visual check while failing a register match.

In each of the three cases, the response is the same: hold, confirm through a known channel, and document. Avoid the temptation to "correct" the supplier master to match the invoice — that swaps the integrity of your master data for the integrity of a document you are still vetting.

The control here is structural rather than visual. Match against register data, not against memory of what the supplier "usually" looks like. A consistent process catches the unusual cases that visual checking misses, and the unusual cases are where the value of the control sits.

---

Running the three checks at scale — the NZBN Register API

A supplier master with a few dozen NZBNs can be checked by hand. A supplier master with several hundred or several thousand cannot — and the cases the AP team most needs to catch are the ones that change between supplier onboarding and the next invoice, not the ones present at onboarding. For that, the NZBN Register exposes a free public API, and a quarterly batch over the supplier master is the workflow that scales.

The use case is straightforward. Take every NZBN in the supplier master, send each one to the NZBN Register API, compare the response to what was recorded the last time the check ran, and produce a delta — suppliers whose entity status has gone inactive, suppliers who have deregistered for GST, suppliers whose trade names have changed, suppliers whose registered details have been updated. The AP team works through the delta, not the whole master. At a quarterly cadence, the delta on a master of two thousand suppliers is usually small enough for one person to triage in an afternoon. That is bulk NZBN verification supplier list work in the form an AP function can actually run.

The API itself returns the same data the web search surfaces — entity status, the legal entity name and any registered trade names, GST registration status with effective dates, the entity type, the registered office. Authentication, rate limits, and the JSON response shape are documented at portal.api.business.govt.nz. An internal developer can read those docs and build a batch script in a day; the input is a list of NZBNs from the supplier master, the output is a structured comparison against the previous run. As a finance manager, the brief you give a developer is short: source list, cadence, output format, change-detection logic.

The API does not change the three checks; it scales them. A batch run flags suppliers that have failed one or more checks since the last run, and the AP team works through the list applying the same hold, confirm, document discipline as for one-off lookups. Automation here, in the AP-team sense, means the lookup is mechanical and the judgement still sits with a person.

For organisations without an internal developer to run the script, the practical paths are a contractor engagement (a few days of work, then a scheduled job somewhere in the existing infrastructure), an integration vendor whose product already covers NZBN Register polling, or an extraction-and-matching tool that captures the NZBN from incoming invoices and runs the register check as part of supplier-master maintenance.

What Xero NZ, MYOB NZ, and your AP system actually do — and the gap they leave

Xero NZ has an NZBN field on the contact record. MYOB NZ similarly captures the NZBN on the supplier record. Most other AP-adjacent tools the New Zealand market uses — Dext, Hubdoc, Lightyear, Approval Max — either capture the NZBN or pass it through from whatever does. NZBN verification Xero NZ and NZBN verification MYOB NZ both return the same answer when you look closely: the NZBN field is data storage, not a control. Neither platform queries the NZBN Register at the moment of payment release to confirm that the NZBN is still active, that GST registration is still in place, or that the name on the bill matches the register.

That gap is wider than most AP teams notice, because the NZBN field looks like a control even when it is not. A supplier was onboarded a year ago; their NZBN was valid then; the field has carried it ever since; the bill that arrived this morning carries the same NZBN; the system shows green. None of that says the entity is still active. None of it says the supplier is still GST-registered. None of it says the trading name on the bill still matches what the register holds. The check that closes the gap has to come from somewhere else.

The options, in increasing order of automation:

• Manual lookup at supplier onboarding and on the first invoice. The minimum viable control. A supplier is added; an AP person runs the three checks against the NZBN Register; the result is recorded against the supplier. The first invoice is held until the check is complete. This catches the worst cases at the point of entry but does nothing about changes after onboarding.
• Quarterly manual batch. An AP person works through the supplier master each quarter, running each NZBN against the web register, and updates the supplier record with anything that has changed. Workable up to perhaps a hundred or two suppliers; impractical at higher volumes.
• Quarterly programmatic batch using the NZBN Register API. The pattern from the previous section. Internal developer or external contractor builds the batch; the AP team works the delta. This is the cadence most NZ finance functions can actually maintain at scale.
• Extraction and matching as part of invoice processing. The NZBN, the legal entity name, and the trading name on each incoming invoice are extracted up front, matched against the supplier master, and (where the toolchain supports it) checked against the NZBN Register. Discrepancies are surfaced before the invoice reaches payment approval rather than after.

The product behind this article, NZBN extraction and supplier-name matching for AP teams, sits in the last of those options. Invoices — PDFs, scans, photos — are uploaded to the workbench with a prompt describing what to extract; the output is a structured spreadsheet that includes the NZBN, the legal entity name, the trading name, the GST number, and any other supplier fields the AP team specifies. That structured output is what the AP team matches against the supplier master and against the NZBN Register. The product extracts and structures the supplier-identity data on every incoming invoice; the register check itself still runs on the NZBN Register, and the matching step still runs in the AP system or a workbook the team controls. The contribution is that the input to the match is reliable across thousands of invoices in different layouts, not that the product replaces the check.

For AP teams that also handle Australian supplier invoices, the same shape applies on the other side of the Tasman — the gap, the staged options, the role of extraction and matching. The equivalent ABN verification workflow for Australian supplier invoices covers that side.

NZBN as the 2027 Peppol participant identifier

The NZBN is also the participant identifier that PINT A-NZ — the New Zealand and Australian profile of the Peppol eInvoicing standard — uses to identify a business on the network. From 2027, large New Zealand suppliers will be required to invoice government agencies through Peppol, and on the receiving side that means inbound invoices arrive identified by the supplier's NZBN rather than (or alongside) a name and a tax number on a PDF. Peppol participant identifier NZBN AP work is the same NZBN handling the rest of this article describes, with the difference that the identifier is now the primary key for routing, not just a field on a document.

What that means for the AP team running the three-check workflow today is operational. NZBNs that are clean, current, and matched in the supplier master now will line up against incoming Peppol identifiers without remediation later; NZBNs that are missing, inactive, or mismatched will surface as routing failures or incorrect supplier matching when the eInvoicing transition reaches you. The three-check workflow is not just a current AP control. It is the data-quality discipline that makes the eInvoicing transition something you turn on rather than something you have to clean up first.

Scope boundaries and what to do when a check fails

Fraud prevention through NZBN verification has a specific scope, and the scope is worth being explicit about. NZBN verification authenticates the supplier's tax and business identity. It does not authenticate the supplier's bank-account details on the remittance line. A genuine, active, GST-registered, name-matched NZBN does not protect against payment redirection — the pattern where a fraudster intercepts or impersonates a supplier and changes the bank-account number on what is otherwise a legitimate-looking invoice. The three checks return green; the money goes to the wrong account.

Bank-detail verification is a separate fraud-control layer with its own steps. Callback to a phone number you already hold in the supplier file rather than a number printed on the invoice. Separation of duties on supplier change-of-details, so the person who updates the bank account is not the same person who approves the next payment. Dual approval on the first payment to a new account, and a small test transfer with confirmation back through a known channel before the full payment goes out. None of that runs through the NZBN Register, and none of it is what these three checks are for. Naming the boundary is what keeps NZBN verification an honest control rather than a false reassurance.

The scope discipline applies across other supplier-payment workflows too. Paying a New Zealand contractor under the schedular-withholding regime is not the same workflow as paying a GST-registered supplier; it has its own identity check (an IR330C declaration), its own withholding calculation, and its own remittance to IRD. AP workflow for paying NZ contractors with schedular withholding covers that workflow in full. Trying to fold contractor payments into the NZBN-verification workflow blurs both controls.

When one of the three checks fails, the response is concrete rather than improvised. In order:

1. Hold the payment in the AP system. The invoice does not progress to payment until the check is resolved. This is a system action, not a mental note.
2. Document the specific check that failed against the supplier record. NZBN inactive, GST not registered, GST registration starts after the supply date, name mismatch — write down which one, and write down what the register showed at the time. The next person who looks at this supplier should not have to re-do the work.
3. Request the corrected information from the supplier through a known channel. A current correct NZBN if the one on the invoice was wrong; a corrected taxable supply information document if the GST issue is fixable; evidence of the registered trade name or the legal entity behind it if the names do not match. The phrase "known channel" matters — a phone number you already have, an email address from an earlier exchange, a contact who was not introduced through the disputed invoice.
4. Escalate to compliance or fraud review where the pattern is more than a clerical error. A supplier who cannot produce a valid NZBN, or whose responses do not reconcile with what the register holds, is no longer in normal AP territory.

The three checks are concrete, repeatable, and documentable. The remediation steps are concrete, repeatable, and documentable. Together they form an auditable supplier-payment control rather than a habit one person performs from memory — which is what makes this the workflow worth running rather than a single lookup the AP team eventually drops.