Money arithmetic: paise, rounding and splits

Money in code needs three decisions that binary floating-point numbers make silently, and wrongly. The first is the representation: an amount is a whole number of minor units, such as paise or cents, or a decimal value, and it always carries its currency. The second is rounding: when a result falls between two paise, a named rounding mode decides, at a named place, per line or per invoice. The third is splitting: when a total is divided, the paise left over are handed out by a fixed rule, so the parts add back up to the total. Tax rates and fees are inputs to these rules, kept as configuration with the dates they apply from.

Why a float loses paise, and what keeps them

A binary float stores fractions as sums of halves, quarters and eighths, so 0.1, 0.2 and most amounts of paise or cents are kept as the nearest binary value, not exactly. The errors are tiny, but they add up, and they surface where money is least forgiving: in totals that compare unequal and in splits that do not add up. A short script shows both, beside the integer and decimal versions that keep every paisa:

"""0.1 + 0.2 in binary floating point, then 1,000 rupees split three ways: as a float, as shares rounded to
whole paise one by one, and as paise allocated so that the shares add up to the bill."""

from decimal import Decimal


def rupees(paise):
    """Formats a whole number of paise without ever making a float."""
    return f"{paise // 100:,}.{paise % 100:02d}"


print("0.1 + 0.2 as floats:           ", 0.1 + 0.2)
print("10 + 20 paise as integers:     ", 10 + 20)
print("Decimal('0.1') + Decimal('0.2'):", Decimal("0.1") + Decimal("0.2"))
print()

bill = 100_000  # 1,000 rupees, in paise
print("1,000 rupees / 3 as a float:   ", 1000 / 3)
each = round(bill / 3)  # every share rounded to whole paise on its own
print(f"each share rounded to paise:    {rupees(each)} x 3 = {rupees(each * 3)}, one paisa short")
base, left = divmod(bill, 3)
shares = [base + 1 if i < left else base for i in range(3)]
print(f"allocated:                      {' + '.join(map(rupees, shares))} = {rupees(sum(shares))}")

0.1 + 0.2 as floats:            0.30000000000000004
10 + 20 paise as integers:      30
Decimal('0.1') + Decimal('0.2'): 0.3

1,000 rupees / 3 as a float:    333.3333333333333
each share rounded to paise:    333.33 x 3 = 999.99, one paisa short
allocated:                      333.34 + 333.33 + 333.33 = 1,000.00

The float sum printed 0.30000000000000004. The split shows a problem that remains even with exact numbers: 1,000 rupees do not divide into three equal amounts of whole paise, so rounding each share gives 333.33 three times, 999.99 in all, and a paisa disappears. Allocation fixes it by giving the leftover paisa to one share, by a rule anyone can predict.

Each decision has its place on that path, and each tool has one job:

• Integer minor units hold an amount as a whole count of paise or cents, so sums and comparisons are exact.
• Decimal types, such as Python’s decimal and Java’s BigDecimal, store base-10 digits with no binary error and apply a rounding mode only when the code asks for one.
• Rounding modes settle ties such as half a paisa: half-up rounds them away from zero, half-even to the even neighbour.
• The place of rounding, per line or once per invoice, is a business rule that can move a total by paise.
• Allocation hands out the leftover paise of a split one at a time in a fixed order, so the parts add up.
• Currency checks refuse to add amounts in different currencies; converting is a separate, explicit step.
• Rates as configuration keep tax percentages and fees as data with the day they apply from.
• Safe integers matter in JavaScript, whose numbers are doubles: whole paise stay exact only up to 2⁵³ − 1.

The same invoice three ways: floats, paise and decimals Pro: opens with a Pro, Premium or Ultimate pass