Ask HN: Currency rounding rules
Are there any rules about what Rounding Mode and Rounding Increments should be used for different currency types?
I am aware of ISO 4217 which specifies the number of minor units (digits after decimal point) that are permitted for known currency types.
But, after searching on the internet for more than half-a-day, there seems to be no clear guidance about what Rounding Mode and Rounding Increments should be used for currency types. Does that mean it is up to the application developer to choose the Rounding Mode and Rounding Increments?
I was told that there are some laws that mandate certain rounding mechanisms to be used for certain currencies, but unfortunately I couldn't find them.
5 comments
[ 3.1 ms ] story [ 17.3 ms ] threadI did find this explanation of Euro rounding rules: http://www.sysmod.com/eurofaq.htm#ROUNDING
You should store it highest precision, but calculate on a configurable rounding scheme. Some accounting systems always round line items to 2 decimal places, some always round with 3. Some round tax to 3 DP because it's a regulatory requirement.
You would think it doesn't matter much, but in many places it does -- especially businesses that sell many, small priced items, and have invoices that are thousands of lines long .. 2dp/3dp rounding (and rounding on discount % calculations too) can mean that invoices are 10's or hundreds of dollars out.
Store high precision, calculations are configurable.
ISO 4217 works well for display purposes but doesn't work for all financial applications. Consider, for example, scenarios involving tax or a product billed based on usage. By rounding off at each processing step, the company could be losing substantial amounts of money. The last two companies I've worked have used varying types of mechanisms for tracking fractions of pennies. In some circumstances, it makes sense to store everything as integers with a separate column to represent precision, but I would probably not do this unless you have a specific use. It's a lot of noise and mucks up the source code worse than, say, a BigDecimal or Decimal type. At the current job, we store everything with 6 digits of precision because of the nature of our billing and use Decimal as a reserved type for only money.
To be honest, if you have an accounting department you probably want to involve them in these discussions because rounding decisions can have impact on your financial statements and, potentially, any audits that may occur in the future. I've worked on two financially focused applications so far and I would strongly suggest that you build out a very defined and clear way to manipulate money for rounding purposes. Building out those processes in a standardized and well-defined way makes for easy unit tests and also helps those who come in the future understand the decisions made.
[1]: http://www.mint.ca/store/mint/about-the-mint/rounding-690000...
Then again, it's money so it's worth taking seriously and paying for or developing expertise for any project that matters.
We were directed to use HALF_UP rounding to two decimal places for each calculation.
https://docs.oracle.com/javase/7/docs/api/java/math/Rounding...