When automated invoices quietly stop charging tax

This article is not about which tax rate applies to you. That depends on where you are, where your customer is, what you sell and how you are registered, and it belongs to your accountant.

It is about something else: what your billing system does when it is not sure, and how you find out. Automated invoicing rarely fails loudly on tax. It produces a confident-looking invoice with a number in the tax line, sends it, collects the money, and the number is a decision somebody's software made using information you may not know it was using.

Your customer's location is a guess with a priority order

Tax follows location, so the first question is how the system decides where your customer is. Stripe documents its answer as a list, taking the first item that exists.

For invoicing and subscriptions it uses, in order: the shipping address, then the billing address, then the billing details of the most specific payment method attached — the invoice's default, then the subscription's, then the customer's — and finally the customer's IP address.

Two things follow from that list, and both matter.

A partly-filled address wins over a correct one. A shipping address left over from a single delivery two years ago outranks the billing address the customer updated last month. The system is not weighing which is more current; it is taking the first one that exists.

An invalid address does not fall through. Stripe is specific: if the shipping or billing address is present but invalid, it raises a customer_tax_location_invalid error rather than trying the next item on the list. A half-typed address is worse than no address, because it stops the chain rather than passing the question along.

At the bottom of the list sits the IP address, and Stripe's own guidance is to be wary of it: "In most cases, we can resolve an IP address to a physical area, but its precision varies and might not reflect the customer's actual location. Given that the US imposes local taxes, we don't recommend relying on a customer's IP address to determine their address."

A postal code is not an address, and in nineteen states it is not enough

If you sell into the US, this one has a list attached, which makes it unusually checkable.

Stripe calculates from the geographical centre of the five-digit postal code when that is all it has. Two neighbouring houses can sit in different tax jurisdictions, so the centre of a zip code is an approximation, and the documentation names the states where it recommends against relying on a postal code alone: Alabama, Alaska, Arizona, Arkansas, California, Colorado, Illinois, Kansas, Louisiana, Missouri, Nebraska, New Mexico, North Dakota, Oklahoma, South Dakota, Texas, Utah, Washington and West Virginia.

Europe has a smaller version of the same problem: tax is set nationally, but a handful of areas sit inside a country and outside its tax. Stripe's example is the Italian postal code 00120, which is Vatican City, where Italian VAT does not apply. Recognising that requires the postal code or region, which is exactly the field a "just ask for the country" checkout leaves out.

If your signup form asks for less than your tax calculation needs, the gap does not announce itself. It shows up as a rate that is slightly wrong, invoice after invoice.

The zero that does not mean what it looks like

A zero in the tax line reads as "no tax was due here". It can equally mean something quite different.

Stripe states the rule plainly: "Stripe only calculates tax in jurisdictions where you have an active tax registration. Without a registration in the customer's location, the calculation returns zero tax."

So a zero can mean the sale genuinely carries no tax — or that the system has no registration for where this customer is and therefore has nothing to calculate. Both print the same character on the invoice. Only one of them is a fact about the sale.

This is worth knowing before you grow into a new market rather than after. The first invoices to customers in a new country will look exactly like the ones you have been sending all along.

While we are on numbers that surprise people: tax is calculated after discounts, on the amount actually paid. Stripe's example is a 150 USD product with a 20 USD discount, where tax is computed on 130 USD. Reasonable, and worth checking against whatever your own spreadsheet does, because a spreadsheet that applies tax before the discount will disagree with your invoices for the rest of its life.

The setting that turns itself off

Here is the failure worth setting a reminder over.

If the system cannot recognise a customer's location, Stripe documents that subscription invoices keep finalising automatically, without calculating tax. The automatic_tax[enabled] flag flips to false on both the subscription and the invoice, disabled_reason is set to requires_location_inputs, and the invoice finalises with no tax amounts on it. Payment is collected as usual.

Nothing stops. The customer is billed, the money arrives, and the tax that should have been on that invoice is not on it — and the reason may be as mundane as somebody updating or removing the default payment method on that customer.

Events are emitted, so an integration can notice. A person will not, unless they go looking. Stripe's dashboard has the filter for exactly this: on the Subscriptions page, Automatic tax not enabled.

If you run recurring billing and read one thing from this article, make it that filter. Check it monthly. It answers, in one click, whether anything has been quietly billing without tax.

What to check

Look at where the address actually came from. For a handful of recent invoices, find which address the tax calculation used, and ask whether it is the address you would have used. Stale shipping addresses are the usual culprit.

Compare what you collect with what the calculation needs. If your checkout asks for a country and your customers are in the US, you are calculating from less than the documentation recommends.

Find your zeros and classify them. Every zero in a tax line is either "no tax due" or "no registration here". You should be able to say which, for each one.

Watch the auto-disable. Monthly, on the subscriptions filter above.

Then hand it to your accountant. Everything in this article is about whether your systems are doing what someone intended. Whether what they intended is correct for your business is a different question, and not one a billing dashboard can answer.

When this is worth a proper look

For a business invoicing in one country with one product type, the checks above are the whole of it.

It gets harder when a sale crosses a border, when what you sell has different treatments for different customers, or when the invoice is assembled from parts that live in several systems — a booking here, a product there, a discount applied by a third. Then the tax line is the output of a chain, and it is worth knowing which link decided what before a quarter's worth of invoices go out with the same quiet mistake in them.

Mapping that chain is one of the things a process audit does: $299, three business days, and a written account of what each step decides. It is not tax advice, and it does not replace your accountant — it tells you what your software is actually doing so that the conversation with them is about facts.