Verify a Supplier's ABN Before Paying an Invoice (Australia)

A supplier invoice arrives with an ABN printed on it. Before payment is approved, three things on that ABN need to check out: (1) it was active on the date of supply, (2) the supplier was GST-registered for that period if GST is on the invoice, and (3) a name on the ABN record matches the trading name shown. To verify a supplier's ABN before paying an invoice in Australia is to run those three checks deliberately, in that order, against the Australian Business Register's records — not to glance at the lookup page and tick a box.

The Australian Business Register's free public tool, ABN Lookup, surfaces every data point those three checks rely on: status with effective dates, GST registration with effective dates, the entity's legal name, and any ASIC-registered business names attached to the ABN. For a one-off invoice, the public page is enough. For a supplier master holding hundreds or thousands of ABNs, the ABR also publishes web services — an API behind the same data — that lets the same checks run on a scheduled batch sweep rather than one supplier at a time.

One scope note up front. This article assumes an ABN has been quoted on the invoice and the question is whether to trust it. The case where no ABN is quoted at all is a different workflow with a different statutory consequence, and that is Australia's 47% no-ABN withholding rule — covered separately. From here on, the ABN is on the invoice; the three checks decide whether the invoice is safe to pay against.

Check 1 — ABN Active at the Date of Supply

ABN Lookup returns a status — Active or Cancelled — with effective-from and effective-to dates marking each status period. The relevant date for this check is the date the supply was actually made, as recorded on the invoice. Not the date the invoice arrived in your inbox, not the date payment is being processed, and not today's date. An ABN that was active on the day goods were delivered or services rendered is valid for that supply, even if it has been cancelled by the time the invoice clears the AP queue.

The practical fail case isn't the supplier whose ABN was cancelled last week. It's the supplier whose ABN was cancelled six months ago and is still issuing invoices — sometimes from a phoenix arrangement, sometimes from a sole trader who let the registration lapse and didn't notice, sometimes from a former employee invoicing under an entity that has been wound up. The supply-date frame is what catches them: when ABN Lookup shows the cancellation effective-to date earlier than the supply date on the invoice, the check fails.

The lookup mechanic itself is direct. Enter the ABN on the public page, read the status block and the effective dates, compare to the supply date shown on the invoice. Cancelled with an effective-to date earlier than the supply date is a fail. Active across the period covering the supply date is a pass. Active now but with a Cancelled period that includes the supply date — historical cancellation, subsequent reactivation — also fails for that supply, even though the ABN is current today. The test is whether the ABN was active for the period covering the supply date, which is not always the same question as whether it is active right now.

Check 2 — GST Registration When GST Is Charged

If the invoice charges GST, the supplier must have been registered for GST for the period covering the supply date for that GST to be claimable as an input tax credit. ABN Lookup carries the GST registration status alongside its own effective dates, and those dates are what this check actually rests on.

The case bookkeepers most regularly miss is the registration-effective-date mismatch. ABN Lookup shows the supplier is registered for GST today, the GST line on the invoice looks fine at a glance, and the invoice is processed. Then the supply date turns out to predate the GST registration effective date — the supplier wasn't registered for GST when the supply was made — and the GST charged on that invoice is not claimable, regardless of the supplier's status now. ABN Lookup surfaces the GST registration effective date specifically so this check can be made; the workflow step is to compare it against the supply date the same way the active-status check does.

The mirror case is more obvious: an invoice charges GST, ABN Lookup shows the supplier is not registered for GST at all. The GST line on that invoice is invalid; nothing is claimable. The supplier may be billing in error, may be misunderstanding their own registration status, or may be charging GST they aren't entitled to charge. Either way, this is not an input tax credit waiting to happen.

When the invoice doesn't charge GST, the registration check shifts from a blocker to a sanity check. A supplier may genuinely sit below the $75,000 turnover threshold for compulsory registration, or the supply may be GST-free or input-taxed by its nature. ABN Lookup confirming the supplier is unregistered is consistent with all of those. The step still earns a moment because the no-GST case can also be a misclassification — a supplier who should be registered, isn't, and is invoicing without GST as a result.

