
Ask HN: Currency rounding rules - fullmetaleng
Are there any rules about what Rounding Mode and Rounding Increments should be used for different currency types?<p>I am aware of ISO 4217 which specifies the number of minor units (digits after decimal point) that are permitted for known currency types.<p>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?<p>I was told that there are some laws that mandate certain rounding mechanisms to be used for certain currencies, but unfortunately I couldn&#x27;t find them.
======
byoung2
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](http://www.sysmod.com/eurofaq.htm#ROUNDING)

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

------
shadowwolf007
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...](http://www.mint.ca/store/mint/about-the-
mint/rounding-6900008)

------
saluki
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...](https://docs.oracle.com/javase/7/docs/api/java/math/RoundingMode.html)

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

