According to the data I have there are:

• 52 currencies that have no decimal places
• 239 that have 2 decimal places
• 3 that have 3 decimal places
• 1 that has four decimal places

But you should also consider that some currencies have specific rounding rules for cash values that relate to the physical currency in circulation.

For example, the AUD and CHF have cash rounding to 0.05 but normal rounding to 0.01.

Additionally there is the question as to when to round and to what precision. In a chain of financial transactions it is most common (according to my research, not an formal statement) that rounding is performed only at the end of the chain.

Then if you are splitting up money (like allocating it to various amounts) then rounding has to be handled carefully to ensure that any remainder is taken care of.

Anyway, money handling and its implication in the real world is an interesting problem - but its not just about decimal arithmetic (I am the author of ex_money and suggestions and PRs are always welcome)

100.00 + 10 == 110.00 is only true if they are both of the same currency. Its money, so the details are important.

As @tmbb suggests, picking a money lib and convert everything to money first so you know you’re dealing with a currency would be a good recommendation.

Money is complicated. Splitting an amount of money is a good case. And indeed there are cases for rounding as well.

1. The current exchange rate today for USD -> JPY is 111.869. I have USD 24.39 and when converted I end up with JPY 2728.9971

2. This is a totally valid accounting value (I understand most fintech systems require at least 7 digits of precision but I can’t site a reference for that). But of course eventually we have to put an amount in a customer account that is a settlement value that is a cash amount. Rounding JPY means no decimal digits so the result would be (using the default “half-even” or “bankers rounding” is JPY 2729.

3. Online services can charge at fractional cents. For example AWS charges $0.192 per Hour for a m5.xlarge instance. Rounding is required prior to billing

4. Splitting definitely has its own challenges. Splitting a money amount and rounding to the appropriate digits for a currency can leave a balance that shouldn’t be lost. I treat this in ex_money by returning the split amount and the remainder:

iex> Money.split(Money.new!(:USD, "12.43"), 3)
{#Money<:USD, 4.14>, #Money<:USD, 0.01>}

In short, there are valid reasons why a money amount may have more precision that the currency’s definition since intermediate results can create such scenarios. Currency conversion is one good example, interest rate calculations is another, stock trading another one. Eventually to settle accounts rounding will be required and management of the remainder will then also become important.

One should not try to build malformed partial implementations in any case, but even if all the currencies were having 2 decimals, the money unlike numbers require an ability to split 0.33 into two shares, than join them back and get 0.33. Otherwise the first audit would dismiss the whole business. That is impossible without very careful implementation, that is IMHO harder than anything else in the field.

You should convert everything to money before adding. The question of 100.00 + 10 shouldn’t even come up