GNOME Bugzilla – Bug 724857
Inconsistencies in invoices with gross unit prices
Last modified: 2018-06-29 23:27:03 UTC
I have an invoice for 125.85 BGN gross with 20 % VAT, the column "Tax included" is checked. The resulting invoice (Reports -> Business -> Easy Invoice) looks like this: Description | Quantity | Unit Price | Tax Amount | Total ------------+----------+------------------------------------ Goods | 1,00 | 125,85 лв | 20,98 лв | 104,88 лв ------------+----------+------------------------------------ Net Price | | 104,88 лв Tax | | 20,98 лв Total Price | | 125,86 лв Amount Due | | 125,86 лв My problem is not about the report "Easy Invoice". It just illustrates the underlying problem(s): 1) The (gross) unit price 125.85 BGN differs from the total price of 125.86 BGN. 2) The sum in the column "Total" should be the difference between Quantity x Unit Price and Tax Amount but it is not. 3) The invoice is a vendor invoice I received which is really over 125.85 BGN gross. But there is no way to create an invoice in GnuCash with a gross total sum of 125.85 with a tax rate of 20 % with one item. So, why does this happen? Without rounding, the exact tax amount would be 20.975 BGN and the exact net amount would be 104.875 BGN. Both values theoretically have to be rounded up because the first digit discarded is a 5. In reality, IMHO, one of them will be rounded down, so that the resulting invoice would be one of 104.87 net + 20.98 tax = 125.85 gross 104.88 net + 20.97 tax = 125.85 gross Compare that to GnuCash's version: 125.86 gross = 125.85 gross incl. 20 % VAT Such an invoice is unlikely to be accepted.
This bug is related to bug 504954.
How does your BG vendor split the amount? Probably you should ask him for an invoice with tax in percent and amount?
The invoice is formally complete and correct. The invoice is about 128.85 BGN gross, VAT 20 %. The net sum on the invoice is 104.88 BGN, the calculated VAT is 20.97 BGN. Like I pointed out, you could alternatively split the same gross sum into 104.97 BGN and 20.98 BGN VAT. The Bulgarian tax authorities do not find fault with either version, and so there is no ground for demanding another, "corrected" version from my vendor.
128.85/1.2=107.375 ??? 104.88*0.2=20.976 So it seems truncated to full cent Just an idea as workaround: Enter 1 line with the net amount and 1 with the tax instead of using the built in calculation. Eventually we should add that to the documentation?
(In reply to comment #4) > 128.85/1.2=107.375 ??? Sorry, my bad: 125.85 is the gross amount printed on the invoice, 104.88 the net amount, and 20.97 the tax. > 104.88*0.2=20.976 > > So it seems truncated to full cent The calculation is based on gross prices. Accountants here, IMHO for good reason, do it one of the following ways: Gross = 125.85 Net = Gross / (1 + p) = 125.85 / (1 + 0.2) = 104.875 -> 104.88 Tax = Gross - Net = 20.97 Alternatively: Gross = 125.85 Tax = Gross * (p + 1/p) = 125.85 / (0.2 + 1.2) = 20.975 -> 20.98 Net = Gross - Tax = 104.87 In other words, calculate one value by multiplication/division, the other by addition/subtraction. Multiplying twice > Just an idea as workaround: > Enter 1 line with the net amount > and 1 with the tax > instead of using the built in calculation. > > Eventually we should add that to the documentation? Geert suggested to add a line only for the correction, and then accumulate when posting.
IMHO, the problem deserves a fix, not only a documented workaround. This is not an esoteric case but a regular effect of the positive bias involved with half-up rounding ("kaufmännisches Runden" in German). In the context of tax calculation, the problem can occur only for tax rates that are the product of an arbitrary odd integer and 5 to the power of an arbitrary integer (necessary condition) and for absolute tax amounts or net amounts that are rounded exactly half-up (sufficient condition). Correct me if I'm wrong. This does indeed sound esoteric but the necessary condition is fulfilled for the common tax rates 4 % (1 * 5^-2), 12 % (3 x 5^-2), and 20 % (1 x 5^-1). In the European Union such tax rates are currently in use in Austria, Belgium, Bulgaria, Estonia, France, Latvia, Luxemburg, Slovakia, Spain, and the UK. For all other tax rates, this case is numerically impossible. This is a possible explanation why the positive rounding bias seems to be ignored so far in GnuCash.
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=724857. Please continue processing the bug there and please update any external references or bookmarks.