A Tax Rate Nobody Remembered to Change
A rate that was right when the product was priced and is not right now, with every invoice since carrying the old one. What a rate on a record has to be, a value with a date and a source, and why editing it in place destroys the evidence.
A rate was correct when you priced the product. Something changed. Nobody went back and edited the rate, because the rate lives on the product and the product has been selling well and nobody has opened it in a while. And then, one day, a customer queries an invoice, or a report shows a tax total that does not sit right next to a target, and the question becomes: which invoices carried the old rate.
The reason that question is hard is not that the change was forgotten. It is that the rate on a record, as most systems store it, has no memory of being a rate at all. It is a value. It was set once and read forever. A value cannot tell you when it was set, by whom, on what basis, or whether it was ever revisited.
So the invoices in question are not wrong in any way the system can express. They each faithfully reproduce the value that was on the product record on the day they were raised. What they lack is any way to say that the value was later found to be wrong, and to link the two facts together.
This article is about what a rate on a record has to be if the answer to that question is going to be available later: a value with a date and a source. It is a record-keeping argument, not a tax argument. NoxOrigin does not file GST returns, does not generate or submit returns, is not a tax authority, and is not certified, and nothing in this article decides what the correct rate is. That belongs to your chartered accountant.
A rate with no date is not a fact, it is a number
Consider the difference between two ways of holding a rate. The first is a field on the product that says eighteen, and the invoice reads it at the moment of raising. The second is a sequence of dated rate versions, each with an author and a source, and the invoice reads the version in force on its own date.
On a quiet day these look identical, because both print the same number on today's invoice. They diverge the first time anything changes, and they diverge in a way that is not recoverable afterwards.
With the first, changing the field rewrites the past. The invoice raised in January, which genuinely carried eighteen, now reads whatever the field says, because the field is the only place the number ever lived. There is no version, so there is nothing to look up. You can either change it and lose the record of the old rate, or leave it and have every future invoice carry a rate you know to be wrong. Both options are bad, and neither is a bug.
With the second, changing the rate appends. The old version stays, the new version is added, and every invoice points at the version that was in force on the day it was raised. A later question about a January invoice can be answered by looking up January, and the answer is the same number the customer received.
Illustrative: editing a rate in place versus holding a rate as a dated version
| Rate as a plain value | Rate as a dated, sourced version | |
|---|---|---|
| When it is corrected | The field is overwritten and the old value is unrecoverable | A new version is recorded and the old version stays readable |
| An invoice raised before the change | Reads the current value, so the document and the record disagree | Reads the version in force on its own date, so the document stays as issued |
| Which invoices carried the old rate | Not answerable without reconstructing from memory and paper | A query over invoices whose date falls in the old version's period |
| Why the rate is what it is | Unknown, because nothing recorded a reason | Recorded once, with an author and a source, and visible to the next person |
| A credit note against an old invoice | Calculated at whatever the field says now, which may not match the original | Calculated from the same version as the original, so the reversal mirrors the entry |
A worked example, constructed so you can check the arithmetic
Everything in this section is constructed. It does not describe a real business, a real product, or a real compliance outcome, and it implies no rate, slab, threshold or classification. The 18% figure is used, and only used, so that you can check each line of arithmetic by hand. The 12% figure is a constructed second rate, invented for this example so that a before-and-after comparison is checkable; it is not a claim about any tax rate that exists.
Suppose a product carries a taxable value of Rs 12,500 and a rate of 18%. The tax on one unit is 12,500 multiplied by 0.18, which is Rs 2,250, and the line total is Rs 14,750. Now suppose 96 units were sold at that rate before anyone noticed the rate needed revisiting.
Tax recorded across those 96 units is 2,250 multiplied by 96. Work it in stages so the arithmetic is checkable: 2,250 multiplied by 100 is 225,000, and 2,250 multiplied by 4 is 9,000, so 225,000 minus 9,000 is Rs 216,000. That is the quantity of tax your records carry at the original rate.
Now suppose the rate is revisited and your chartered accountant confirms the treatment that should have applied, expressed in this constructed example as 12%. The tax on one unit is 12,500 multiplied by 0.12, which is Rs 1,500, and across the same 96 units that is 1,500 multiplied by 96, which is 1,500 multiplied by 100 minus 1,500 multiplied by 4, so 150,000 minus 6,000, which is Rs 144,000.
The difference is 216,000 minus 144,000, which is Rs 72,000. Check it a second way: the per-unit difference is 2,250 minus 1,500, which is Rs 750, and 750 multiplied by 96 is 72,000. Both routes give the same figure, which is the only reason to trust either.
This number means one thing and one thing only: it is the arithmetic difference between the tax recorded and the tax your records would carry under the different treatment, for this constructed set of 96 units. It is not a penalty, it is not a liability, it is not a deadline, and it is not a statement that anything is owed. What it does mean is that the question of what follows from 96 invoices raised at a rate that was wrong is a determination for your chartered accountant, and that the amount at issue is a countable quantity in your records rather than a matter of recollection.
The obvious next number is 72,000 divided by 216,000, and this article will not print it, because a ratio invites the reader to treat a constructed relationship as a frequency or a severity, and the arithmetic supports neither.
What a rate on a record has to be: a value, a date, and a source
Three things, and the second and third are what everyone leaves out.
The value is the easiest and the least interesting. The date is what makes the value mean something: a rate is not a property of a product, it is a property of a period. The source is what makes it defensible: where did this number come from, and who decided it applies. A source might be a decision by the owner, an instruction from your chartered accountant, a rate card version, a written confirmation from the customer, or a product classification decision made once and applied since.
The source is the field that most often does not exist anywhere, in software or on paper, because nobody thinks of a rate as something that needs a reason. The consequence is that when the rate is questioned, the only available answer is a person remembering, and a person remembering eleven months later is not a record. The system that has the source can print the answer; the system without it can only escalate to a human, and the human may no longer be there.
None of this requires the system to know any tax rule. It requires the system to know who said so and when, which is bookkeeping, and bookkeeping is a thing software is genuinely good at.
What a rate on a record should carry, and what you should be able to ask it
- The value itself, held separately from the line total so the arithmetic on the line is visible rather than implied.
- The date the version came into force, so an invoice can be matched to the version that was in force on its own date.
- The date the version was entered, which is not the same as the date it came into force, and the gap between them is a question rather than a rounding error.
- The person who entered it, named rather than shared, because a judgement needs an author.
- The source, in the form that will still mean something in two years: a decision, an instruction, a rate card, a written confirmation, or a classification decision.
- The previous version, retained and readable, with the period it applied for.
- A way to list the invoices raised under a given version, so the question has an answer that is a query rather than a memory.
Why in-place editing also breaks the credit note
A credit note or return is a reversal, and a reversal has to mirror the entry it reverses. If an invoice was raised at one rate and the rate is later corrected in place, a credit note computed from the current field no longer mirrors the original, and the two documents stop agreeing with each other in a way that nobody will notice until somebody tries to add a quarter up.
This is the same principle our note on storno accounting describes in its European context, where the practice is to cancel a booked entry with an equal and opposite reversal rather than to delete it. The principle travels well: a reversal that mirrors the original keeps the history readable, and a correction that overwrites the original takes the history with it.
The practical test is short. Take any invoice and its credit note. The taxable value, the tax, and the total on the credit note should be the exact negation of the invoice. If your system can only produce that if nobody has touched the rate since, the rate is not being versioned, and the credit note is exposed to the same problem as the invoice.
How a stale rate actually gets found, and how late you will find it
The honest answer is that a stale rate is found late, and the reason is structural rather than human. Nobody opens a product record between sales. The rate is not visible at the counter, because the person at the counter is looking at a customer and a total, not at a tax classification. The rate is not visible in a daily report either, because a daily report aggregates and aggregation hides a single wrong line among many right ones.
It surfaces through three channels in practice: a customer who queries an invoice because their own figures differ, a report where a tax total looks odd next to a period where it should look similar, or an accountant who asks a question that requires the history and finds there is none to give. All three are late. None of them is avoidable, and the only lever available is the size of the period you discover it over, which is exactly what a dated rate version reduces.
It also helps to be clear that a product-level rate is not the only place a stale value lives. A discount basis, a rounding convention, a price inclusive or exclusive of tax, and an invoice numbering scheme are all the same kind of field, and all of them go stale the same way. If your system versions the rate, the same mechanism usually handles the others, which is worth asking about directly during a test rather than assuming.
Two related reads are worth pairing with this one. Our guide to what a billing engine actually is covers the rules layer around tax and totals in more depth, and the field-by-field checklist for GST invoice fields is the practical companion for testing a system against a document rather than against a feature list. The buying question around the whole system is covered in how to choose GST billing software for a small business in India. None of them is a substitute for your own chartered accountant, and none should be read as guidance on treatment.
The one-line version. A rate on a record is a value with a date and a source, not a value you edit. Editing in place rewrites the past: old invoices stop matching the record, the set of invoices affected by the old rate stops being a query, and credit notes stop mirroring their invoices. Appending a version keeps all three possible. Whether the old rate was correct, and what follows from invoices raised at it, is a determination for your chartered accountant. NoxOrigin records the value, the date, and the source, and prepares nothing statutory.
Two further ways a tax record stops matching reality. the tax identity that changed mid-year the invoice nobody can reconcile at quarter end
Frequently asked questions
What should a tax rate on a product record carry besides the value?
A date it came into force, a date it was entered, the person who entered it, and a source: a decision, an instruction from your chartered accountant, a rate card version, a written confirmation, or a classification decision. The source is the field most often missing, and without it a questioned rate can only be answered by a person's memory.
Why is editing the rate in place so bad?
Because the old value is the only record of what the earlier invoices carried. Overwriting it means an invoice raised in January can no longer be shown to match the rate that was in force in January, the set of invoices affected by the old rate stops being a query, and a credit note raised later can stop mirroring the invoice it reverses.
Can I work out the tax difference myself?
You can work out the arithmetic difference between two rates on the same taxable value, and any system can do that. You cannot work out which rate applies, or what follows from invoices raised at the wrong one. That is a determination for your chartered accountant, and the arithmetic is only useful because it tells them the size of the question.
Does NoxOrigin know tax rules or suggest a rate?
No. NoxOrigin records the rate that was applied, the date, the document, and the version of the product record in force on that date. It does not know tax rules, does not compute a place of supply, does not handle reverse charge, and does not prepare, generate, or submit any statutory return. NoxOrigin is not a tax authority and is not certified.
How do I find out which invoices carried the old rate?
By date, if rates are versioned: every invoice raised between the date the old version came into force and the date the new one did. If the rate was a plain field with no history, the only route is reading the documents, which is a person's afternoon rather than a query.