DEV Community: BitOwl

Australian ABN validation for SaaS developers

BitOwl — Sat, 20 Jun 2026 19:03:00 +0000

Selling to Australian businesses and never heard of ABN? That's fine, most people building global SaaS haven't. But once you have an Australian business customer, they're going to ask for it on the invoice. And if you don't collect it during checkout, you're adding friction later.

Here's the short version:

What is an ABN?

ABN stands for "Australian Business Number". It's an 11-digit identifier issued by the Australian Business Register, and basically every business entity in Australia has one. It goes on invoices. Australian businesses use it to claim GST credits back, so your B2B customers will want to provide it.

Legally, businesses are required to include their ABN on invoices over AUD 82.50. For a SaaS subscription that's pretty much every invoice.

Validating ABN:s

The official path is the ABR lookup API. It's free, but it requires registering for a developer GUID, and the response format is XML. There's also a checksum algorithm specific to ABN's that you'd need to implement for format validation before even hitting the registry.

Skip all of that. I use TaxVett for this:

curl -X POST https://api.taxvett.com/v1/validate \
  -H "X-Api-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"number": "51824753556", "country": "AU"}'

Response:

{
  "valid": true,
  "number": "51824753556",
  "country": "AU",
  "regime": "au_abn",
  "verification_method": "live_registry",
  "company_name": "Apple Pty Ltd"
}

The lookup goes against the live ABR registry, so you get the registered business name back too. This is useful for pre-filling the company name field in your checkout, or displaying "Invoices will be issued to: [company name]" before the customer confirms.

A checkout pattern that works:

Here's how I wire this into a checkout form. The ABN field validates on blur. No submit needed:

// React (works with Next.js, Remix, Astro API routes, etc.)

async function validateABN(abn: string): Promise<{
  valid: boolean;
  companyName?: string;
}> {
  const normalised = abn.replace(/\s/g, "");

  const res = await fetch("/api/validate-abn", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ abn: normalised }),
  });

  return res.json();
}

// In your form component:
function ABNField() {
  const [status, setStatus] = useState<"idle" | "valid" | "invalid">("idle");
  const [companyName, setCompanyName] = useState<string>();

  async function handleBlur(e: React.FocusEvent<HTMLInputElement>) {
    const abn = e.target.value.trim();
    if (!abn) return;

    const result = await validateABN(abn);
    setStatus(result.valid ? "valid" : "invalid");
    setCompanyName(result.companyName);
  }

  return (
    <div>
      <input
        type="text"
        name="abn"
        placeholder="51 824 753 556"
        onBlur={handleBlur}
      />
      {status === "valid" && companyName && (
        <p className="text-sm text-green-600">✓ {companyName}</p>
      )}
      {status === "invalid" && (
        <p className="text-sm text-red-600">
          ABN not found. Check the number and try again.
        </p>
      )}
    </div>
  );
}

The server route that proxies the validation (keeps your API key out of the browser):

// pages/api/validate-abn.ts or app/api/validate-abn/route.ts

export async function POST(req: Request) {
  const { abn } = await req.json();

  const res = await fetch("https://api.taxvett.com/v1/validate", {
    method: "POST",
    headers: {
      "X-Api-Key": process.env.TAXVETT_API_KEY!,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ number: abn, country: "AU" }),
  });

  if (res.status === 422) {
    return Response.json({ valid: false });
  }

  const data = await res.json();
  return Response.json({
    valid: data.valid,
    companyName: data.company_name,
  });
}

ABN format notes

ABNs are 11 digits. They're often written with spaces: 51 824 753 556. Strip spaces before sending. The checksum validation catches a lot of typos before the request even reaches the registry, and the API returns a 422 for those cases so you can show a useful error without burning a lookup.

What about GST registration?

Not every ABN holder is registered for GST. Sole traders under the AUD 75,000 annual revenue threshold don't have to be. The ABR API returns GST status if you need it, but for a global SaaS checkout, validating the ABN is enough. It confirms the business exists and is registered in Australia.

Pros and cons

Pros: free tier covers development and early production (500 req/month), no XML or ABR developer GUID, returns the registered company name which you can show in checkout

Cons: paid at higher volumes (from 9 EUR/month), adds a third-party request to your checkout flow so handle timeouts gracefully

Also works for EU and UK

If you're selling globally, the same endpoint handles UK VAT, all 27 EU member states, Norway and Singapore too. One API key, same response shape. The regime field tells you which registry handled the lookup (au_abn, eu_vat, gb_vat, etc.).

There's a practical comparison of EU VAT validation options and a guide to UK VAT post-Brexit if you need those regions covered too.

GLHF coding

