The Split That Cannot Be Re-Derived
The month-end spreadsheet is not the problem. The problem is that the rules inside it are not written down anywhere the system can apply again.
Almost every business filing with more than one tax authority has a spreadsheet. One month of trading comes out of the accounting system as a set of totals, and somebody applies rules to it — this is a service so it goes to that province, this customer is in that jurisdiction, these lines are federal — until the totals become several returns. It works. It has worked for years. And it has a specific weakness that is not the one people assume.
The weakness is not accuracy
The person doing it is usually good at it. The splits are usually right. If you audited last month you would probably find it correct, and if you found an error it would be an ordinary one, of the kind that also happens inside software.
The weakness is reproducibility. The rules that produced the split exist in the head of whoever produced it, in the structure of a spreadsheet nobody documented, and in a set of judgement calls about ambiguous cases that were never written down. Ask in eighteen months how a particular figure was arrived at, and the honest answer is a reconstruction rather than a record.
The distinction that matters
A derivation performed inside a system leaves a trail by construction — the inputs are stored, the rule is code, and the same inputs produce the same answer. A derivation performed outside it leaves a result. Those are different things, and only one survives the departure of the person who did it.
Two ways a stored figure fails a report, and they are not the same
| What is missing | What becomes impossible | Example |
|---|---|---|
| The parts of a total | Any report about the parts. The information was never written down. | A tax figure stored as one number when it was made of four. |
| The rule that produced a split | Repeating the split, or explaining it later. The result exists; the derivation does not. | A month of trading apportioned to five authorities in a spreadsheet. |
Why this is a reporting problem rather than a tax one
Because the same shape turns up everywhere an important number is produced by judgement rather than by data. An overhead allocation across cost centres. A revenue split across business units. A stock valuation adjustment. In each case the output goes into the system and the reasoning does not, and the reasoning is the part somebody will ask about.
The test generalises cleanly: for any figure your organization reports, ask whether the system could produce it again from what it stores. If the answer requires a person, you have a provenance gap rather than a data gap — and provenance gaps are invisible until somebody leaves or an auditor asks.
What actually fixes it
Less than a full compliance module. What makes a split reproducible is that its inputs are stored on the records themselves: which jurisdiction a line belongs to, which authority its tax is owed to, what classification decided that. Once those are attributes of the data rather than knowledge in a spreadsheet, the split becomes a query — and a query can be run again next year by somebody who was not there.
Our own system does not store them. A tax figure carries a rate and no authority, so the apportionment has to happen outside and stays outside. That work is specified and priced and it is not large, and the reason to describe it this way rather than as "multi-jurisdiction support" is that the phrase hides which of the two failures above it would actually fix.
One question for whatever you are running now
Not for a vendor — for your own operation. Ask how last year's split was produced, and whether the rules are written anywhere other than in the file itself. If the answer is a person, that is worth knowing before it becomes urgent, and it is the kind of thing that only ever becomes urgent at the worst moment.
