Ten Types, And None Of Them Yours
Our tax types are a fixed list of ten, the same ten for everybody. Three of them exist because Canada needed them — which tells you both that the list can grow and that it only grows when somebody complains.
Every system that handles tax has to decide how a tax is named. Ours decided with a lookup table: ten rows, the same ten for every organization, and an organization picks one. It is a reasonable design, it has been fine for years, and it contains a specific kind of assumption that is worth pulling out into the light — because the same assumption is in a great many products and it is invisible until the day it is not.
The list
Value Added Tax. Goods and Services Tax. Sales Tax. Harmonized Sales Tax. Provincial or State Sales Tax. Quebec Sales Tax. Excise Tax. Service Tax. Withholding Tax. Custom Tax.
Read it twice, because two things in it matter more than the contents. The first is that three of the ten are Canadian. HST, PST and QST are there because somebody once needed a name that "VAT" and "Sales Tax" could not carry, and the list was extended to hold them. The second is that the tenth is a catch-all called "Custom Tax", which is what a business gets when its tax is not one of the other nine.
What those two facts prove together
The list can grow, and it grows only when a market is loud enough to make it grow. Everybody else gets the catch-all. That is not a design decision anybody made on purpose — it is what a central enum does over time, and it is the reason this post exists.
Who gets the catch-all
A business in the Canary Islands pays IGIC, which is not VAT — the islands sit outside Spanish VAT territory entirely, as we wrote separately. Ceuta and Melilla levy IPSI. Neither is on the list, so the most accurate option available to either is "Custom Tax": true, in the sense that it is not any of the other nine, and useless on a document somebody outside your business is going to read.
And they are not alone. Any market whose tax has a local name that does not map onto a global category is in the same position, and there are more of those than a list of ten suggests.
Why a central list is the wrong shape for this
The general problem is that a fixed enum encodes the author's knowledge of the world at the moment of writing, and then makes everybody else wait for a release to correct it. That is the right trade for things which genuinely are finite — a currency has a defined set, an ISO country code has a defined set. The name of a tax is not that. It is local, it changes, and new ones are created by legislatures who did not consult the enum.
| Shape | Who can fix a gap | What a gap costs |
|---|---|---|
| Central fixed list | The vendor, in a release | Everybody with an unlisted tax waits, and uses a catch-all in the meantime. |
| Organization-defined | The organization, immediately | Nothing, and the vendor never has to anticipate a market. |
| Central list with an escape hatch | Either — but the hatch is unlabelled | What we have. It works and it prints the wrong word. |
What this is worth to somebody evaluating software
It is a thirty-second test with a structural answer, and it works on any product in any market. Find where the tax type is set. Read the list. If your tax is not on it, ask whether you can add one — and if the answer is that support can add it for you, you have learned that your document's accuracy is on somebody else's release schedule.
That is not a disqualifying answer. Plenty of good systems work that way and plenty of businesses never notice. It is just worth knowing before an implementation rather than during one, and it is the sort of thing nobody thinks to ask because it sounds like a detail. It is a detail right up until it is printed on an invoice.
For our part: letting an organization define its own tax type is on our list with a specification and a price. It is small work — the list already grew once — and its real value is not Spain. It is that we stop having to anticipate every market, which is a thing no vendor has ever successfully done.
