When One Tax Sits Inside Another Tax's Base
Two levies at 19% and 1% are not one levy at 20%. Where one sits inside the other's base the difference is permanent, one-directional and about the size of a rounding error — which is exactly why it survives.
Almost every finance system ever built holds tax as a rate. A percentage, attached to a line, applied to the net amount. Where two taxes apply, it holds two rates and adds them. That model is correct in most of the world most of the time, which is why nobody examines it — and it is wrong wherever one of the two levies is inside the other one's base.
The failure has a particular character worth naming up front. It does not produce an error message, an unbalanced journal or a failed validation. It produces a total that is a little bit too small, in the same direction, every time. There is no month in which it cancels out.
The arithmetic, on a thousand
Take the clearest live example. In Tunisia, where FODEC applies, there are two consumption levies on the same line: FODEC at 1% of the price excluding tax, and VAT at 19%. But the VAT is not charged on the price. It is charged on the price plus the FODEC.
One thousand, two ways
Three decimal places because the Tunisian dinar has three. The figures are a derivation from the two rates rather than a constant — if either rate moves, so does the gap. What does not move is the relationship: the shortfall is always the outer rate applied to the inner levy.
Nineteen hundredths of one percent. On one invoice it is beneath anybody's materiality threshold. Across a year of production invoices it is a consistent variance with no traceable cause, because every individual calculation looks right and the rates on file are the correct rates.
The shortfall is always the outer rate applied to the inner levy. Which means it scales with turnover, never reverses, and is invisible at the level anybody checks.
Why adding rates feels safe
Because it is safe, in the ordinary case. If two levies are both percentages of the same base, adding them is not an approximation — it is algebraically identical. A 5% levy and a 2% levy on the same thousand really are 7% of that thousand. The habit is not sloppiness; it is a correct simplification that has been generalised past its condition.
The condition is shared base. Break it and addition stops being equivalent to anything. And a shared base is not something a rate can tell you about, which is the structural problem: a system that stores taxes as a list of percentages has thrown away the only information that would let it know whether adding them is legitimate.
Where else this happens
This is not a Tunisian eccentricity. It is a design pattern in tax systems, and it appears wherever a legislature has layered a levy on top of an existing one rather than beside it.
| Shape | What it looks like | What breaks |
|---|---|---|
| A levy inside the VAT base | A parafiscal or industry levy computed on the net, then included in the base the VAT is charged on | Adding the two rates under-states the total by the outer rate applied to the inner levy |
| Tax on tax across tiers | A sub-national tax charged on a base that already includes a national one, or the reverse | The same shortfall, and the two amounts can no longer be split for two different returns |
| Excise inside the VAT base | A specific or ad valorem excise included in the consideration on which VAT is charged | A system holding excise as a separate charge line rather than as part of the base computes the VAT on the wrong figure |
| A tax-inclusive base | The rate is defined against the gross rather than the net | Dividing instead of multiplying — a different error, from the same missing information |
The last row is worth pausing on because it is the most common version of the mistake in practice, and the easiest to get right: a rate defined on a tax-inclusive amount is not the same rate applied to a tax-exclusive one. Systems that offer a "tax inclusive" tick box have solved that single case. Almost none of them have solved the general one, which is that a base can contain another levy.
The second problem, which is worse than the first
Suppose you accept the shortfall. It is small; perhaps you are prepared to be a fraction of a percent light and correct it at the return. There is a second consequence that no adjustment fixes.
When a system adds the rates, it produces one number. Not a VAT figure and a levy figure — a blended figure, usually labelled with both codes joined together. And the two levies are not reported to the same place, on the same form, on the same cycle, or by the same rule. A return needs the VAT. An industry fund needs the levy. A single blended total cannot be split back into the two, because the split depends on a base the system never stored.
That is the difference between an inaccuracy and a structural gap. An inaccuracy can be adjusted; a missing split has to be recomputed from source documents, one at a time, by a person.
What a system would need in order to be right
Not much, and this is the frustrating part. The information required is one relationship per levy: what is this a percentage of? Not a rate, a base reference. Given that, the order of computation falls out and both the total and the split are correct.
- Does each tax carry a base reference — the net amount, or the net plus a named other levy — rather than only a rate?
- Are the levy amounts stored separately on the line, or is one blended tax figure stored?
- If two taxes are enabled, does the system add the rates or compute them in sequence? Ask to see it on 1,000 with rates of 19 and 1.
- Can a return be produced that shows one levy without the other, from stored data rather than by recalculation?
- Where a levy applies to some products and not others, is that a property of the item or a manual choice at entry?
The third item is the test to run in a demonstration, and it takes ninety seconds. Ask for two taxes at 19% and 1% on a thousand and look at the total. If it says 200, the system adds rates. If it says 201.90, it computes them in sequence. There is no third answer and no amount of configuration changes which one you are looking at.
Our own answer to that test is 200
AWRA OpsHub resolves the tax on a document by taking every tax type you have enabled and adding their default rates into one blended figure. Two taxes at 19 and 1 return 20, labelled with both codes joined, with no split between them. On the worked example above that is 200.000 where the correct figure is 201.900, and it is reached from twenty-one places in the codebase — invoices, quotations, point of sale, the vendor portal and the API. We measured it rather than reasoned about it, and there is a test in the repository that pins the behaviour so a future fix has to be deliberate. Publishing this is cheaper than being asked about it, and it is the reason we think the ninety-second test is a fair one to recommend.
The judgement, and it is not "buy a bigger system"
Large tax engines do model compounding bases, and if your obligations require it then that capability has to come from somewhere — usually from the local package or the clearance provider that also handles your statutory filing, rather than from a general operations system.
What is worth resisting is the assumption that this is a settings question. It is not. A system that stores a rate but not a base cannot be configured into correctness, because the information needed to compute the answer was never asked for. Knowing which of the two you are buying is the point of the ninety-second test, and it is a better question than almost anything on a feature comparison.
A tax rate per jurisdiction that you set
A default rate per country rather than one regional assumption, yours to set and change, carried onto lines at entry.
Landed cost that carries a levy you cannot reclaim
Where a levy on a purchase is genuinely a cost rather than a credit, it attaches to the consignment and moves the unit cost — which is the right destination for a charge no rate field can compute.
A base reference per levy, and levy amounts stored separately
The two things that would make a compounding base computable. Not built: the product adds rates and stores one blended figure. Stated here rather than in a footnote.
Statutory returns split by levy
We hold the detail a return is built from and we produce no returns, in any jurisdiction other than Kenya. That is a local purchase and should stay one.
The verdict
Adding tax rates is correct only when the levies share a base, and nothing in a rate tells you whether they do. If you operate anywhere with a levy inside another levy's base — Tunisia is the cleanest example, and it is far from the only one — then the arithmetic question comes before the feature list, because a system that adds rates under-states every affected total by the outer rate applied to the inner levy and cannot split the result for two returns. Run the ninety-second test on every vendor you shortlist, including us. Our answer is 200, we have said so, and knowing that is worth more to you than a promise.
Ask us the ninety-second question
Two taxes at 19% and 1% on a thousand. We will show you what our totals return, why, and which half of your problem we are actually for.
Talk to us about tax arithmetic