EU VAT validation API's: a practical comparison

BitOwl — Wed, 17 Jun 2026 09:36:00 +0000

At some point in every B2B SaaS project, someone asks: "can we skip tax for EU business customers?". And then you spend a friday afternoon finding out... yes, you can, but you need to validate their VAT numbers first. And that opens a whole thing.

This is what I found, from my experience with VAT number in our global SaaS service.

Option 1: VIES directly

"VIES" is the official EU VAT database. It's run by the European Commission and it's free to use! Those are the good parts.

The bad is that it's a SOAP API from around 2003 and it really shows... You write raw XML, send over HTTP, and parse XML back. Error states come back as HTTP 200:s with fault codes buried in the body. Some member countries return full company names. Others return nothing. Germany is known for returning MS_UNAVAILABLE during regular business hours for no obvious reason.

Here's a minimal request:

curl -s https://ec.europa.eu/taxation_customs/vies/services/checkVatService \
  -H "Content-Type: text/xml" \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ec.europa.eu:taxud:vies:services:checkVat:types">
  <soapenv:Body>
    <urn:checkVat>
      <urn:countryCode>SE</urn:countryCode>
      <urn:vatNumber>556543123401</urn:vatNumber>
    </urn:checkVat>
  </soapenv:Body>
</soapenv:Envelope>'

It works. Just budget time for XML parsing, error handling, and tests for the unavailable-state edge cases.

Pros: free, no rate limits, no third party in the chain
Cons: XML, inconsistent responses per country, no UK support (post-Brexit), needs defensive error handling

Option 2: VatLayer / Abstract API / Vatstack

A bunch of services wrap VIES in a REST API, which solves the XML problem. The docs are good and the responses are consistent.

The catch is that most charge from the very first request. No real free tier. If you're running validations in development and staging too, costs add up before you've even shipped. I also noticed one service routing all lookups through a single US region, which adds unnecessary latency and possible compliance issue for European customers.

Pros: clean REST API, no XML
Cons: cost starts from day one, EU-only coverage on most plans

Option 3: TaxVett

TaxVett is what I ended up using lately. Free lookups every month, no credit card needed, and it covers not just EU but also UK. And for the future there's also Norway, Australia and Singapore in the same API. For our service with companies globally that's is very useful.

The request is simple:

curl -X POST https://api.taxvett.com/v1/validate \
  -H "X-Api-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"number": "SE556543123401"}'

Response:

{
  "valid": true,
  "number": "SE556543123401",
  "country": "SE",
  "regime": "eu_vat",
  "verification_method": "live_registry",
  "company_name": "Acme AB",
  "company_address": "Stockholm, Sweden"
}

Country is auto-detected from the number prefix, so you don't need to pass it unless the format is ambiguous. If VIES is unavailable for a specific country, you get a proper error back in the same JSON shape rather than a silent success.

For UK numbers, it routes to HMRC instead of VIES. There's a separate post on UK VAT validation here if you need that specifically.

Pros: free to start, REST API, consistent response across all countries, covers UK/AU/NO/SG too
Cons: third-party dependency, paid plans kick in at higher volumes (from 9 EUR/month)

How do I integrated in Node.js?

async function validateVatNumber(vatNumber: string): Promise<{
  valid: boolean;
  companyName?: string;
}> {
  const response = await fetch("https://api.taxvett.com/v1/validate", {
    method: "POST",
    headers: {
      "X-Api-Key": process.env.TAXVETT_API_KEY!,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ number: vatNumber }),
  });

  if (!response.ok) {
    // 422 = format invalid, 404 = not found in registry
    return { valid: false };
  }

  const data = await response.json();
  return {
    valid: data.valid,
    companyName: data.company_name,
  };
}

When valid is true, I also prefill the company name in the checkout form. Saves the customer a step and feels polished.

The batch endpoint?

If you need to validate existing customers in bulk, there's also a batch endpoint:

curl -X POST https://api.taxvett.com/v1/validate/batch \
  -H "X-Api-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "numbers": [
      {"number": "SE556543123401"},
      {"number": "DE123456789"},
      {"number": "FR12345678901"}
    ]
  }'

I batch 50 per request. Each one counts against your quota separately, which matters if you're on the free plan.

What to pick?

If you're EU-only and happy with XML and error handling: VIES directly is totally fine and free.

If you want a clean API and are selling into multiple regions: a wrapper is worth it! TaxVett is the only one I found with a real free tier, that made it easy to evaluate without committing.

How to validate UK VAT numbers in Node.js (post-Brexit edition)

BitOwl — Sun, 14 Jun 2026 14:48:49 +0000

