Ask HN: Currency rounding rules | Hacker News Reader

Ask HN: Currency rounding rules

10 pointsfullmetaleng5 comments

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.

View on HN

A quick search reveals that the highest precision should be used for storage and calculations, and rounding just for presentation. So it shouldn't matter what rounding rule you use for display purposes.

I did find this explanation of Euro rounding rules: http://www.sysmod.com/eurofaq.htm#ROUNDING

Close, but wrong,

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.

The standard rounding for financial applications is typically Banker's Rounding, which is another way of describing rounding to the nearest even. E.g. 1.5 rounds up to 2 but 6.5 rounds down to 6. Over the long haul, this method of rounding produces the least amount of error. Some regulations and laws, though, specify different rounding techniques or specific phases in a process where rounding must or must not be performed. Especially critical in things like forex and other trading type applications. In addition to what byoung2 mentioned, Canadian law has specific rounding regulations that change based on what payment method is being used, but (as far as I know) don't generally apply to things like interest calculations and stuff like that[1].

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...

We ran in to this on a project recently involving line item currency calculations that were coming up off by pennies vs what the API was calculating.

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...

Compliance with local currency regulations is probably a hard problem, not just because the regulations may be written in the local language but because their interpretation may vary with time, place and the individual interpreting...and the amount of money involved.

Then again, it's money so it's worth taking seriously and paying for or developing expertise for any project that matters.

Reply on news.ycombinator.com