A US invoice, a UK invoice, an Australian tax invoice and a Canadian invoice are four genuinely different documents, not one document with a different percentage. Here's what I had to model to make a single form produce all four correctly.

The four systems, briefly

• US — sales tax. No national rate. It's state (and often county/city) level, and the seller only charges it where they have nexus. On a simple invoice tool, the realistic move is: let the user enter their own rate, show it as "Sales Tax," and never pretend there's one number.
• UK — VAT. One national rate (20% standard), but the invoice must show the VAT registration number and the VAT amount as a line, and "VAT invoice" is a specific legal document. Not every small business is VAT-registered, so VAT has to be optional.
• Australia — GST. 10% flat, but the document itself changes name: once GST is included it's a "Tax Invoice," and that label is required wording. Below AUD 1,000 vs above has different ID requirements. The ABN (not a VAT number) goes on it.
• Canada — GST/HST + PST. This is the spicy one. Depending on the province you get GST alone, HST (a combined federal+provincial rate), or GST + a separate PST/QST. Ontario is 13% HST; Alberta is 5% GST only; Quebec is 5% GST plus 9.975% QST calculated separately. So Canada isn't one rate — it's a per-province rule set.

What that means for the data model

The naive model is taxRate: number. That dies immediately on Canada. What actually works is a small per-region descriptor:

const TAX = {
  US: { label: 'Sales Tax', mode: 'single', rateEditable: true, idLabel: null },
  UK: { label: 'VAT', mode: 'single', rate: 20, idLabel: 'VAT No.', optional: true },
  AU: { label: 'GST', mode: 'single', rate: 10, idLabel: 'ABN', docName: 'Tax Invoice' },
  CA: { label: 'GST/HST', mode: 'province', idLabel: 'GST/HST No.' }, // per-province
};
// Canada resolves to one or two components:
const CA_PROVINCES = {
  ON: [{ label: 'HST', rate: 13 }],
  AB: [{ label: 'GST', rate: 5 }],
  BC: [{ label: 'GST', rate: 5 }, { label: 'PST', rate: 7 }],
  QC: [{ label: 'GST', rate: 5 }, { label: 'QST', rate: 9.975 }],
  // ...
};

Now tax is a list of components, not a scalar. The US/UK/AU cases are just a list of length one. Canada is length one or two. The renderer doesn't care how many there are:

function taxLines(region, province, subtotal) {
  const comps = region === 'CA'
    ? CA_PROVINCES[province]
    : [{ label: TAX[region].label, rate: resolveRate(region) }];
  return comps.map(c => ({
    label: `${c.label} (${c.rate}%)`,
    amount: round(subtotal * c.rate / 100),
  }));
}

Once tax is a list, every "weird" case collapses into the same loop. That one refactor — scalar to list of components — is the whole trick.

The non-obvious bits that bit me

