The Rate That Was Law For Five Years
Bhutan's goods and services tax commenced on 1 January 2026 at 5%. Its own Act had said 7% since 2020, and 7% was never charged for a single day. Almost every source still says 7%, and every one of them read the statute.
There is a rule of thumb in this work that is almost always right: when sources disagree about a tax rate, go and read the Act. It is the rule that separates a figure you can publish from a figure you found. Bhutan is where it fails — not because the Act is wrong, but because reading it correctly and completely can still leave you with a number that has never appeared on an invoice.
The GST Act of Bhutan 2020 set the rate in Schedule I at 7%. Section 67 of the GST (Amendment) Act of Bhutan 2025 replaced that schedule, so it now reads that other than the zero rate, the applicable rate on taxable supplies and taxable imports shall be 5%. And the tax itself commenced on 1 January 2026.
Read those three lines in order and the shape appears. The 7% existed in law for five years. It was replaced before the law it lived in ever operated. A rate can be enacted, published, cited and superseded without a single invoice ever carrying it — and a researcher who goes to the primary source, reads it carefully, and stops there will publish it with complete confidence.
That is not a hypothetical failure. Almost every secondary source on Bhutanese GST still says 7%, and they are not careless — they are reading the Act. The 5% is only visible if you know that an amending Act exists and go looking for a consolidation.
This is not the same as a tax that has not started
It is worth separating this from a case we have written about before. Palau and the Marshall Islands have legislated consumption taxes with no commencement date — laws that exist and do not operate. That is a different problem with a different answer, and the answer there is that a system should carry a real zero rather than a placeholder.
Bhutan's tax has commenced. It is live, it is being charged, and the figure to configure is unambiguous. The failure is not in the country and not in the law. It is in the assumption that the document called "the Act" contains the current text of the Act.
Four ways a statute tells you what is charged today
Once you start looking for it, legislative drafting turns out to have several completely different answers to the question "what does this charge now", and they are not equally safe to read.
| Model | Where | What you get | What it costs you |
|---|---|---|---|
| Consolidated, with amendment notes | Pakistan | Current text, plus a footnote on each clause saying which Finance Act put it there | Nothing. This is the safe case and it is rarer than it should be |
| Consolidated, history kept inline | Cyprus | The rate section states the old band with both its dates and the current one after it | Nothing, and it is oddly useful — the law is its own changelog |
| As enacted, never consolidated | Bangladesh | The original text, complete, authentic, and superseded in places | A superseded figure carried with the authority of a statute |
| Consolidated, but the original never ran | Bhutan | Current text — if you find the consolidation rather than the original | A figure that was law and was never charged |
Cyprus is the one worth dwelling on because it is so nearly a solved problem. Section 17 of its VAT Law does not simply state a percentage. It states that VAT is imposed at 18% for the period from 14 January 2013 to 12 January 2014, and at 19% from 13 January 2014. The superseded band is still in the operative text, with a start date and an end date, twelve years after it stopped applying.
A Cypriot rate is a dated interval in the law itself. Almost no finance system can store what that statute is plainly telling it.
Bangladesh, and the archive that looks safest
The dangerous case is not the blocked website. It is the one that answers.
Bangladesh's Value Added Tax and Supplementary Duty Act, 2012 is published by the revenue authority as an English text, and it is genuine. Section 15(3) sets VAT at 15%, which is correct today. Elsewhere in the same document are a turnover tax rate and two turnover thresholds that later Finance Acts have moved, and nothing in the document says so — no amendment footnote, no consolidation marker, no revision date beyond a footer.
So the same PDF gives you one current figure and several historic ones, with identical authority, in identical typeface. There is no signal to tell them apart. And this Act carries a second date worth knowing: it was passed in 2012 and came into force on 1 July 2019, seven years later. Anything written between those dates describes a law that was not operating.
Three dates, and "the Act says" answers none of them
Put together, the four cases above say that a tax figure has at least three dates attached to it, and that they routinely differ by years.
-
When was the instrument passed?
The easy one, and the least useful. It tells you when a legislature agreed something and nothing about whether it applies. Bangladesh's Act was passed in 2012 and this date is the only one printed on its cover.
-
When did it commence?
The one most often missing. Bhutan's GST commenced on 1 January 2026, six years after its Act. Bangladesh's VAT commenced on 1 July 2019, seven years after its Act. If a source gives you a rate and an Act year, you do not yet know whether the tax existed.
-
When was this particular figure last amended?
The one that catches people who did everything else right. This is the Bhutan case exactly: correct Act, correct commencement, superseded schedule. The only defence is knowing whether you are holding a consolidation, and the only way to know is to look for the amendment apparatus rather than for the number.
-
And separately: what date does the document you are pricing belong to?
A different question with a different answer, and we have written about it elsewhere. The three above are about where your reference figure came from. This one is about which figure a particular invoice should have used. A system can get either right and the other wrong.
What we do about it, and what we do not
The honest version, because this post is a criticism of a research practice and we use the same practice.
What AWRA OpsHub does today
- A provenance record for every country rate, held separately from the rate itself: the authority, the source URL, the date the figure was last verified, the date it took effect where that is known, a confidence value, and a written note.
- A review clock per country, so a figure that has not been re-checked inside its window is reported as due rather than quietly ageing. A command reports the outstanding count and a scheduled digest sends it.
- A confidence vocabulary that can say "this is only the standard rate", or "this was not verified at the authority", so an unverified figure is distinguishable in the data from a verified one rather than only in somebody's memory.
- A written failure note per country where verification failed, naming what was tried and what to try next — which is what turns an unverified row into a task rather than a shrug.
What it does not do
- Any date on the rate itself. Our country tax table holds one rate per country and no effective date at all. The provenance sidecar records when a figure took effect; the table the software actually reads does not.
- Any rate history. There is exactly one figure per country. When a rate moves we overwrite it, and the previous value survives only in version control and in the provenance note.
- Any automated detection of a change. The review clock tells you a figure is old. It does not tell you it is wrong, and nothing anywhere watches an authority for an amendment.
- Any of this on the tenant side. An organisation's own tax rate rows carry effective-from and effective-to columns that nothing reads — a separate defect we have written about on its own.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a tax authority pipeline, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax authority pipelines and reporting
Electronic invoicing or invoice registration against your authority's published interface, with retries, a failure queue and a daily report of sales that carry no reference. The regimes across this region differ enough that this is one build per country rather than one build for the region, and the local bench is deep in most of them — so the honest question is usually whether you need this from us at all, or whether you need the operations layer that feeds whatever you already file with.
Local payment rails and bank feeds
Real-time payment collection matched to the invoice, bulk payment files in your bank's format, and statement feeds wired into the Payments Register.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Statutory payroll and social security schedules computed on live records and produced in the layout each filing body expects. Per-state and per-province variation is the norm rather than the exception here, and it is what makes this a country build rather than a regional one.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThe number that keeps us honest about the second half of that list: when this was written, our own review tooling reported 72 of 188 country rows as due for review. That is a measurement on a day and not a steady state, and it is the right order of magnitude for a table that is checked by people rather than by software. It is published here for the same reason the rest of the list is — a provenance system whose backlog you do not state is a provenance system you are describing rather than running.
The instruction
If you take one thing from this: going to the primary source is necessary and it is not sufficient. The second half of the check is to establish what kind of document you are holding — as enacted, or consolidated, and if consolidated, to what date. That question takes a minute and it is the difference between Bhutan at 5% and Bhutan at 7%, which is a forty per cent error arrived at by doing the research properly.
And if you are the one configuring a system rather than the one researching it, the practical version is smaller still. Ask whoever gave you the number where they got it and when. If there is no answer to the second half, the figure is not sourced — it is remembered.
Frequently asked questions
Is Bhutan's GST rate 5% or 7%?
5%. The GST Act of Bhutan 2020 set 7% in Schedule I, and section 67 of the GST (Amendment) Act of Bhutan 2025 replaced it with 5% before the tax commenced on 1 January 2026. Because the Act only commenced in 2026, 7% was never charged. Sources still publishing 7% are reading the original Act rather than the consolidated one, which is an understandable error and still an error.
How do I tell whether a statute I am reading is consolidated?
Look for the amendment apparatus rather than for the rate. A consolidated text usually carries a footnote or marginal note against amended clauses naming the instrument that changed them, and often a revision date on the cover. A text with none of that, especially one described as an unofficial translation, is likely to be the original. If you cannot tell, treat the numbers in it as unverified and say so.
Does your own tax table have this problem?
Partly, and we would rather state which part. We keep a provenance record beside every country rate — authority, source, the date it was last verified, a confidence value and a note — and a review clock that reports figures which have aged past their window. What we do not have is any date on the rate the software actually reads, or any history: there is one figure per country and a change overwrites it. So we can tell you where a number came from and when we last checked it, and we cannot tell you what it was last year.
Why does this matter if a rate is usually stable?
Because the cost is asymmetric. A rate that has been stable for a decade needs checking once and costs nothing to hold; a rate that moved last year and was configured from a document written before it moved is wrong on every document until somebody notices, and the person who notices is usually an auditor. The checking is cheap and the discovery is expensive, which is the whole argument for doing it on a clock rather than on a complaint.