Ongoing or staged supplies that bridge a GST registration boundary are the awkward edge. A consulting engagement that ran across a registration date, a maintenance contract billed quarterly through a year that started before registration and ended after — the work doesn't divide cleanly into a single supply date. The right move is to split the invoice between the unregistered period (no claimable GST) and the registered period (GST claimable on the in-window portion), rather than letting a single invoice claim GST against work performed before the supplier was entitled to charge it.

Check 3 — Entity Name and Trading Name Match

ABN Lookup carries two name fields, and both matter. The entity name is the legal name attached to the ABN — typically a company name like "JOHN SMITH PTY LTD" or, for a sole trader, the individual's legal name. The registered business names are the public-facing trading names the entity has registered through ASIC against this ABN — for the same example, that might be "Smith Plumbing" or several others. The ABR administers ABNs and entity names; ASIC administers business names; ABN Lookup pulls both into one view, which is the convenience that makes this check practical without querying two registers separately. The trading name on the supplier invoice can match either form, or sometimes a near-variant of either.

The matching rule is straightforward in shape: the trading name on the invoice should match the entity name or a current registered business name shown against the ABN. If neither matches, the check fails and warrants follow-up before payment.

What looks like a mismatch but isn't is common enough that the rule has to recognise it. Minor capitalisation and punctuation differences — PTY LTD on the register, Pty Ltd on the invoice, Pty. Ltd. on the letterhead — are not failures. The same entity legitimately trades under one of several registered business names, and any of those names appearing on the invoice is a match against the ABN record. Sole traders frequently invoice under a registered business name that bears no resemblance to their legal name, and that's exactly what registered business names exist for. None of those cases is a fail; none warrants holding payment.

What does warrant holding payment is the cleaner failure mode. The invoice carries a name that doesn't appear as the entity name and doesn't appear among the current registered business names on the ABN — it's not a formatting variant, it's a different name entirely. Or the ABN exists and is active, but is registered to a completely unrelated entity (the ABN was real; the name on the invoice was made up). Or the invoice is using a business name that was once registered against the ABN but has since lapsed or been cancelled — the name was legitimate at one point and the supplier is operating off old letterhead, or someone is using a stale public-record entry. Each of those failure shapes is worth a verification call before the invoice gets paid.

This is also where the ABN-impersonation pattern lives. Someone invents a supplier identity, copies a real and active ABN off the public register, and issues an invoice carrying that ABN under a name they made up. The first two checks pass cleanly: the ABN is active, the GST registration is current. The third check is where the impersonation surfaces — the made-up name doesn't match the entity name on the ABN and doesn't appear in its registered business names. AP doesn't need a fraud-detection capability to catch this; the third check is the catch.

---

Verifying ABNs in Bulk Across the Supplier Master

Running the three checks one ABN at a time on the public ABN Lookup page is fine for the invoice in front of you. It does not scale to a supplier master holding several hundred — let alone several thousand — active records. ABNs cancel between manual checks, GST registrations lapse, business names get deregistered, and none of those changes ping the supplier-master file by themselves. Without a scheduled refresh, status drift accumulates silently and surfaces at audit, or worse, on a payment that should have been held.

The ABR addresses this by publishing the same data behind a free API. ABR's ABN Lookup web services is free to use and is authenticated with a GUID (Globally Unique Identifier) issued on registration. The same status, GST registration, and entity-name data the public page surfaces is available to a registered caller in machine-readable form, in either JSON or XML.

The workflow shape sits at the level a finance manager or senior bookkeeper can hand off to a developer or evaluate against an existing tool, rather than build from first principles. Register for a GUID through the ABR's web services portal. Send the supplier master's ABNs through the API in batched calls — typical implementations process the list in chunks rather than one record per request. Parse the returned status, GST-registration status, GST-registration effective date, and current registered business names per ABN. Compare each of those fields to what's currently held against the supplier in the master file, and flag anything that has changed since the last sweep — a status change to Cancelled, a GST registration that has lapsed, a registered business name that has been deregistered. The flagged records become the work queue for whoever is responsible for the supplier master.

A quarterly cadence is a sensible default for a stable supplier base. Tighter cadence — monthly, or weekly for a high-risk subset — suits high-turnover suppliers, recently onboarded suppliers, or supplier categories that have historically produced more verification problems. New-supplier onboarding adds a separate one-off check the moment a record is created: running the three checks at intake catches a name mismatch or a cancelled ABN before the supplier's first invoice is even issued, which is materially cheaper than discovering the same mismatch six invoices in.

