What is best practice for currency padding/rounding when entering values in a text field?

Question

If I have a text field on a web page which displays a currency symbol next to the field is there any problem in taking values entered without 2 decimal places and adding them after the user submits?

123 becomes 123.00 123.4 becomes 123.40

What about >2 decimal places? Should the user be allowed to enter 123.456 and the system saves it as 123.46?

Currently the field behaves in a manner which forces the user to enter the full currency value including decimal symbol and following values (#.##) or they just cannot proceed, is this a safer practice for entering currency data?

Answer 1

It's ok to make 123 into 123.00 as it makes no difference

It's ok to make 123.4 into 123.40 as it makes no difference

It's not ok to do anything if the user enters 123.456

The chances are high that the user made a typo.

Did they mean

• 123.45
• 123.46
• 123.56
• 1234.56

Only the user knows what they meant to type.

And in that case, you need to highlight this as an error and get them to correct it into a suitable format that you can interpret completely unambiguously.

So - by all means be flexible by not forcing the user to enter .00 after a whole number - but do pick up on what could be a mistake.

Answer 2

I agree with everything Roger Attrill says. I can only add that since you don't mention what currency you're dealing with (US dollars, euros, UK pounds) you assume it's one that has sub-units to the hundredth (like a cent or pence).

If your use for this can be expanded to other countries, you'll want to consider other formats as well. For instance, Japanese don't usually user sub-units for prices in Yen. Other middle-eastern countries use three decimal places.

If internationalization is or may become a concern down the line, you can consider using a reference like Unicode's Common Locale Dra Repository. They have a JSON file of currencies with rules on how many decimal places, how to round numbers (including for cash transactions for places like Canada that have phased out the one cent coin). And if there are markets with special rules you can forward the file to your developer who can perhaps use it in his code.

Answer 3

I would allow the user to input whole numbers and any number of decimal places since the exchange rates are usually >2 decimal places and some items for example fuel have 3 decimal places in their price.

Answer 4

As Tim mentioned, 2 decimal places is only valid for some currencies. Here a useful reference -- http://apps.cybersource.com/library/documentation/sbc/quickref/currencies.pdf

Note also that, if you're supporting internationalization in any way, the decimal character isn't always a period. In many (all?) European countries, for example, comma is used as the decimal separator and period is used as the digit grouping (e.g. thousands) separator.