Money that survives the trip to the screen

Corveek has never stored money as a floating-point number — amounts are integers in minor units, and every calculation goes through one shared helper. That was the easy half. The harder half is the last few centimetres: turning a stored integer into the string a person reads.

A review of that final step turned up three separate ways the number on screen could disagree with the number in the ledger.

Separators are not decoration

The formatter hardcoded US grouping. For an Indonesian organization, 1.234.567,89 is the correct rendering of the amount the old code showed as 1,234,567.89. Those are not two styles of the same number — read literally, they are different numbers. This was live for our first market.

Not every currency has two decimals

Dividing by one hundred assumes a two-decimal currency. The Japanese yen has no minor unit at all and the Bahraini dinar has three, so the same assumption over- or under-states the amount by a factor of ten or a hundred. The scale now comes from the currency itself rather than from a constant.

Large amounts lost precision

The conversion ran through a float on its way out. Past roughly nine quadrillion minor units the result is no longer exact — and in rupiah that ceiling arrives around ninety billion, which is an ordinary annual figure rather than an exotic one. Amounts are now assembled exactly from arbitrary-precision integers and handed to the formatter as a string, with no float anywhere in the path.

What this means for you

• Amounts render in your organization's locale, with its grouping and decimal marks.
• Currency precision follows the currency, not an assumption.
• Large figures are exact, not approximately exact.

Verified against a running stack rather than unit tests alone: the same ledger row renders 427.50 for a US English organization and 42.750 for an Indonesian one, because both are right.