A Total You Cannot Report On
A stored sum can be charged, reconciled and audited. It cannot be broken back into the things it was made of — and that is a reporting limit, not a tax one.
There is a category of limitation that never shows up during an evaluation, because everything you ask for during an evaluation works. You raise documents, the totals are right, the ledger balances, the audit trail is complete. The limit appears months later, when somebody asks a question the data cannot answer — not because it was recorded wrongly, but because it was recorded as one number when the question needs three.
Addition is lossy
This is obvious when stated and almost never designed for. If you store 4 + 3 + 2 as 9, you can still charge 9, reconcile 9, and prove 9 was correct. What you cannot do is recover the 4. Every report that needs the 4 is now impossible, and no amount of querying fixes it, because the information is not somewhere awkward — it was never written down.
Our invoice line stores one tax figure. In most markets that figure has one component, so nothing is lost and the design is right. In Brazil the figure routinely has four or five components owed to three levels of government, and storing the sum discards which was which. We wrote about the cardinality itself in a companion post; this one is about what happens downstream, which is where anybody actually feels it.
The four questions a stored sum cannot answer
| The question | Why the sum cannot answer it |
|---|---|
| How much did we owe each authority this period? | The split by levying government was never stored, so there is nothing to group by. |
| Does what we remitted match what we charged? | You can reconcile the total against the total. You cannot reconcile a state payment against the state portion of an invoice that never held one. |
| What did the change do to us? | A rate or base change affecting one component shows up only as a movement in the sum, mixed with everything else that moved. |
| Which customers or products drive which tax? | The sum is attributable to a customer and a product. Its parts are attributable to nothing. |
Why this is a reporting argument and not a tax one
It is tempting to file this under compliance and move on. That would miss the useful part, because the same shape appears everywhere once you know to look for it, and almost none of the instances are about tax.
A landed cost stored as one number cannot be reported as freight versus duty versus handling. A payroll cost stored as one number cannot be split into gross versus employer contribution. A discount stored as one number cannot say which of three promotions produced it. In each case the arithmetic is right, the total is defensible, and an entire class of question has been quietly foreclosed at the moment of writing.
The test that generalises
For any figure a system stores, ask: was this computed from parts, and are the parts stored too? If the answer is "computed from parts, stores the result", every report about the parts is already impossible and nobody will discover it until they need one.
What we do hold, which is worth knowing before you conclude
Two things, and they matter to how bad this actually is for you. The rate on each line is stored on the line as a figure captured when the document was raised, so history does not drift when a reference table is edited later. And reports run against a period rather than against a snapshot, so a prior year can be reproduced rather than reconstructed — which through a multi-year tax transition is the difference between answering a question and rebuilding it.
So the honest summary is narrow rather than sweeping: we are good at telling you what a period looked like, and we cannot tell you what a tax figure inside it was made of. If your accounting practice composes and decomposes that outside the system today, nothing here changes for you. If you need the system to hold it, it does not, and that is a data-model change with a specification and a price rather than a setting somebody has hidden.
Two minutes, on any system
Ask for a report of tax owed by authority for last quarter. Not a tax report — a report grouped by who the tax was owed to. It is the cheapest possible probe for whether a system stores components or a sum, and unlike most evaluation questions it has an unambiguous answer: either the grouping exists or it does not.
