GNOME Bugzilla – Bug 612957
Incorrect rounding when taxes are included
Last modified: 2018-06-29 22:36:52 UTC
To recreate, do the following. 1) Create a new tax table entry with 100% tax. 2) Create a new invoice. 3) Add an entry to the invoice with amount £5.11 and quantity 1. 4) Mark the entry as tax included and set it to the previously created tax table. 5) Observe that both the sub-total and the tax are listed as £2.56, and that the total is listed as £5.12. This is clearly wrong. A tax included amount of £5.11 means that's the price it's selling for and that's what you're receiving from the customer. Thus either the sub-total should be £2.55 or the tax should be.
Temporary workaround for those affected by this bug: Edit /src/engine/iso-4217-currencies.c so that by default it supports fractional pence, e.g. 100->1000 on line 585. (Less than ideal of course.)
I believe I have observed this too. In my case: Gnucash 2.2.9 r17849M Tax table entry is 20% (UK VAT) Create a new invoice Add an entry to the invoice with amount £39.99, quantity 1 Mark the entry as tax included and set it to the 20% VAT tax table You will get the total as £39.98 (£33.32 plus £6.66 tax) which is 0.01 out from the amount entered.
Re 1: If the tax rate is 100% you must not enter odd tax included amounts. What do you expect? Re 3: Keith, can you test and report with a more recent version? Current stable is 2.4.7. There were a few changes in between, which could affect the result.
Hi Frank, I don't have 2.4.7 at the moment, but I'm on 2.4.4 if that's any help. If anything, the problem has got worse on this version. Whereas before I only saw this occasionally I'm now seeing it much more often. The effect has also changed. Following the same procedure I did before (listed above) I now get the total as £40 (£33.33 plus £6.67 tax)
For the rounding there's no difference between 2.4.4 and 2.4.7, so for this issue 2.4.4 will do. If you see the issue more now that's an unlucky coincidence of your tax rate with the change in rounding algorithm. Before the rounding happened "round half to nearest even" where it now has changed to "round half away from zero". Both algorithms are mentioned in accounting contexts. The latter one gives results that are in most cases more intuitive, but that's not really an answer to your problem at hand of course. I agree that regardless of the rounding algorithm used at least when you are entering values with tax included, the sum of the calculated net and tax values should at least be equal to the entered value. This has to be fixed in the code somehow. As a workaround you can add a correcting entry to your invoice. So if you get Entered value: 39.99 Net value: 33.33 Tax value: 6.67 You can add an additional entry Tax corrected: -0.01, transferred to your tax account and with the tax related box unchecked. Or if you think it's the net value that's incorrect, then add an additional entry Net value: -0.01, transferred to the account of your first entry and with the tax related box unchecked. That will ensure all sums are correct, but you will end up with an additional entry on your invoice. If you intend to print the invoice for your customers, this is probably not an option, but the wrong totals aren't either.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=612957. Please continue processing the bug there and please update any external references or bookmarks.