Three Reasons for a Zero, and Two Places to Put Them

On the screen they are identical: a line with a quantity, a price, and nothing in the tax column. Three different legal situations produce that same nil, and the differences between them are not subtle points of interpretation. They change who is liable for the tax, whether the seller can recover the tax on their own costs, and whether the invoice has to carry an extra sentence to be valid at all. A system that stores one of them as another is not being imprecise. It is recording something that did not happen.

Nothing here is tax advice, and this post deliberately does not classify a single real supply. Which state a particular transaction is in is your adviser's determination. What follows is about data modelling — a question you can settle on your own, and one that stops mattering the moment you have settled it.

The three states, and what actually separates them

Zero-rated

A taxable supply, charged at a rate of nought. The transaction is inside the tax system; the rate applied to it happens to be zero. Because it is a taxable supply, the tax the seller paid on their own costs to make it generally remains recoverable. The liability is the seller's and the amount is nil.

Exempt

A supply outside the charge entirely. Not taxed at nought — not taxed. The practical consequence runs in the other direction from the one above: the tax on the seller's own costs attributable to it is generally not recoverable, which means an exempt sale can be more expensive to make than a zero-rated one of the same value. There is no liability and the difference lands on the seller's costs.

Reverse-charged

The one that is structurally unlike the other two, and the reason this post exists. The supply is taxable and the tax is real — it has simply become somebody else's to account for. On a supply to a VAT-registered business in another member state, the buyer accounts for the tax in their own country. The liability exists, it is non-zero, and it belongs to the other party. The nil on the seller's invoice is not the absence of tax. It is the tax being somewhere else.

It is also worth knowing that the mechanism is not only a cross-border one. Some domestic arrangements shift the charge to the customer within the same country — construction subcontracting is the commonly cited case. Read that as a mechanism rather than as a rule you can apply; whether it bites on a particular contract is your adviser's call. What matters here is the shape: a reverse charge is a fact about a transaction, not about a border, so a system that models it as "the international case" has modelled it wrong.

What our own product does, stated exactly

We will use ourselves as the worked example, because it is the schema we can actually show you and because a post on this subject that only criticised other vendors would be worth nothing. Our resolver takes an organization default rate and an item treatment, and it has three branches.

Two things follow, and the second is worse than the first. The first is the one you would expect: zero-rated and exempt resolve to the same nil, so once a line is saved the record cannot tell you which was meant. That distinction is not decorative — it is the one that decides recoverability — and a return assembled from these records afterwards is being assembled from information the database threw away.

The second is the interesting one. There is no reverse-charge value at all, and the resolver's third branch means the obvious attempt to add one does something unfortunate.

A validation error would be a far smaller problem than a plausible wrong number. Rejecting an unknown value costs somebody thirty seconds. Accepting it and quietly substituting the default costs somebody a customer conversation and a credit note.

Why a missing state is worse than a missing feature

There is a temptation to file all of this under "does not support reverse charge yet", which sounds like a gap on a roadmap. It is not quite that, and the difference is worth being precise about.

A missing feature is something the system cannot do. You find out, you work around it, you move on. A missing state is something the system records incorrectly — and it records it incorrectly at the moment of saving, in a way that cannot be repaired later. If a year of invoices was issued with reverse-charged lines saved as merely zero-rated, no amount of subsequent reporting cleverness can separate them from the genuinely zero-rated ones, because the distinction was never written down. The workaround does not merely inconvenience you now; it degrades the archive.

This is the general form of the thing, and it is worth carrying to every vendor conversation you have: ask what a system stores, not what it displays. A tax status that exists only as a note somebody typed, or only as a report filter applied afterwards, is not stored. It is remembered, by a person, and only until they leave.

What a correct model looks like, in four lines

It is not a large piece of design, which is part of what makes the gap frustrating rather than forgivable.

1. A tax state on the line with more than two values

   Standard, zero-rated, exempt and reverse-charged as four distinct stored states, not two outcomes. The states are stable across every VAT jurisdiction on earth, which is why this is a schema decision rather than a country feature.

2. An unrecognised value that fails rather than defaults

   Anything the resolver does not know should stop the save. The current behaviour — fall through to the organization default — is the single most dangerous line in this part of our code, because it converts a typo into a plausible invoice.

3. The document wording derived from the state

   If a line is reverse-charged, the invoice says so because the line says so — not because somebody remembered to type it into a notes box. The state is the source; the sentence is a rendering of it.

4. The counterparty identifier stored on the transaction

   A reverse charge names the other party. That means the buyer's VAT identification number belongs on the invoice, not only on the customer record — which is also the only way a per-customer periodic listing can ever be produced from the data.

Three questions worth asking any vendor

What we would build, and where we stop on purpose

A fourth state, stored; a validation failure instead of a fall-through; the invoice legend rendered from the state rather than typed; and the counterparty identifier on the transaction so a periodic listing becomes possible at all. That sequence is a schema and resolver change rather than a configuration exercise, and it improves every VAT jurisdiction in the product rather than one country — which is the argument for doing it properly rather than for the Netherlands. What we will not do is decide which state a supply belongs in. That determination is your adviser's, they sign it, and a vendor offering a view on it is selling a tax opinion with a software licence attached.