Why tax rates belong in a database, not in code

Ask an engineer to compute UK income tax and they will write a function: personal allowance here, basic band there, a few constants sprinkled in. It works beautifully — until Autumn Statement day, when every constant in every deployment becomes a bug waiting for a release cycle.

The alternative is treating rates as what they really are: reference data. A rate row carries its value, its thresholds, its effective dates and its source. Calculations read the rows current at run time. Nothing about the software changes when the law does.

This design pays twice. First, updates become data entry — auditable, reviewable, reversible. Second, history becomes free: re-run last year's calculation and the engine reads last year's rows, reproducing the original figures to the penny.

It also disciplines honesty. A rate row without a source citation looks naked in review, so every row documents where its number came from. Hard-coded constants invite folklore; database rows demand footnotes.

AVERQIS runs entirely on this principle — 64 HMRC-published rates across two tax years as versioned data, with the engine reading whatever is active when you press Calculate.