We encounter the same problem in jurisdictions with tax computed after. Which is to say this problem is not unique to having tax-in pricing advertised.
Where I see it is in bills where the GnuCash rounding differs from that used by the vendor. And it only happens when there are multiple line items in the bill. GnuCash appears to total tax the taxable items and then round and sum the tax, whereas most vendors hereabouts add the taxable items and then multiply by the tax rate and round. Because the “bill” I create within GnuCash is only for internal use, I add a pair of entries - one taxable and one non-taxable, that balance out the amount in Accounts Payable, while adjusting the amount of VAT paid to match that on the bill from the vendor. In your case, is it making the invoice have the wrong total, or just your internal Accounts Receivable and/or VAT payable? In the latter case you can make an adjusting transaction to fix it. Ugly, and error prone, but possible. At least it only happens <some> of the time. > On Oct 17, 2022, at 3:50 PM, Michael or Penny Novack > <stepbystepf...@comcast.net> wrote: > > On 10/17/2022 11:03 AM, gnuc...@boeziek.nl wrote: >> Hi, >> I created a Sales Tax Table entry of 20%. >> When I create an Invoice of EUR 109,95 with tax included and select my Tax >> table, GNUCash calculates EUR 18,33 tax and EUR 91,63 in net revenue. >> My Accounts Receivable however will not increase by EUR 109,95 but by >> 109,96. So 1 cent difference. (the precise amounts are: sales is EUR 91,625 >> and tax EUR 18,325 and thus both are rounded up) >> >> Is there a way to have the tax rounded down (by 0,5cent) so that the total >> stays EUR 109,95? >> I really prefer to have accounts being 0 at the end of a period, instead of >> all these loose cents adding up (makes reconciliation harder). >> >> Thanks, >> Etienne > > This is NOT a rounded-up rounded-down issue. It is a when calculated issue if > both a set of items and their sum. > > Rounded (A+B) does not (necessarily) equal (Rounded A) + (Rounded B) And > how far the distance can become depends on the number of items involved. If > there were a couple dozen items the range of "answers" could vary by several > units. The calculation of "fuzz" is a fine art (when a computer program is > checking for equality between amounts calculated in different ways the > program decides they are equal if the difference between them is less than > the "fuzz" -- and I have had to figure what the correct fuzz should be in my > days in the cypher mines) > > SO --- what are the actual tax rules of the jurisdiction? If several items > are bought at the same time is the correct VAT the sum of the VAT due for > each item or is it the VAT due on the sum of the items? > > Michael D Novack > > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