This is the natural point to acknowledge where the ABN data on each invoice originates in an automated AP pipeline. In a manual workflow, the ABN is read off the supplier invoice by an AP clerk and typed into ABN Lookup. In an automated pipeline, automated invoice data extraction converts the supplier invoice into a structured record before any verification step runs — the ABN, supply date, GST amount, and trading name come out of the document as named fields rather than being re-keyed from a PDF by hand. The verification gate then operates on structured data: a value extracted from the invoice is compared to a value returned by the API, and the comparison is what triggers a hold or a release.

A scope note: the description above is the workflow, not the code. An AP team running this themselves either commissions the integration from a developer or uses a tool that already wraps the ABR API and surfaces the diff against the supplier master in a usable form — the article is not a developer tutorial. The same scheduled-check-against-a-public-registry pattern turns up in other jurisdictions too — the Japan T-number supplier verification workflow is one example, the Canadian equivalent for confirming supplier GST/HST registration against the CRA registry is another, the trans-Tasman counterpart for verifying a supplier's NZBN before paying an NZ invoice follows the same three-check shape against the NZBN Register, and the Singapore equivalent for checking a supplier's UEN and GST registration via BizFile and the IRAS GST register applies the same supply-date discipline to the UEN/GST pair — which matters for AP teams handling suppliers in more than one country.

ABN Verification in Xero and MYOB

The two accounting platforms most AU SMBs run their AP through both treat the ABN as a contact-level field and neither hard-enforces it at pay time. Knowing exactly where each platform's coverage stops is what tells you what the gap-filling workflow has to look like in your own stack.

Xero's contact record carries an ABN field on every supplier. The value gets entered when the contact is created, often validated for format at that point, and is then used to populate the ABN on bills and remittances. What Xero AU doesn't do is re-check that ABN's status against the ABR on any ongoing basis, or block a payment to a supplier whose ABN has been cancelled since the contact was set up. The verification at supplier creation is essentially a one-shot field — and once it's set, keeping it accurate over time falls on whoever owns the contact list. Xero's community has carried an open feature request for native ABN status checking for years; the gap is well-known.

MYOB sits one step further along: supplier records carry an ABN status indicator that surfaces in-product, typically rendered as a colour-coded cue (commonly described as a green-or-orange signal) tied to the current ABN status. The indicator is genuinely useful — it puts a current-status flag in front of the user at the moment they're looking at the supplier record. What MYOB doesn't do is enforce the supply-date version of the active check, the GST-registration-effective-date check, or the entity- and business-name match. AP still owns the workflow decision; the indicator is a prompt, not a control.

The implication is the same in either platform. The supplier master needs a refresh that lives outside what the platform does natively — manual one-by-one for a small list, scripted against the ABR API for a larger one — with the platform's contact field updated when status, GST registration, or registered names change. Onboarding triggers a check at supplier creation; ongoing checks are scheduled, not platform-triggered.

Third-party AP tools sit in the gap. Document-capture platforms, AP automation layers, and spend-management products that sit between invoice intake and the accounting platform can run ABN verification at intake and reconcile the result against the supplier master before the bill ever lands in Xero or MYOB. Whether to use one is a procurement question, not a verification question — the workflow described in this article runs whether a tool wraps it or a person does. Naming any specific vendor here would be a recommendation the article isn't qualified to make.

---

When a Check Fails — The Remediation Path

Each of the three checks has its own remediation. Treating "ABN verification failed" as one event with one response is what produces the generic "withhold and chase" reflex; the actual workflow has four distinct branches.

Cancelled ABN at the supply date. Hold payment. Contact the supplier for an explanation and request a reissued tax invoice carrying a current, active ABN. If the supplier confirms they no longer hold an ABN at all, the case has shifted out of ABN verification and into the no-ABN withholding workflow — that's where the standing cross-link in the opening section sends you, and re-walking it here would just duplicate that article.

