A tax rate written into your code is a debt with an expiry date. When the law changes — and it will — somebody has to find the number in the repository, change it, test it and redeploy. Worse than the work is the silent effect: every invoice already issued is now recalculated under the new rule, including ones that went into filed returns. The question "which rate applied to this invoice in March?" stops having an answer at all.
The alternative is to treat every tax rule as a dated, versioned record with the law cited beside it. That is how Enerxia — the oil & gas ERP we build and operate for Angola — handles VAT, withholding and petroleum tax. The mechanism is worth explaining, because it transfers to any system that has to survive an audit.
The rule table starts empty — deliberately
In a fresh Enerxia deployment, the tax_rule table holds not one row. There is no default rate, no "sensible" value pre-loaded, no leftover example from a test environment.
That sounds inconvenient until you price the alternative. A system that ships with a rate already filled in is asserting a regulatory fact nobody checked. If it happens to be right, nobody notices. If it is wrong, nobody notices either — until the first audit, and by then there are months of documents issued against a number the software vendor invented.
So the system refuses to issue the document rather than guess. A crude sale invoice with no tax rule configured does not come out with zero VAT: it does not come out at all, with a message naming exactly which rule is missing. Unknown means blocked and configurable, never a plausible-looking default.
A rate without a legal citation does not get in
Every rule carries a mandatory legal reference. Mandatory in earnest: the column is NOT NULL in the database, but that alone only stops NULL — a single space satisfies the constraint perfectly well. A rate whose citation is a space is an invented rate that passed a constraint.
So the domain layer rejects blank and token citations too. Whoever enters the rate has to write down where it comes from. Months later, when somebody asks why, the answer sits on the same row as the number — not in the memory of someone who has since left.
Changing a rule is not editing it
This is the point that separates an auditable system from one that merely looks tidy.
When a rate changes, the temptation is to open the record and correct the number. Enerxia does not allow it. A regulatory change creates a new version with an effective date; the previous version is closed the day before the new one begins. Both stay readable.
The difference is not housekeeping. Correcting version 1 in place would silently restate every transaction already assessed under it, including ones inside returns that have been filed. Closing and opening preserves the chain: an invoice issued in March is still calculated with March's rule after the rule changes in June. Reissuing an old document does not recalculate it under today's law.
That is what makes a past assessment reproducible, which is the only useful definition of "auditable".
Jurisdiction is not a free-text field
A rule's jurisdiction is taken from the company's own legal entity. It is not a parameter whoever fills in the form gets to choose.
The reason is segregation, not convenience. The tax rule table is global and has no company column — the rules of a territory are the same for everyone established in it. If jurisdiction were free text, one company's administrator could write the rules another company is assessed under. In a deployment holding several operators and service providers, that is a control problem, not an interface detail.
Two rules on the same day are not ambiguous — they are double
The system refuses two versions of the same rule in force on the same day. The reasoning is harsher than it first appears.
If two rules of the same code are active at once, "which rate applied?" has no answer. And because rules are summed rather than selected, the answer is not "one of them" — it is both, silently doubled. VAT applied twice does not fail with an error. It issues a document with a wrong number on it and carries on into the accounts.
Overlaps like this are the kind of defect feature testing never finds, because each rule is correct on its own. You find it by designing the table so the overlap cannot exist.
What this gives an auditor
Put together, the register answers four questions a spreadsheet cannot:
| Question | What answers it |
|---|---|
| Which rate applied to this document? | The version in force on the document's date |
| Who entered it, and when? | Author and creation date on the record |
| On what legal basis? | Mandatory legal reference on the same row |
| How has it changed over time? | Prior versions closed, not deleted |
None of these depends on anyone remembering anything. That is the difference between compliance as a practice and compliance as a property of the system.
What it actually costs
It is worth being straight about the cost: more work at the start. Someone in finance has to sit down and state the rules, with citations, before the system will issue its first document. An ERP with rates pre-loaded starts faster.
It starts faster and carries a risk that only surfaces later, when it is more expensive. The choice is between a day of configuration at the beginning and reconstructing months of documents at the end.
If you want to see the rule register working against real data — creating a version, superseding it by effective date, refusing an overlap — Enerxia can be opened and walked through module by module.