UK VAT numbers used to be validated through VIES like every other European country. After Brexit they moved to HMRC's own API, which is well-designed for what it does, but comes with some integration overhead that's worth knowing about upfront.

I had customers all over the world, storing thousands of VAT numbers in our SaaS solution, and sometimes a mess, manually managed. That brought me to finding a better way to validate them.

Here's a clean way to handle UK VAT validation, and how to extend it to cover EU and beyond with the same integration.

The HMRC API is solid, but not lightweight

HMRC's VAT validation endpoint lives inside their MTD ("Making Tax Digital") API platform. It's a proper, well-documented API. But it's built for accountancy software integrations, not quick checkout validations. Using it directly means:

Registering a developer account and creating an application
Implementing OAuth client credentials flow and handling token refresh
Going through HMRC's production credentials approval process before going live

The endpoint itself (GET /organisations/vat/check-vat-number/lookup/{targetVrn}) works well, once it's set up... The overhead is just higher than you might expect for a single-country number check.

The other consideration: if you're selling into EU countries as well, you'd need a separate VIES integration alongside it. Two auth systems, two error models, or more.

One endpoint for UK, EU, and more

I use TaxVett for this. It covers UK (HMRC), all 27 EU member states (VIES), Norway, Australia, and Singapore — one REST endpoint, one API key, consistent response format across all of them. For a checkout that sells into multiple regions, that's the main reason to reach for it.

For UK specifically, you just pass the number:

curl -X POST https://api.taxvett.com/v1/validate \
  -H "X-Api-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"number": "GB123456789"}'

UK numbers use GB prefix, auto-detected, no country field needed.

Full integration example

Here's a TypeScript module I for a Next.js API route:

// lib/vat.ts

interface ValidationResult {
  valid: boolean;
  companyName?: string;
  companyAddress?: string;
}

export async function validateUKVat(
  vatNumber: string
): Promise<ValidationResult> {
  // Normalise: strip spaces and ensure GB prefix
  const normalised = vatNumber.replace(/\s/g, "").toUpperCase();
  const withPrefix = normalised.startsWith("GB")
    ? normalised
    : `GB${normalised}`;

  const res = await fetch("https://api.taxvett.com/v1/validate", {
    method: "POST",
    headers: {
      "X-Api-Key": process.env.TAXVETT_API_KEY!,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ number: withPrefix, country: "GB" }),
  });

  if (res.status === 422) {
    // Format validation failed before hitting the registry
    return { valid: false };
  }

  if (!res.ok) {
    throw new Error(`TaxVett error: ${res.status}`);
  }

  const data = await res.json();
  return {
    valid: data.valid,
    companyName: data.company_name,
    companyAddress: data.company_address,
  };
}

And in the API route:

// pages/api/checkout/validate-vat.ts

import { validateUKVat } from "@/lib/vat";

export default async function handler(req, res) {
  const { vatNumber } = req.body;

  if (!vatNumber || typeof vatNumber !== "string") {
    return res.status(400).json({ error: "vatNumber required" });
  }

  try {
    const result = await validateUKVat(vatNumber);
    return res.status(200).json(result);
  } catch (err) {
    // Don't block checkout if validation service is down
    // Log the error, return valid: null to signal uncertainty
    console.error("VAT validation error", err);
    return res.status(200).json({ valid: null });
  }
}

Note: The valid: null pattern is intentional! I'd rather complete a sale and flag it for manual review than reject a legitimate customer because of a network timeout.

What format do UK VAT numbers have?

UK VAT numbers are 9 digits, optionally prefixed with GB. Branch traders use a 12-digit variant (GB + 9 digits + 3-digit branch code). A few formats the normalisation above handles:

Input	Normalised
`123 4567 89`	`GB123456789`
`gb123456789`	`GB123456789`
`GB 123 4567 89`	`GB123456789`

HMRC's test number GB999999973 works in sandbox environments if you want to check the integration is wired up before going live.

Does this work for EU VAT too?

That same endpoint actually handles all 27 EU member states, Norway, Australia, and Singapore. If you're selling into multiple regions you validate with one integration and get a consistent response shape regardless of which registry handled the lookup. (I think there are minor differences for just one or a few rare countries, have not affected me in practice so far.)

When it makes sense, and when it doesn't

Good fit:

You're selling into more than one region
You're in early development and want to iterate fast
You want a consistent JSON response
You don't want to pay to get started

Worth considering:

If you only need UK and already have an OAuth setup, hitting HMRC directly is a valid option
VAT numbers pass through a third-party API. If your compliance requirements are strict about data routing, check you are ok with TaxVett's privacy policy before integrating
At higher volumes the paid plans kick in (Pro €9/month). That's still cheap, but it's not free