• The document name is data, too. Australia's "Tax Invoice" wording isn't decoration; switching region has to switch the H1/title, not just the math. I ended up treating the doc label as part of the region descriptor.
• Rounding is per-component, per-line — and countries disagree. Summing then rounding vs rounding then summing can differ by a cent, and some tax authorities are specific about it. Pick a rule, apply it consistently, and round each tax component independently (especially for Canada's two-component provinces).
• Tax ID labels differ and some are optional. VAT No., ABN, GST/HST No. — same slot, different label, and for a not-yet-registered freelancer the whole field should disappear rather than print an empty "VAT No.:".
• Currency is not region. Someone in the US invoicing in EUR is a real case. I keep currency and tax region as independent selectors; coupling them was an early mistake.

Why bother, for a free tool

Because "close enough" tax is worse than no tax — it makes the document look official while being subtly wrong, which is exactly what a small business can't afford. Modelling it properly turned out to be maybe 150 lines of config, not a tax engine. The leverage was in the shape of the data (components, not a rate), not in the amount of code.

If you want to see all four in action, the generator is here: free-bizdocs.com/en/invoice — switch the region selector and watch the labels, the document name and the tax breakdown change together.

I'm sure I'm still missing edge cases (provincial point-of-sale rebates, EU reverse-charge, US origin-vs-destination sourcing). If you've shipped multi-jurisdiction tax, I'd genuinely like to hear what broke for you.

The obvious way is to save the document to a database, mint an ID, and serve /invoice/abc123. But I didn't want to do that. A free tool that quietly stores everyone's invoices — names, amounts, bank details — is a liability I'd rather not own. Storage costs money, backups are a responsibility, and "we keep a copy of your billing data" is the opposite of what a throwaway tool should promise.

So I built sharing with zero server storage. The link contains the document. Open it and your browser reconstructs the invoice locally. Nothing ever hits my database.

Here's how it works, and the three gotchas that took the longest to get right.

The core idea: the fragment is the payload

A URL has a part the browser never sends to the server — everything after the #. That's the fragment (hash). I encode the whole invoice into it:

// Create a share link
function makeShareLink(doc) {
  const json = JSON.stringify(doc);              // {items, client, company, total, dueDate, ...}
  const packed = btoa(encodeURIComponent(json)); // UTF-8 safe base64
  return `${location.origin}/invoice#s=${packed}`;
}

On the receiving side, the page reads its own hash on load and rebuilds the document — read-only, with the amount, bank details and due date surfaced at the top:

// On page load
const m = location.hash.match(/[#&]s=([^&]+)/);
if (m) {
  const doc = JSON.parse(decodeURIComponent(atob(m[1])));
  renderReadOnly(doc);   // no edit UI, just the invoice + a "pay to" panel
}

Because the data lives in the fragment, the server literally never receives it. My Cloudflare Function logs show a request for /invoice with no query string — the #s=... part stays in the browser. No row is written. No ID exists to leak.

Gotcha 1: btoa chokes on non-ASCII

btoa("請求書") throws InvalidCharacterError. Base64 in the browser only speaks Latin-1, and my users write invoices in Japanese, German, Spanish… The fix is to percent-encode to UTF-8 first (encodeURIComponent) and decode after (decodeURIComponent). Miss it and every non-English invoice silently breaks.

Gotcha 2: the PDF is generated on the client too

If the server never sees the data, it obviously can't render the PDF. I generate it in the browser with pdf-lib and embed a font so Japanese doesn't turn into tofu:

import { PDFDocument } from 'pdf-lib';
import fontkit from '@pdf-lib/fontkit';

const pdf = await PDFDocument.create();
pdf.registerFontkit(fontkit);
const font = await pdf.embedFont(await fetch('/fonts/noto-jp.ttf').then(r => r.arrayBuffer()));
// ...draw the invoice with `font`, then pdf.save()

Keep the font same-origin. I initially loaded it from a CDN and spent an afternoon on CORS/ArrayBuffer failures that only showed up on some networks.

Gotcha 3: links get long — decide what not to include

A full invoice with ten line items and addresses is a few KB of JSON → a chunky base64 string. Browsers and chat apps tolerate surprisingly long URLs (tens of KB), but I still draw the line:

• In the link: line items, client, company, totals, due date, bank details.
• Never in the link: uploaded logos and stamp images. A base64 PNG would blow the URL up to hundreds of KB. The shared view just omits them.

That one rule kept links pasteable in email and messaging apps without truncation.

Why this shape is nice beyond privacy

• No backend for the feature. The entire thing is static assets plus a tiny Cloudflare Function that only serves the shell. On Cloudflare Pages the whole site runs at effectively zero fixed cost.
• Nothing to expire or clean up. There's no orphaned-rows table growing forever. Delete the link, delete the data.
• Trivially offline-friendly. Rebuilding the doc is pure client code.

The trade-off is honest: the data is only as private as the link. Anyone with the URL can read it — same as a PDF attachment — and you can't revoke it after sending. For a shareable invoice that's exactly the right model; for anything you need to lock down later, store it server-side and gate it behind auth.

If you want to poke at the running version, the invoice tool is here: free-bizdocs.com/en/invoice — create one, hit "share link", and watch the network tab stay quiet.

Would I use the fragment-as-database trick everywhere? No. But for "let the user hand someone a self-contained document, and don't you dare keep a copy," it's the simplest thing that works.