This is a followup of bug 502853 and bug 504954.

Both bugs initially pointed out rounding errors and quickly evolved in a discussion on variable rounding systems used in different jurisdictions.

Both original rounding bugs will be fixed in gnucash 3.2. However gnucash still only supports one rounding system.

This new enhancement request will serve as a tracking point for improving that.

To start as of gnucash 3.2 rounding on invoices will happen as follows:
- net values will be rounded at the entry level. So the total net value of an invoice will always be sum (rounded entry net values)
- taxes will be aggregated unrounded per tax account in the tax table and each aggregate value will be rounded before adding them up in the invoice tax total.

This ensures posting an invoice will never create an unbalanced transaction.
Note the rounding strategy used before 3.2 also ensured a posted transaction would always balance (the old way means rounding both net value and taxes at the entry level before summing/aggregating). However the old way cause more rounding errors leading into the above mentioned bugs.

Note also that the 3.2 way does still create display inconsistencies: taxes are displayed per line (both in the invoice entry window or on invoice reports) rounded to the invoice currency's SCU (smallest common unit). So they appear to be rounded before aggregation though the total tax is rounded after aggregation. Adding the individually displayed taxes together will reveal the reverse rounding error.

This is the first thing that probably can be improved. It would probably make sense to display these taxes with one or two digits more than the currency's scu. A design decision needs to be made on whether should be configurable and at what level. Perhaps only on a printed invoice is sufficient.

The mentioned bugs had the following elements we should take into account when improving rounding:

1. what rounding method to use or which rounding methods to offer to the user
I mentioned in bug502853c5 that different rounding strategies exist such as "round to nearest even", "round towards infinity", "round towards zero".
Currently we have settled on "round towards infinity" for business related rounding. We could offer more to cater for bills that happen to use a different strategy.

I'm in favour of not doing that unless it turns out to be mandatory in some jurisdictions. Instead I would like to allow the user to tweak final calculated tax results to make them match whatever is on a bill. I have used other accounting applications and this is typically the way they deal with it. This would also solve issues like 724857.

That will likely require changes in the data format and certainly in the user interface.

Related to this was the suggestion of the German "save sum rounding". I think this one as well would no longer be required if the user had direct control over the final tax amounts to post.

2. when to apply the rounding
Rereading the bugs I came across this nice analysis [1] again it appears our old method is used in some parts of the world. So we will probably have to support both options. The proposals in this analysis should be carefully reviewed. I'm not sure they all guarantee balanced post transactions, but at least the old method should be an option. The design decision to make here is at what level do we implement this ? Is this a book global option (business option) or a per vendor or per invoice option ?

[1] https://lists.gnucash.org/pipermail/gnucash-devel/2009-January/024605.html