How we check our figures

Anyone can publish a calculator. The useful question is what stands behind the number it gives you. This page describes the verification actually in place on this platform, and — just as importantly — what it does not prove.

The architecture

The platform is deliberately built in layers that can be checked separately. Presentation is kept apart from calculation, and calculation is kept apart from the rules it applies. That separation is what makes verification possible at all: you cannot meaningfully test arithmetic that only exists inside a page.

1. A calculator registry

Every calculator is declared in a single registry with its identifier, name, public address, category, jurisdiction and whether it is rules-sensitive. The registry is validated automatically: identifiers and public addresses must be unique and well formed, categories must be real, and a calculator only becomes visible on the site once a calculation engine actually exists for it. That gate is why an unfinished calculator cannot appear as though it were finished.

2. Deterministic calculation engines

The arithmetic lives in code that takes inputs and returns outputs, with no dependence on the browser, the page or anything ambient. The same inputs always produce the same outputs. Inputs are validated at the engine boundary, so an out-of-range or nonsensical value produces a clear error rather than a confidently wrong number.

3. Versioned UK rules

Rates, thresholds and bands are held as data tied to a named tax year, not scattered through the code as bare numbers. Progressive band arithmetic — the kind used for Income Tax, National Insurance and Stamp Duty — is implemented once and shared, so a band boundary behaves the same way everywhere rather than being reimplemented, slightly differently, in a dozen places.

4. Independently derived benchmark cases

This is the part that does the heavy lifting, and the detail that matters is the word independently.

Each calculator has reference cases: a set of inputs with the expected outputs stated alongside. Those expected values are derived from the rules themselves — worked out from the legislation and official guidance — rather than produced by running the code and recording whatever came out. A benchmark generated from the implementation cannot detect an error in that implementation; it only proves the code still agrees with itself. Deriving the expected value separately is what turns the suite into an actual check.

Benchmark expectations are treated as fixed. When code and benchmark disagree, the disagreement is investigated and one of them is proved wrong. Editing an expected value so a failing test passes is the one move that would hollow out everything else on this page.

5. Automated regression suites

The repository maintains several suites that run together before any release:

Reference benchmarks execute every calculator against its derived expected values.
Unit and integrity tests cover engine behaviour, registry validity, rule data, input validation and edge cases.
Content verification re-runs the engine against the exact inputs behind every published worked example and fails if any published figure no longer matches. Published explanation cannot drift away from the arithmetic it describes.
Browser-level parity checks drive the real pages in a real browser and confirm that what a user sees matches what the engine computed — closing the gap between a correct engine and a field wired to the wrong input.
Route and metadata checks confirm that pages resolve, that canonical addresses are correct, and that the sitemap matches what is actually published.
Automated accessibility scans run Axe against calculator and content pages to catch accessibility regressions.
Type checking and build verification run across the whole repository, so a change that breaks a contract between two parts of the system fails before it can reach the site.

6. Source verification

Rule-sensitive figures are checked against primary official sources, under a hierarchy that determines what a given source is allowed to prove:

Tier 1 — Primary official sources. Required for every statutory figure. A Tier 1 source is the only kind that can stand on its own as authority for a tax rate, threshold, benefit amount or statutory formula.
Tier 2 — Authoritative institutional sources. Used for explanation, corroboration and worked context. A Tier 2 source may clarify how a rule is applied in practice, but it may not be the only evidence behind a statutory value.
Tier 3 — Secondary explanatory sources. Background reading only. A Tier 3 source is never sufficient evidence for a rule-sensitive figure, and search-result snippets and AI-generated summaries do not count as sources at any tier.

A source's tier is determined by the body that published it, not by an author's judgement of how authoritative it felt. Where a figure has not been confirmed against an official source, the guide says so on the page instead of presenting it as verified. The editorial policy sets out how inaccessible sources and conflicting sources are handled.

Verification snapshot

Test totals change as the platform grows, so they are published as a dated snapshot rather than as a permanent claim. The figures below come from suites actually executed on this date, not from a planning document.

Verification snapshot — 26 August 2026

253

Calculators published

Editorial coverage, stated honestly

Automated verification covers every published calculator. Authored editorial guides — with methodology, a verified worked example, assumptions, limitations and cited official sources — currently cover 40 of 253 calculators, concentrated on the rule-sensitive and most-used tools where the explanation matters most.

We are not going to describe that as full editorial review, because it is not. A calculator without a published guide still runs on the same verified engine and the same benchmark cases; what it lacks is the written explanation and the source citations. Coverage is stated here so you can see exactly where the platform stands.

51 of 253 calculators depend on rules that change when legislation changes; the remaining 202 apply general mathematical or scientific methods that do not move with a Budget.
Guides cite 109 official sources, of which 86 are Tier 1 primary official sources and 23 are Tier 2 authoritative institutional sources.
3 guides carry at least one figure still marked as requiring source verification, and say so on the page.
Published guides were last reviewed against their sources in August 2026.

Review and maintenance

Rule-sensitive content falls due for review at the start of each UK tax year, which is when its figures actually go stale — rates change on 6 April, not a fixed number of months after somebody last read the guidance. General content is revisited on a fixed cycle to catch link rot and drifting explanation. Budgets, mid-year statutory changes and benefit or pension uprating trigger review outside that cycle.

Review dates shown on calculator pages are derived from the editorial content itself rather than kept in a separate list. A review date therefore cannot exist for a review nobody performed.

What this does not prove

Verification reduces risk. It does not eliminate it, and a page like this one is worth very little unless it says so.

Benchmarks cover cases somebody thought of. A large, independently derived suite catches a great deal, but no finite set of cases can prove that every possible combination of inputs produces a correct result.
Legislation changes, sometimes without warning. Rates and thresholds move at Budgets and fiscal events, and occasionally mid-year. There will be periods between a change taking effect and this platform reflecting it.
Every calculator simplifies. Real tax and benefit law is full of interactions, reliefs, elections and edge cases that a general-purpose tool does not attempt to model. Where your circumstances exceed the stated assumptions, the result will not describe your position.
Correct arithmetic is not the same as the right answer for you. A calculator can apply its model perfectly and still give you a figure that is wrong for your situation, because the model was never built for it.
Automated accessibility testing has limits. Axe catches many defects, but automated scanning cannot substitute for testing with real assistive technology, and we do not claim to have completed formal external accessibility certification. See our accessibility statement.

We do not guarantee that any calculation is accurate, and nothing here is financial, tax, legal or medical advice. Where a decision carries real consequences, check the result with someone qualified to advise on your circumstances. See the disclaimer.

Found something wrong?

Reports of suspected errors are prioritised, and a report with the inputs you used, the result you saw and an official source supporting the figure you expected can be investigated straight away. The contact page explains what to include. Corrections already made are recorded on the updates page.