What's the proper way to show money in an UI in Java?

Question

On the backend I'm storing money values in a Money class which wraps a BigDecimal and sets rounding to be always Half Even with scale 8. All basic operations work fine and behave as expected. But I need to show those values to the user with scale of 2, and that's bringing me rounding errors.

For example, I have these values in the backend:

a = 109.11432
b = 9015.57069
c = 9124.68501

Each one of them is formatted to the pt-BR locale:

NumberFormat nf = NumberFormat.getInstance();
nf.setCurrency(Currency.getInstance(new Locale("pt","BR")));
nf.setMinimumFractionDigits(2);
nf.setMaximumFractionDigits(2);
String n = nf.format(valor);
return n;

And then I have

a = 109,11
b = 9.015,57
c = 9.124,69

And that's ok, at first. But c should be a + b. With the real values, this is guaranteed, but the rounding gives me a 0.01 error.

What's the proper way to handle this situation?

Answer 1

If I were writing a money class, I would make it consist of two integer portions - dollars and cents (or reais and centavos, or whatever). That way you never end up with fractional cents. You just have to handle rolling over 100 cents in the addition and subtraction operations.

EDIT:

The comment to my original response has a good point. Another option would be to just store the number of cents, then divide by 100 when you need to display.

Answer 2

In a class I'm using currently the "value" was represented by a Long in cents (or whatever you want), so we have 2 methods one that returns this value and one that returns the "amountValue" (which is value/100.0) so for example the user inputs 12,5$ and the class stores it as 12,5*100=1250. Then we do all the operations using that value and we round it so it's not a floating point unit.

BUT be aware that even this solution isn't flawed, but it's more because of java/how computers represent the values. For example inputing 8,7 is ok and gives us back a value 8,7 when needed (first it's converted to 870 and then divided by 100.0 when we need the "amountValue") but for example when the user inputs 8,2 and wants to retrieve that value he gets 8,19 (because according to java 8,2*100=819,(9)). Not sure there's an easy way to make a Money class that would work in every single case.

Answer 3

It seems to be doing exactly what you want it to. The way you are storing it, you are storing far beyond 0.01. If that is not your intention, then stop doing it :)

If you want a + b to equal c with 2 decimal places, then you need to round before doing the addition. The solution to your issue depends on the requirements of your application. One common way of storing money is actually with an integer. That way, you cannot store fractions and you could never have the issue you are currently describing.

But it really depends on your requirements. Are you required to do money arithmetic based on 0.01, or on full accuracy and then round the end result? That's a business question, not a technical question.

Answer 4

Note that a NumberFormat also can have a rounding mode.

But ultimately, no rounding method can fulfill a business requirement like "these values have to add up to this one" without being designed specifically for that case. Round-half-even is designed to avoid a large-scale bias, not single last-decimal errors. So where do you originally get the data from? That's where you have to make sure that the rounding preserves the total.

Is storing the data with 8 fractional digits really a requirement, since you display only 2? I'd also question the assumption that "With the real values, this is guaranteed", since the same thing could happen there, when rounding to 8 digits after whatever calculation produced the values.