One Country, Three Rates
Configuration screens ask which country you are in. For a large number of businesses that is the wrong question, and the resulting default is wrong from the first document without anything looking unusual.
Ask what the consumption tax rate is in Jamaica and the correct answer is a question back: what do you sell? The General Consumption Tax is 15% as standard, 25% on telephone services, phone cards and handsets, and a reduced effective rate in the tourism sector. One tax, one country, three answers — and almost every accounting system on the market is built to store exactly one of them.
Jamaica is not unusual in this. Liberia charges a higher rate on telecommunications than on general supplies. Plenty of jurisdictions run reduced rates on food, accommodation, transport or construction. What makes it worth writing about is that the software failure mode is unusually quiet: the rate stored is correct for the country and wrong for the business, and the two are hard to tell apart from a configuration screen.
A right value in a wrong unit
This is a different kind of error from a stale rate, and worth separating carefully. A stale rate is a maintenance problem: somebody looks it up, corrects it, and the system is right again. A wrong unit cannot be corrected by looking anything up, because there is no single value that would be right. The reference says "Jamaica: 15%", the reference is accurate, and a telecoms dealer set up from it is ten points light on every document.
| What the system stores | Is the value right? | Is the answer right? | How it fails |
|---|---|---|---|
| One rate per country | Yes, for the standard rate | Only for standard-rated businesses | Silently, from the first document, for everyone else. |
| One rate per country, gone stale | No | No | Loudly, eventually — somebody notices the number is out of date. |
| A rate per line, set by a person | Yes, when they remember | Yes, when they remember | On the day that person is on leave. |
| A rate per class of supply | Yes | Yes | It does not, which is the point. |
Why systems get the geography and miss the goods
There is a structural reason for this and it is worth knowing, because it tells you what to ask for. Tax tables in mid-market software are usually designed around jurisdiction, because the loudest requirement in the largest market is sub-national: state and local sales tax in the United States, provincial taxes in Canada. So the table grows a country column, then a region column, then a city column.
Those three columns answer the question "where is the transaction". They cannot answer "what is the transaction", which is a different axis entirely. A system can be thoroughly well designed for one and have no representation at all of the other.
The table can tell Kingston from Montego Bay, which does not matter here, and cannot tell a handset from a hotel room, which does.
What ours does, since we are the ones raising it
Exactly what is described above, and we would rather name it than let you find it. Your organization's own rate can be varied by country, by region and by city — three kinds of geography — and by nothing about what is being supplied. Your organization holds one default rate per tax type, so a second sector rate has nowhere to live as a default. Our country reference says Jamaica is 15%, which is correct and is what we would provision you with. The workaround is real and it is manual: the rate is stored per invoice line, so any document can be raised correctly, by a person choosing to. We will not call that sector support. Published on our Jamaica page in the same words.
The trap that looks like a solution
A tempting workaround is to configure the second rate as a second tax type — a "telecoms tax" at 25% alongside the ordinary one. Check what your system does with that before you build a year of records on it. In ours, where more than one tax type is enabled, the default rates are added together and reported as one blended figure, so 15 and 25 would present as 40. It is not merely inelegant; it produces a total on a screen that nobody can explain and that no report will flag.
The general lesson is that tax types are usually modelled as things that co-apply — a federal and a provincial tax on the same transaction — rather than as alternatives. Using them as alternatives fights the model, and the model wins quietly.
What a buyer can actually check
Four questions, and the second is the one that surprises people
Where does a non-standard rate live — on the item, the customer, the line, or a rule?
What you will hear
One of those four, or a description of an override.
How to read it
Only "on the item" or "a rule" survives staff turnover. "On the line" means a person remembers.
If I enable two tax types, what happens to the total?
What you will hear
Ideally: they are treated as separate lines. Sometimes: they are summed.
How to read it
If they are summed, the second-tax-type workaround is closed to you. Better to know before you configure it than after.
What rate will you set us up with on day one?
What you will hear
A number, drawn from a country reference.
How to read it
If that number is your country's standard rate and you are not standard-rated, your configuration is wrong from the first document. Ask what prompts anybody to change it. Usually nothing does.
A rate for one sector is announced to change in eighteen months. What does the system do?
What you will hear
Frequently a date field is offered.
How to read it
Ask what reads it. A date that is stored but never consulted is a common and well-disguised gap — we have two such columns ourselves and say so.
The short version
Before evaluating any system, write down every rate your business actually charges. If that list has one entry, none of this affects you. If it has two or three, you are buying against a requirement most tax configuration screens do not have a shape for, and the failure will not look like an error — it will look like a correct invoice at the wrong rate. Ask where a non-standard rate lives, and treat "the person raising the document sets it" as the honest answer it is rather than the feature it is sometimes presented as.
