How We Test Our Calculators

Where there is no official example yet

The table is short compared with the catalog, and that is deliberate: a row goes in only when the authority prints inputs and an answer we can reproduce. Some obvious candidates are missing, and it is better to say why than to imply they are covered.

• IRS Publication 15-T. Its percentage-method examples compute withholding from a single paycheck. No calculator on this site implements that method; the W-4 withholding calculator estimates the year's tax and compares it with what you are having withheld. Testing it against 15-T would test something it does not do.
• IRS tax tables. For taxable income under $100,000, the tax table in the Form 1040 instructions taxes the midpoint of each income band, most of them $50 wide. Our federal calculators apply the rate schedule to your exact income, so they can differ from the table by a few dollars by design.
• Social Security, HMRC income tax, the ATO and the CRA. These calculators are tested against rates and thresholds taken from the primary documents, with expected answers derived by hand. None of their tests yet reproduces a worked example those agencies print, so none appears above.

Building this page also turned up two tests whose names claimed more than their sources show. One said it reproduced a gov.uk worked example for the High Income Child Benefit Charge at £67,600; the current gov.uk guidance states the rule but prints no such example. The other described NOK 137,030 as Skatteetaten's own example; Skatteetaten's examples use list prices of NOK 279,000 and NOK 660,000. Both tests were renamed to say what they check, and the two real Skatteetaten examples were added as new tests and appear in the table.

What must pass before a change ships

The same checks run on every push to the main branch, on every pull request, and once a week on a schedule so that a table going stale is caught even when nobody has touched the code:

1. Type checking of the whole codebase.
2. The full test suite described above.
3. Registry validation: the catalog schema, duplicate and collision checks, a 1,200-word floor on each calculator page, and a check that every calculation module a page declares is one its code calls, and the reverse.
4. A count of em and en dashes in calculator content, which must be zero.
5. A production build of every page.
6. An output audit that runs every calculator and fails if a promised result is missing.
7. A mechanism audit that flags a "How this is calculated" step describing something with no trace in the code it is bound to.

The last of these exists because of a real failure. In August 2026 about 150 pages described calculation steps no code performed. No numeric test caught it, because a made-up step contains no number. The fix and the reasoning are on the About page and in the methodology.

What a passing test does not prove

A test shows the engine gives the expected answer for the inputs in the test. It does not show the calculator suits your situation, that a law has not changed since the source was read, or that the inputs you enter are the right ones. Each calculator page has a section on what it does not account for. Read it before relying on a result.

If you find a published example we get wrong, send it through the contact page with a link to the document. If it is a fair test of what the calculator does, it will be added to this table, whether it passes or not.