Rounding issues with

[Geert Janssens]

On Friday 21 February 2014 09:19:01 Guido Flohr wrote:
> Am Dienstag, den 18.02.2014, 18:01 +0000 schrieb Mike or Penny Novack:
> > >125.85 gross with a 20% VAT would correspond to a net price of
> > >104.875. Since net prices aren't priced to the thousandth of a
> > >Euro, that would really be 104.87 or 104.88. For the former, the
> > >gross price would be (unrounded) 124.844, which would round to
> > >124.84. For the latter, the gross price would be 125.856, which
> > >would round to 124.86.
> > 
> > I am totally unsure how we can be having a discussion about
> > "rounding
> > errors" with regard to tax computations without FIRST determining
> > what the rules the jurisdiction imposes for computing the tax
> > amount.
> You can receive invoices from many different countries with different
> rules for tax calculations.  And even if there was a world-wide
> agreement on how taxes have to be calculated you may still receive
> invoices with marginal rounding errors.
> 
> Most of my vendor invoices come from Bulgaria.  Some calculate the tax
> based on net prices, some on gross prices.  Some calculate the tax
> per row, some per item.  And some invoices suffer from rounding
> errors of one stotinka (think: cent).  I have never received a
> complaint from tax authorities for accepting and accounting all those
> invoices exactly as they were issued.
> 
> The situation seems to be the same in Germany.
> 
> So, my problem is not that Gnucash calculates taxes incorrectly but
> that it enforces its own calculation scheme on invoices that I
> receive, and not only on those that I issue myself.
> 
I agree and I believe it is indeed the core of the issue. GnuCash 
shouldn't force the tax calculation on received bills. I have worked 
with other accounting programs and all have a way to correct the net/vat 
values when entering bills.

> Somebody from the German mailing list recommended to create an account
> "rounding errors" and book the marginal differences there.  Probably
> the best solution for the time being.
> 
The way I work around it is to add an extra entry to the bill with the 
VAT correction, directly on my VAT account. That's not 100% ideal either 
- the bill's total will be correct now, but the VAT correction is 
added/substracted to/from the net value instead of the VAT value. When 
the bill is posted, I make sure "Accumulate splits" is enabled. At this 
point the generated transactions are correct because the calculated VAT 
and the manually entered correction are now summed together and put in 
the VAT account. So the books are all correct. It's just the bill itself 
that displays the rounding correction in the wrong spot.

Geert