A single flat rate across an expense ledger is wrong by construction. How to recover the real rate per account from prior-period records, and when to refuse.
Reconstructing the tax component of a period’s expenses usually starts with an instruction of the form “the rate is such-and-such, work it back from the gross”. It is a reasonable starting point and it is wrong for a meaningful share of any real ledger.
Some supplies are exempt. Some categories carry a partial-recovery rule. Some accounts hold a mix of both. Applying one rate uniformly produces a figure that is confidently incorrect, and — because it is derived arithmetically from real gross amounts — looks entirely plausible on the working papers.
The alternative is to recover the actual rate for each account from the entity’s own prior-period records, which already contain the answer.
01 · The rate is a property of the account, not of the period
Work out the tax after the account has been settled, never before. Deriving it earlier applies a rate to rows that have not yet been categorised, including rows that will turn out not to be expenses at all.
The check — confirm the ordering in your process: classify, then code to an account, then derive tax. Any tax figure computed before the account is known is provisional at best.
02 · Recover the rate by pairing gross against net
A general ledger records each purchase twice: gross where the money left the account, and net in the expense category. The difference between the two is the tax on that transaction, and it requires no assumption whatsoever.
There is a trap in how you join those two sides. Tax split lines are typically stamped with the tax authority’s name rather than the supplier’s, so joining on the vendor name returns an enormous, meaningless set. Join on the transaction, not on the name.
The check — for each account in the prior period, pair gross and net entries by transaction and compute the implied rate.
03 · Refuse a rate when the underlying records disagree
This is the rule that makes the whole approach trustworthy, and it is the one most likely to be dropped for convenience.
Where the transactions within an account do not all imply the same rate, the correct output is not the average. An average across a mixed account is exactly the kind of plausible-looking number that is wrong for every row it is applied to.
Disagreement inside an account is usually real information. An account of otherwise ordinary purchases containing one supplier at a different rate frequently means that supplier’s charge is not a taxable supply at all — a penalty or a levy rather than a purchase. That is a genuine distinction worth surfacing, not noise to be smoothed away.
The check — derive a rate only where every transaction in the account agrees. Where they do not, report the account and the disagreeing entries and let a person decide.
04 · Skip transactions that span several accounts
A payment that splits across categories — a repayment separating into principal and interest, for instance — has a single gross figure covering multiple destinations. The gross-minus-net method cannot apportion it, and attempting to will assign the entire difference to whichever line happens to be processed first.
The check — identify multi-destination transactions and exclude them from rate derivation entirely. They are a small share of any ledger and including them corrupts the accounts they touch.
05 · A rate that looks wrong may be correct
Some categories legitimately produce a rate that is a fraction of the headline one, because a partial-recovery rule applies to them. Entertainment-type expenses are the usual example.
The derived figure will look like an error to anyone expecting the standard rate. It is not, and “correcting” it introduces a real error in place of a correct result.
The check — before adjusting any derived rate that looks anomalous, establish whether a recovery rule explains it. Record the explanation next to the figure so the same question is not reopened next period.
06 · Distinguish “checked, none” from “not captured”
A blank tax figure and a zero are different statements and they must not be conflated.
A zero says the document was examined and carries no tax. A blank says nobody has established anything yet. Writing zero where the truth is blank understates a claim while appearing complete; leaving blank where the truth is zero sends finished work back for review.
Where the account has not been settled, neither is correct — the honest value is an explicit marker meaning the question is still open.
The check — use three distinct states, not two, and make sure the deliverable’s totals treat the open state as unresolved rather than as zero.
Why the derived figure is worth the effort
The output of this approach is not just a set of numbers; it is a set of numbers each of which can be traced to the entity’s own prior records. Where a figure is questioned — and tax figures are questioned — the answer is a specific set of historical transactions rather than an assumption somebody made.
That property is worth as much as the accuracy. Carrying a short provenance note alongside each derived rate turns a later query from an investigation into a lookup.
What makes a derived rate trustworthy
Deriving a rate from history is only better than assuming one if the derivation is itself disciplined. A rate recovered from a thin or unrepresentative slice of the past is an assumption with extra steps, and it is more dangerous than an open assumption because it looks like evidence.
Four conditions worth holding to.
Enough observations to distinguish a pattern from an accident. One or two prior transactions on an account establish nothing; a coincidence at that sample size is likely rather than remarkable. The threshold does not need to be large, but it needs to exist and be stated.
Consistency within the window, not just a majority. If prior transactions on an account split between two rates, the correct reading is usually that the account genuinely carries both — a mixed category, or a rate change partway through — rather than that the minority is noise to be discarded. Taking the majority silently converts a real distinction into a systematic error.
Awareness of rate changes inside the window. A rate that changed mid-period will produce exactly the split above, and the two cases have to be told apart by date rather than by frequency. A derivation that ignores when each observation occurred will average across a change and produce a rate that was never correct at any point.
A stated basis per account. Which transactions, over which period, produced this rate. This is the part that converts a later query into a lookup, and it costs nothing at the time it is recorded.
Where any of the four fails, the account belongs on the exception list. That list is the deliverable working correctly, not a shortfall in it.
Where this fits in a firm’s work
This is a reconstruction problem, which means it arrives with catch-up and cleanup engagements rather than with routine compliance. That is worth noting, because reconstruction work is exactly where the pressure to assume is strongest: the records are incomplete by definition, the deadline is usually inherited, and an assumed rate makes the file finishable today.
The trade being made in that moment is a bad one. Assuming produces a complete-looking set of figures containing an unknown number of unmarked estimates. Deriving produces a slightly smaller set of figures that can each be traced, plus a short list of accounts that need a decision — and the second deliverable is the one that survives a query.
It is the same distinction that governs whether cleanup work can be quoted at all, covered in why bookkeeping cleanup always takes longer than you quoted: the difference between a result and a result you can stand behind is whether the uncertain parts are marked.
For ledgers large enough that this cannot be done by inspection, deriving rates per account from prior-period data is a contained piece of work that removes an entire class of assumption. We build it into bookkeeping cleanup automation.
Questions this raises
Why not apply the standard rate and adjust later if needed?
Because "later" has no trigger. An assumed rate produces figures that look exactly like derived ones, so nothing prompts anybody to revisit them. The adjustment happens only if someone independently notices a discrepancy, which for a rate error spread evenly across a ledger is unlikely.
How far back should history go to derive a rate reliably?
Far enough to include a rate change if one occurred in the window, and enough transactions per account to distinguish a pattern from a coincidence. A handful of prior transactions on one account is a weak basis; the honest response there is to report the account as underivable rather than to derive it thinly.
What happens to accounts where history does not settle it?
They are reported, with the evidence that was available and why it was insufficient. A short list of accounts needing a decision is a usable deliverable. A complete set of figures where some are assumed and indistinguishable from the rest is not, because it cannot be reviewed proportionately.
Is a derived rate defensible if the figure is later questioned?
More defensible than an assumed one, which is much of the point. A derived rate resolves to a specific set of prior transactions in the entity own records, so a query becomes a lookup rather than an investigation. Carrying that provenance note alongside each rate costs nothing at the time and saves a great deal later.