Calculation methodology

Every calculator has two distinct steps. The first takes whatever was typed and either coerces it into a valid input or returns the specific problems with it. The second is a pure calculation over an input already known to be valid — it reads no clock, no locale and no external state, and returns the same answer for the same input every time.

The practical consequence is that a calculator cannot half-fail. Either you get a complete answer or you get told exactly which field is wrong; there is no path that produces a plausible number from input that was never checked.

It is also what lets the identical calculation run on this page, inside an embedded widget on a customer’s site, and in the test suite — with results verified byte for byte across all three.

Calculations run at full precision. Rounding happens once, when a figure is shown.

This matters more than it sounds. A thirty-year monthly loan schedule has three hundred and sixty periods; rounding each one to the nearest cent and carrying the rounded figure into the next accumulates an error that shows up as a final payment that does not clear the loan, or a total interest figure several dollars away from the truth. Amortising exactly and rounding at the end avoids the whole class of problem.

Where a regulator specifies its own rounding — several duty scales round the dutiable value to a multiple before applying the rate — that rounding is part of the rule and is applied as the authority specifies. Statutory rounding is not a display choice, and it is not overridden by ours.

Most calculators here are arithmetic: a repayment, a ratio, a projection. A few depend on rates somebody else publishes — transfer duty, income tax, the Medicare levy — and those are handled differently.

Each is a rule set: a versioned record holding the rates, the jurisdiction it applies to, the period it is in force for, the assumptions built into it, and at least one primary source naming the authority’s own publication with the date it was retrieved. There are currently 11 of them.

A calculator does not name a rule set or a version. It names the domain it needs — “transfer duty”, “income tax” — and which revision applies is decided at calculation time from the market, the jurisdiction and the date you supplied. Freezing a calculator to one revision of the law is exactly what this avoids.

Rates change. Transfer duty is assessed against the scale in force when the contract was entered into, and income tax against the rates for the income year concerned — not against whatever applies today.

So the date is an input, not an assumption. A purchase contracted last July is assessed against last July’s scale, and a projection into a future year where rates have already been legislated uses that year’s scale rather than this year’s. A calculator that only knows today’s rates gives a confidently wrong answer to anybody asking about any other date, with nothing to indicate it has.

The date you enter also decides what is shown in the rates panel on the page, so you can see which scale produced the number.

The same inputs and the same date always produce the same result. Nothing here consults a clock during a calculation, nothing depends on where it is run, and no result is affected by anything that happened before it.

Rule sets are version-controlled alongside the code, so the state of the rules at any point is recoverable. A change to a rate is a new version with its own effective period rather than an edit to an existing one — which means a calculation made against the old scale can still be reproduced after the new one is added.

Regulatory sources were last checked on 2026-08-30.

Every calculator states its own assumptions and limitations on its own page, because they differ. Some limits are shared: