Accuracy and testing
A tax calculator is a piece of software, and software is wrong in predictable places. This is what is done about that.
Last reviewed
Every calculation on the network is written as a plain function, separate from the interface that displays it, for one reason: a function can be tested against known answers and an interface cannot. The tests below run on every change, and nothing reaches a live site until they pass.
What is tested
- Boundary tests. Tax code is a series of edges — the income at which a band starts, the dollar at which a phase-out begins, the cap that stops a contribution being deductible. Off-by-one errors hide precisely there and nowhere else, so tests are written on both sides of every edge rather than at comfortable round numbers in the middle of a band.
- Official worked examples. Where the tax authority publishes a worked example, its inputs are run through our implementation and the outputs compared. A disagreement is treated as our defect until the authority's example is shown to be the outlier.
- Historical tax-year tests. Superseded years are asserted with the values that were in force at the time. This is what stops a rollover from quietly rewriting last year's answer — the year someone amending a return actually needs.
- Rollover smoke tests. Every site carries a test that fails when a new tax year has been applied to part of the site but not all of it. A half-applied rollover is the most dangerous failure mode here, because every page still looks correct.
- Regression tests. A reported error becomes a test before it becomes a fix, so the same defect cannot return unnoticed.
Checks that run at build time
Some classes of error are not calculation errors but publishing errors, and they are caught by checks that fail the build rather than by review:
- Internal links that point at a page which no longer exists.
- Pages that nothing links to, and so can be reached only by a crawler with the sitemap.
- Pages missing from a site's own index of calculators, which makes them unfindable on-site.
- Silent changes to a page's title or description, which are recorded and must be changed deliberately rather than as a side effect of other work.
The current numbers
These counts are derived from the five repositories rather than typed in — a script reads each site and writes the figures this page renders. They were last refreshed on 2026-08-16.
| Site | Calculators & tools | Automated test files |
|---|---|---|
| AusTax Tools · Australia | 371 | 524 |
| CA Tax Tools · Canada | 237 | 140 |
| NZ Tax Tools · New Zealand | 149 | 121 |
| UK Tax Tools · United Kingdom | 192 | 145 |
| US Tax Tools · United States | 411 | 315 |
| Network total | 1,360 | 1,245 |
Elsewhere on this site the same figures appear rounded down — 1,300+ calculators and tools, 1,200+ automated test files — so that a claim made in prose stays true as the sites grow between refreshes.
Two caveats about what these numbers mean. The calculator count is the number of entries in each site's own index of calculators and tools, which is checked at build time against the pages that actually shipped; it is a count of things a visitor can reach, not of unique calculation engines, since one engine often powers several pages. The test count is a count of test files, each containing many individual assertions — it is the figure that can be stated without interpretation, and it is deliberately not dressed up as a coverage percentage.
What testing cannot do
Tests prove that the code implements what we believe the rule to be. They cannot prove that belief is correct: a rule misread at the source is implemented faithfully and tested happily. That is why the source hierarchy puts official worked examples in it, and why the corrections policy exists. If you have found an answer that disagrees with your tax authority, that report is worth more than any test we could have written.