What Was The Rate Then?
Almost every finance system stores one tax rate per country and no date. That is correct until the first time you raise a new document about an old period, and then it is confidently wrong with no warning attached.
Open the tax configuration of any accounting system and you will find a rate attached to a country, or to a tax code, or to a product category. What you will almost never find is a rate attached to a period. The model says a country has a rate. It does not. A country has a rate on a date, and the two only look like the same statement until a legislature moves one.
This is not an exotic edge case dragged in to make a point. Rates move constantly and in both directions, for ordinary budget reasons. Fiji moved its VAT from 9% to 15% on 1 August 2024 — a six-point change, in the upward direction, on a single stated date, in a country small enough that most businesses there felt it at once. It is a clean example precisely because there is nothing unusual about it.
The half that is usually already safe
Start with the good news, because it is real and because it tells you where to look for the bad news. In a competently built system the tax rate is stored on the document line at the moment the document is raised, not looked up when the document is displayed. An invoice raised in July 2024 carries 9% as a stored figure, and will still say 9% in five years and after three more rate changes.
That is not an accident and it is worth understanding as a design decision rather than as luck. A system that re-resolved the rate on display would silently rewrite its own history every time a budget passed, and every historic report would change underneath the people relying on it. So the storage of a rate on the line is the single most important protection here, and it is one most products get right. Go and verify it in yours anyway: open a document from before a change and check that the rate on it is the rate it was raised at.
The half that is usually not
The exposure is not in old documents. It is in new documents about old periods — and there are more of those than anybody expects, because they are the ordinary business of correcting things.
| The document | What it needs | What a dateless system does |
|---|---|---|
| A credit note against a pre-change invoice | The rate the original supply carried — a credit follows the supply it reverses | If the credit note holds no tax breakdown at all, there is nowhere to record which rate it reverses. The treatment lives in the journal narrative. |
| A reissued or corrected invoice for an old period | The rate in force at the time of supply | Resolves today's rate, because that is the only rate stored. |
| A recurring schedule crossing the change | The old rate before, the new rate after | Usually fine — each generated document resolves at generation and then stores it. This one tends to work. |
| A quotation issued before and accepted after | A genuine question, turning on the terms and the time of supply | Converts carrying the rate it was issued at, with nothing to prompt anybody that the question exists. |
| "What was the rate on this date?" | A rate history | Answers with today's rate, and does not indicate that it was asked something it cannot answer. |
The dangerous answer is not "I do not know". It is a confident number, returned instantly, to a question the system was never able to answer.
Why nobody just adds a date column
Because a date on the existing row does not fix it. What is needed is a rate history per country — a set of rows, each with a validity span — plus a document date threaded through every place that currently resolves a rate. Those are two different-sized jobs and the second is the large one.
Consider what resolves a tax rate in a typical system: invoicing, quotations, point of sale, credit notes, purchase orders, supplier invoices, the API, any import routine, and the provisioning path that gives a new organization its defaults. Most of those have a document date available and simply never pass it. One of them — provisioning — has no document date at all, because the organization is registering today and today is the right answer for it. So the change is not uniform, and any design that makes the date mandatory breaks the one caller for which "now" is correct.
What ours does, since we are the ones raising it
Two things, and we will name the columns. Our invoice lines store the tax rate on the line, so history is genuinely safe and does not re-resolve. Our credit note is a single amount with a customer, a reason and an optional link to the invoice — no lines, no tax rate, no tax columns, so a credit reversing a supply taxed at a different rate has nowhere in the record to say so. And our country tax reference holds one rate per country with no effective date anywhere in the file or the resolver, so asked what a rate was in a past month it returns today's. Both are published on our Fiji page and pinned by a test, so that fixing either has to be a deliberate act rather than something that quietly happens.
What a buyer can actually check
Four questions, and none of them need a demo environment
"Open an invoice from before the last rate change and tell me what rate it shows."
What you will hear
The old rate, immediately.
How to read it
Good — the rate is stored on the line. If it shows today's rate, stop the evaluation. Every historic report in that system changes when a budget passes.
"Raise me a credit note against that invoice. Where is the tax rate recorded?"
What you will hear
Either a rate field defaulting from the original, or a single total.
How to read it
A single total is extremely common and is not a scandal — but it means the tax treatment of your credits lives in your accountant's journals rather than in the system, and you should know that before rather than during a review.
"What does the system think the rate was eighteen months ago?"
What you will hear
Usually today's rate, delivered with confidence.
How to read it
Almost universal, and the honest vendors will say so unprompted. The answer to watch for is one that claims a rate history — then ask to see the table.
"When the rate last changed, what did your customers have to do?"
What you will hear
A specific, slightly weary story, or a blank.
How to read it
A vendor whose customers have lived through a rate change has a story with dates and irritations in it. A blank means they have not, which is fine — as long as you are not the one who finds out first.
And one thing that is not a software problem
Which rate applies to a given transaction across a change is a question about the time of supply and about your contract terms, and it is not always obvious. Goods ordered before a change and delivered after it; a service performed across the boundary; a deposit taken early against a supply made late. Those are questions for your accountant and for the published guidance, and a software vendor who answers them confidently in a sales meeting is selling you a liability rather than a feature.
What software can honestly offer is narrower: record what rate was used, on what date, on which document, and make it retrievable. That is enough to answer an auditor without reconstruction, and it is a smaller claim than the market usually makes.
The short version
A rate is a fact about a country on a date. Storing it as a fact about a country is correct for new documents and wrong for every new document about an old period — credit notes most of all, because those are the ones a business raises routinely and never thinks of as historic. Check that your invoice lines store the rate. Then check what your credit notes do, and what your system says the rate was two years ago. The second and third answers are usually worse than the first, and neither will announce itself.
Find one credit note that crosses a change
A credit raised after a rate change against a supply invoiced before it. Ask your system which rate it was treated at and where that is recorded. Bring the answer and we will tell you honestly what ours does with it.
Talk to us