Methodology and exactness

The checks, in numbers

• 7 436recorded arithmetic calls verified against the server
• 5 003recorded money operations verified against the server
• 12exactness tests covering every calculation engine

These figures are not typed in by hand: the page reads them at build time from the very fixture files and tests the engines are checked against. When a fixture changes, so does this page.

Why calculators lose kopecks

Most calculators compute in floating-point numbers. Their error is relative: invisible on small amounts, it grows with the sum — on very large balances the distance between two representable numbers exceeds a kopeck, and the figure simply cannot be written more precisely. The everyday 0.1 and 0.01 are infinite in binary altogether, so even plain addition of prices accumulates dust in the last digits.

The other route is to count in kopecks, or with a fixed number of decimal places. It is more honest, but it breaks on rates: the monthly share of an annual rate is a division by 1200, and the fraction 1/1200 has no finite decimal form. However many digits you keep, every month the calculation drops a tail — and over a long term the kopecks drain away.

The shortest example: 1 ruble at 1% per year for six months. The true result is exactly 1.005 rubles — a rounding tie, which by the common rule goes up, to 1.01. Any fixed-precision calculation lands just below — 1.00499… — and reports 1.00, one kopeck short. Floating-point numbers fail similar examples from the other side.

How Amortiva computes

An amount at rest — stored, shown on screen or sent to the server — is kept as a whole number of currency units plus a whole number of billionths of a unit, with no binary fractions. Arithmetic over such amounts runs on integers of arbitrary length: ten million rubles in billionths already overflow an ordinary number, so ordinary numbers take no part at all.

While a calculation is running, an amount lives as an exact fraction — numerator over denominator. Adding, subtracting, multiplying and dividing exact fractions is exact by definition: nothing is dropped and nothing accumulates, however many steps the schedule has.

Rounding happens once, at the very end, from the true value — to the decimals of the specific currency: two for the ruble, zero for the yen, three for the dinar. One rule holds across the product: halves round up. There is no double rounding — first to some intermediate precision, then to kopecks — which is exactly what produces the familiar 'a kopeck went missing somewhere'.

A rate is never divided in advance. A monthly accrual is balance * rate / 1200, computed as one exact fraction — not a pre-rounded "monthly rate" that would carry its error before the balance is even multiplied.

Why the browser and the server return one result

Every calculation runs twice: in the browser — instantly, as you type the figures — and on the server, when a report is saved to an account. These are different programming languages, and "almost identical" arithmetic between them would drift by a kopeck at the very first rounding.

So the equality is not assumed — it is recorded. Thousands of real arithmetic calls are captured from the browser engine: the arguments and the exact answer of each. Those records live in both repositories, and the server implementation must reproduce every answer exactly; the control is a SHA-256 digest of the file, pinned into the checks on both sides. Changing one copy without the other fails the build before the change can ship.

Rate and ratio arithmetic — 7 436 calls, SHA-256: be56be53bfd0a6a6ec5e7fb66a9097ae96d427aad12b84a8cd7f63a0a32212c8

The money type and exact fractions — 5 003 operations, SHA-256: 2f2c42246a0fa42c4550a6bc1997d9e7311037496c803f6b5b58a284a64cda36

Proven on every engine

Every calculation engine ships with an exactness test: it independently replays the same projection in exact fractions and requires agreement to the last kopeck. The comparison is between whole kopecks, never approximate numbers — above 2^53 kopecks an approximate comparison would silently pass exactly the cases the check exists for.

The check is not a formality. When the engines were converted to exact arithmetic, the old floating-point version was run against the exact reference on 3,024 input combinations: it was wrong in 22 of them, in the worst case by 2.93 rubles. The current engine is wrong in none.

If a schedule does not match the bank

Exact arithmetic does not mean the figures will match any bank's statement: a bank computes by its own contract, and the contract may hold different rules. The usual sources of discrepancy:

• The year basis. We accrue interest over actual days and the actual length of the year — 365 or 366. Some contracts count the year as 360 days, or always as 365; in a leap year that alone makes a difference.
• The payment shift. When a payment date falls on a weekend, the bank collects on the next business day — and the added days accrue interest a 'calendar' schedule does not show.
• The allocation order. On a partial payment the bank distributes the money by the contract's rules — fees, penalties, interest, principal — and its internal rounding at each step may differ from ours.
• The calculation date. A schedule is built for the date you entered; the bank's statement is built for the date the money actually moved. A day of difference is a day of interest.

If the discrepancy is more than a few kopecks, that is a reason to open the contract and ask the bank which rules it computes by. Our schedule follows exactly the terms you entered, and the formula behind every figure can be checked by hand through the "how it is calculated" hints beside the results.