Rounding issues with
Geert Janssens
janssens-geert at telenet.be
Mon Feb 17 20:40:03 EST 2014
On Tuesday 18 February 2014 00:45:14 Guido Flohr wrote:
> Goedemiddag, bonjour, hallo, whatever you like best in België, en
> Belgique, in Belgien!
>
> Can you please kick me in the right direction where to report more
> problems with the gnucash business module? The gnucash-user mailing
> list, IRC, bugzilla, you personally, /dev/null?
>
All are fine except me personally :)
The reason is simple: more viewers give you better chances of getting an
answer. And others may have the same questions. Asking public means
others get their answers as well in one go.
> My current issue was described in
> http://list-archives.org/2014/02/14/gnucash-de-gnucash-org/rundungsfeh
> ler-bei-ust-berechnung/f/5423065615
>
> I have paid 125.85 $ (really 125.85 BGN, Bulgarian levs) gross in
> cash, and demanded an invoice for that. The invoice then contained
> the items 104.88 net, plus 20 % VAT 20.97 totalling to 125.85 $
> gross. Yes, it is debatable whether the invoice is formally correct
> because of the rounding, resp. rounding errors, applied. But the
> Bulgarian tax authorities accept it as one of the many possible
> calculation schemes. I am still waiting for a reply from the German
> tax authorities about the same question.
>
> 125.85 € is an "impossible" gross price with a VAT rate of 20 % (the
> default for example in Austria or Bulgaria) because there is no net
> price for such a gross price. The same holds true for the common
> supermarket price of 0.99 €. Still, those gross prices are not
> illegal, and it should be possible to issue invoices for that.
>
How is that an impossible gross price ?
> Another similar issue seems to be the question whether the tax/VAT
> should be applied to each row of the invoice, or to the grouped net
> sum, or even to each individual item.
>
> I have zero minus null accounting experience. So, feel free to just
> answer my initial question with "/dev/null".
>
> My 0.02$ are though: I have the impression that there is a wide range
> of accepted (by tax authorities) VAT calculation schemes, as long as
> they are consistent. Gnucash provides two options:
>
> 1) base is gross (tax included), which is systematically wrong almost
> everywhere.
>
> 2) base is net (tax not included) but is calculated per row/group not
> per item which is probably correct very often, but not necessarily.
>
> So 1) is pretty much useless although it should cover the supermarket
> use case with prices of x.99 units (with a 20 % tax rate in my
> example; and - gnucash provides wrong results with 20 % in my
> example). And 2), although less relevant, leaves room to human
> mistakes. In other words: A gnucash user may be in the situation to
> enter an erroneously issued invoice, accepted by both the local tax
> authorities and the tax authorities of the issuer, but not by the
> expectations of Gnucash.
>
> Wouldn't it be better to give the user an option to overrule the
> software's decision here? I have unsuccessfully tried to fix the
> problem by modifying Gnucash's XML file directly, so I am aware that
> a flexible solution is not allowed by the current model that
> redirects the tax calculation to the tax table (unless I missed
> something).
>
There are several bug reports regarding rounding and taxes [1]. Does any
of these describe what you are trying to explain ?
I have run into similar issues in the past, but I have always been able
to make the transactions that get posted match the net and tax values as
printed on the bills.
Others may correct me if I'm wrong but in my opinion whether "gross" vs
"net" is used as basis for tax calculation is not that important in this
context. What is important is that gross = net + taxes and that this
matches what is printed on the bill.
> I have heard that other, "professional" (aka proprietary) software
> handles those issues in a somewhat consistent manner. But for gnucash
> it doesn't seem to be documented, and it looks to me that there is
> still room for a flexible, user-friendly, and consistent solution.
>
That I can only agree to. If only someone were available to write these
improvements...
> Just to remind you: "> /dev/null" is still a possible reply. ;)
>
> Cheers,
> Guido
Regards,
Geert
[1] A few of the reports:
https://bugzilla.gnome.org/show_bug.cgi?id=443967
https://bugzilla.gnome.org/show_bug.cgi?id=502853
https://bugzilla.gnome.org/show_bug.cgi?id=504954
https://bugzilla.gnome.org/show_bug.cgi?id=520547
More information about the gnucash-user
mailing list