When the Unit of a Rate Is a Sector
Every system provisions a tax rate from a country, because almost everywhere the country is the unit. Where the unit is a sector instead, a correct-looking configuration is wrong for your whole business.
Ask a piece of software what tax rate to use and it will ask you what country you are in. That is not laziness — it is right nearly everywhere. The country is the unit the rate varies over, so a country is enough to resolve it.
Jamaica levies one tax at more than one rate, and the thing that decides which rate applies is not where you are. It is what you do. So a system resolving a default from a country produces a figure that is the headline national rate, plausible, correctly installed, and wrong for every business in the sector that has its own.
That is a different class of error from a stale rate. A stale rate is a number somebody has to update. This is a shape problem: the system has one slot where the market needs a dimension, and no amount of editing the number fixes it.
Why it survives, which is the interesting part
A wrong rate usually announces itself. A customer queries a total, an adviser spots it at a filing, somebody notices the figure does not match an invoice they received elsewhere.
This one does not, for three reasons at once. The value came from a vendor's reference data, so it looks authoritative. It is a genuine Jamaican rate, so it does not look like a typo. And it was written once at signup, into a field that nobody revisits — the moment of least attention in the life of an account.
This post assigns no rate to any sector, deliberately
Which rate applies to which activity, and to a business that does more than one thing, is a question for your adviser — and it is the fact most likely to move. The reduced tourism rate has been announced to end in April 2027, which is a date worth putting in a diary and confirming rather than treating as settled. What is safe to publish is structural: if the rate depends on your sector, then a configuration keyed on your country cannot express it.
Two rates inside one business is the normal case, not the exception
The examples are ordinary: a dealer selling handsets alongside accessories, a hotel with a retail arm, an operator billing both visitors and residents. None of them is an unusual structure. All of them mean the answer to "what is our rate" is it depends on the line.
| Where the rate is held | What happens to a mixed business |
|---|---|
| One default per organization | One of your two activities is billed wrongly, consistently |
| On the customer | Fails as soon as one customer buys both kinds of thing |
| On the document | Fails on any invoice that carries both |
| On the line, chosen at capture | Works — and the mix becomes a record rather than a reconstruction |
A rate that varies by sector inside a business that has two sectors is not a tax question. It is a question about whether your document model has a line-level opinion.
Where we stand, including the parts that do not work
Four limitations, all four in the honesty ledger on our Jamaica page rather than waiting to be discovered.
A rate on every sales and purchase line at capture
Net, tax and gross split at the point of entry, per line. This is the mechanism that lets a mixed business be recorded as mixed, and it is the reason the argument above is actionable rather than theoretical.
A rate you control, not one we impose
The default is yours to set and change. Which matters here more than in most markets, because our default is the one that will be wrong for you.
No sector dimension on a tax rate
Your organization holds one default per tax type. There is no field that says "this rate applies to this activity", so a business with two rates manages the distinction at the line and in its own discipline rather than through configuration. Ordinary work, commissionable now with a written specification, a timeline and a price.
Nothing prompts you when a rate is due to change
An announced end date is a diary entry with a name against it, not a scheduled event in the product. We would rather say that than let a date in a field imply a plan.
No output for the authority
We produce no return in a format Tax Administration Jamaica accepts and we submit nothing. We hold the detail a return is built from. Commissionable against a published specification, with Kenya as the evidence we build this way.
Telling you which rate your activity attracts
Not ours. That is an adviser's judgement about your business, and a vendor answering it confidently in a sales meeting has told you something about how they sell.
The check, and it applies well beyond Jamaica
Whatever market you are in, do this once at signup rather than at the first filing.
- What rate did the system provision for you, and where did that value come from?
- Is it the right rate for your activity, or the right rate for your country?
- If your business does two things, can a single invoice carry both rates?
- Is there any date attached to the rate you are on — and if there is, does anything act on it?
- Who in your organisation would notice if the rate were wrong, and by what route?
The last question is the one that decides how long an error lives. In most operations the honest answer is "the auditor, eventually" — and the gap between signup and eventually is where the cost accumulates.
What is built here, what is not, and what we would decline is on the Jamaica market page. The general form of this — asking what an obligation is computed over before you write a rate into anything — is what does this obligation count in, and it carries two defects of our own found by asking exactly that.
