GNOME Bugzilla – Bug 502853
Incorrect tax rounding in invoice (rounding of .5)
Last modified: 2018-06-29 21:56:12 UTC
Please describe the problem: The tax amount in an invoice is rounded incorrectly and leads to wrong calculations. This way I can't use GnuCash to write invoices. Steps to reproduce: 1. Create an invoice 2. Set column "action" to hours 3. Set amount to 8.5 4. Set price to 35.00 EUR 5. Use a tax of 19% 6. Set the description and account to whatever you like. Actual results: Invoice sum will be 297.50 EUR with tax sum of 56.52 EUR. This tax is NOT correct. Expected results: The calculated tax without rounding is 56.525, so according to standard mathematical rules it should round up to 56.53 EUR. Does this happen every time? Yes, whenever the third digit after the colon is 5 (0.005). Other information: I don't know if there are any accounting rules for other countries that force this form of calculation, but here in Germany this way of rounding is definitely wrong. I'm sorry if the names for fields don't exactly match, but I use a german version here.
*** Bug 557876 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > *** Bug 557876 has been marked as a duplicate of this bug. *** Sorry, this was incorrect. I have set bug 557876 as a duplicate of the proper bug, but the comment seems to remain on this bug as well.
I can confirm this behaviour in GnuCash 2.3.15+ as well. Belgium, just as Germany requires to round 0.005 to 0.01. @Derek: Would this be different in the United States ?
I'm honestly not 100% sure what the USA Regulations say. Personally I think that .005 probably should round up to .01
Digging deeper in the code, I'm no so sure anymore whether this is a bug or intentional behaviour... There are multiple ways to round x.5. The definitions can be found in Wikipedia [1]. As it turns out, GnuCash uses the "Round half to even" method [2]. This is mentioned as the "banker's method" and is apparently the method frequently used in accounting. In short the means that 52.525 is rounded to 52.52 while 52.535 is rounded to 52.54. The original reporter on the other hand expects a "Round half away from zero" method [3]. Confusingly, this method is frequently used for currency conversions and price roundings. GnuCash is both an accounting program and does currency conversions and price roundings. So which method should be preferred ? I don't have enough accounting knowledge to answer this I'm afraid. [1] http://en.wikipedia.org/wiki/Rounding#Rounding_to_integer [2] http://en.wikipedia.org/wiki/Rounding#Round_half_to_even [3] http://en.wikipedia.org/wiki/Rounding#Round_half_away_from_zero
Should affect all OS.
I spoke with my accountant today. He confirms that the method used in Belgium is "Round half away from zero". He knew about the "Round half to even" method, but stated he never saw it used in practice. I also found a message on the GnuCash-devel mailing list [1] which summarizes a number of tax and rounding problems in the GnuCash code. The reporter was so kind to refer to two official EU regulations that confirm that "Round half to even" should be used in Europe for conversions between the old euro currencies and the euro [1]. Of course rounding on currency conversion is not the same as rounding on invoices. But I also found that at least in Dutch law (the first one I could find) even on invoices "Round half away from zero" should be applied [3]. So I will assume that rounding on invoices can be changed to "Round half away from zero". [1] https://lists.gnucash.org/pipermail/gnucash-devel/2009-January/024605.html [2] http://europa.eu/legislation_summaries/economic_and_monetary_affairs/institutional_and_economic_framework/l25025_en.htm [3] http://www.minfin.nl/Actueel/Besluiten_beleidsregels/2009/02/Omzetbelasting_Administratieve_en_factureringsverplichtingen
I found some proof for Germany as well: http://www.kpmg.de/docs/20090701_vat_newsletter_2009_07dt.pdf At the bottom of page 3 of this PDF says by means: "German tax law does not contain regulations about rounding of tax amounts. But if you declare tax on your invoices, its a safe bet to use standard mercantile rounding rules: Any fraction of a cent below 0,5 is rounded down to the full cent, i.e. 0,014 = 0,01 and any fraction of a cent equal or greater than 0,5 is rounded up to the next full cent, i.e. 0,015 = 0,02."
The traditional rounding is "round away from zero". "Round to even" was introduced IIRC in the second half of the 20th century, when banks watched a significant sum of all rounding errors when calculating interests. The same happend to organisations, which paid pensions ... Therefor IEEE 754 was introduced. Another problem in the invoice context is "Summenerhaltendes Runden", sorry I don't know the correct english term. More details are in http://de.wikipedia.org/wiki/Rundung and links. So I believe "round away from zero" should be the default. Eventually there could be an option to switch to "Round to even" for now unknown governmental requirements.
Is this a preference that should be made system-wide? datafile-by-datafile? account-by-account? currency-by-currency?
I can imagine the situation, where a government requires "round to even" for business accounting, while they still stuck to "round away from zero" for private accounting. So I think, a preference per datafile would be save. To explain "sum save rounding" (Summenerhaltendes Runden): An invoice of tax included prices is a matrix of the form n1 + t1 = g1 n2 + t2 = g2 : nm + tm = gm ------------ sum(ni) + sum(ti) = sum(gi) with n: net amount = round (g * 100 / (100 + taxrate)) t: tax amount = round (g * taxrate / (100 + taxrate)) g: gross amount i = 1..m but because of the rounding the sum line sometimes violates at least one condition. To avoid this, there are different rounding algorithms, which do some "error diffussion".
As a first step, I have changed the default rounding to "round away from zero". Since nobody so far referred to a situation that requires "round to even", I prefer to hold off the creation of a new option for a while. Besides the current string freeze would not allow to add a new option, so that will have to wait for 2.4.x anyway. I do think this change in default behaviour should be mentioned in the 2.4 release notes though. @Frank: the "round save sum" method you introduce in comment 9 and comment 11 is interesting. I hadn't heard about it. I think though it is more relevant in the context of bug 504954. That bug really deals with issues if you round at different times in the calculation (before or after summing). "round save sum" implicitly requires there to be a sum of values. This bug (502853) on the other hand only deals with what rounding method to use in a single amount rounding.
Just to add onother complication, the UK HMRC guide: http://customs.hmrc.gov.uk/channelsPortalWebApp/downloadFile?contentID=HMCE_CL_001596 section 17.5.2 states: 17.5.2 Calculation based on tax per unit or per article If you want to work out the VAT per unit or per article (for example, for use in price lists), you must work out the amounts of VAT either to: Page 80 of 214 Notice 700 The VAT Guide May 2012 4 digits after the decimal point and then round to 3 digits - for example, if the VAT is £0.0024, it should be rounded to £0.002 (0.2p); or the nearest 1p or 0.5p. If you decide to do this, you must not round the VAT down to “nil” on any unit or article that is liable at the standard or reduced rate - for example, if the VAT is £0.0024, it should be rounded to £0.005 (0.5p). That last part seems to imply that on a VAT rated rated item you must *always* charge some VAT even if the calculated VAT is less that 0.5p, so you can't just round it down to zero. So in the unlikely event you are selling an item for £0.02 you must round the VAT to £0.005. I'd think, in reality, this would almost never happen though. Just checking with trunk and three items of £0.02 each the total VAT payable is zero.
Thanks for the additional data point. It nicely illustrates that we won't be able to come up with a universally correct rounding scheme. IMO a proper solution can only be found by localizing some of the accounting/business rules. That's likely a huge refactoring of the code though.
To make the matter worse, some states here in the US use sales tax brackets (basically a table with tax amount a seller must withhold, e.g. http://dor.myflorida.com/dor/forms/current/dr2x.pdf for Florida). The sales tax values for Florida are actually just a rounding to ceiling of the sales amount multiplied by the state and county tax rate. Wouldn't it be easier to code an option to enter a sales tax amount manually?
The original rounding issue has been fixed for gnucash 3.2. For a wider discussion on rounding I have opened a new enhancement request: bug 796391 . Specific to comment 15: as we don't currently support sales tax brackets at all, I have opened a separate enhancement request for those: bug 796392. With that I'm closing this one as the original issue has been solved.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=502853. Please update any external references or bookmarks.