Not GST-registered when GST is charged. Hold payment. Request a corrected invoice with the GST removed, or evidence (a registration letter, a confirmation of an effective date that ABN Lookup hasn't yet reflected) that the supplier was in fact registered for GST covering the supply date. Do not claim the GST as an input tax credit on the basis of the invoice as issued — claiming GST that the supplier wasn't entitled to charge is the bookkeeping error that creates the audit problem.

GST registration is current but didn't cover the supply date. This is the registration-effective-date mismatch case from check two — the supplier is GST-registered now, but the supply happened before the registration effective date. The remediation depends on the shape of the supply. For a single one-off supply that pre-dates registration entirely, the supplier was not entitled to charge GST on it; request a corrected invoice without the GST line. For a supply that genuinely straddled the registration date — an ongoing service, a staged delivery — the corrected invoice should split the supply, with the in-window portion carrying claimable GST and the out-of-window portion not.

Name mismatch. Don't auto-reject. The first move is to re-check the ABN record on ABN Lookup specifically for current registered business names — legitimate trading-name use under a registered business name is common, and a name that doesn't match the entity name will frequently match a registered business name attached to the same ABN. If no name on the record matches the trading name on the invoice, request a clarifying tax invoice that shows the correct entity name or a registered business name. The full picture of what a corrected invoice has to contain — ABN, supplier identity, supply date, GST treatment, the recipient details, the rest — is set out in the Australian tax invoice field requirements, which is the right reference for AP when issuing the supplier-side request.

A single failure of any kind from a known supplier is, almost always, a data-quality problem — the supplier didn't update their ABN after a change, the AP record holds an old name, the GST registration lapsed and was re-instated and the timing is awkward. The right response is the targeted remediation above. A pattern is different. Repeat failures from the same supplier, failures across multiple suppliers that fit a known impersonation profile, or failures that surface alongside other anomalies (changes to bank details, urgent payment requests, mismatched email domains) belong with internal compliance or fraud review, not with the standard supplier query channel. One failure is a control producing a useful signal; a pattern is the signal worth acting on at a higher level.

---

ABN Verification Is One Layer — What It Doesn't Authenticate

What ABN verification authenticates is the supplier's tax identity — that the entity quoting the ABN exists, was active at the supply date, was GST-registered for that period when GST is being charged, and is named on the invoice consistently with the public record. What it does not authenticate is the bank account on the invoice. That is a separate layer with its own controls, and conflating the two is how supplier-fraud losses keep happening at organisations that genuinely do verify ABNs.

The gap is concrete enough to walk through. A fraudulent invoice can carry a real ABN — copied directly off the public register, which is built to be public and is not a defence against being copied — combined with the correct entity name for that ABN, an active status, current GST registration, and a perfectly clean three-check pass. The invoice routes payment to a bank account belonging to whoever sent the invoice, which has nothing to do with the supplier whose ABN is on it. Every check in this article passes; the money still goes to the wrong place.

Bank-detail verification is the other layer, and it has its own established controls. PayID name lookup, on payment rails that support it, returns the registered name attached to the receiving account so a mismatch between the supplier's invoiced name and the account name surfaces before the payment is released. A callback to a known supplier phone number — one already on file in the supplier master, not one supplied in the suspect email or invoice — confirms a change-of-banking-details request was actually initiated by the supplier rather than by an attacker who has compromised the supplier's email. Explicit supplier change-of-details controls — written requests, dual approval inside AP, mandatory callback before any update is made — close the standing exposure that lets bank details be changed silently in the supplier master.

Business email compromise sits behind a meaningful share of AU SMB AP losses, and the practitioner instinct that "we need to verify suppliers more carefully" is correct. The discipline this article holds is to name what each control actually does. ABN verification is a real control on supplier-tax-identity, not a marketing umbrella. Bank-detail verification is a different control on payment routing. Each catches a class of failure the other doesn't. Treating them as one product is what produces the false sense of cover that attackers exploit.

The shape of pre-payment supplier-authenticity verification is recognisable across borders. Poland's White List pre-payment supplier check sits at the intersection of supplier identity and a payment-routing control, requiring suppliers' bank accounts to appear on a published register before payment carries the standard VAT consequences — a different mechanism, the same underlying instinct that the verification step belongs before the payment runs. Treating ABN verification as Australia's instance of that broader category, rather than as a uniquely local control, is how it ends up sitting alongside the other layers properly rather than carrying the entire weight of supplier authenticity on its own.