GnuCash doesn't handle fractional cents properly with tax tables

[Omari Stephens]

(Rearranged responses.)

On 03/08/2017 10:58 PM, David Carlson wrote:
>
> On Wed, Mar 8, 2017 at 3:39 PM, Mike or Penny Novack <
> stepbystepfarm at dialup4less.com> wrote:
>
>> On 3/8/2017 12:19 PM, Omari Stephens wrote:
>>
>>> On 03/01/2017 08:11 AM, Omari Stephens wrote:
>>>
>>>> Howdy, y'all.  I'm pretty sure there's a bug here, but it's not clear to
>>>> me yet whether I'm also doing something wrong, or whether this just
>>>> needs to be fixed.
>>>>
>>>> My total sales tax rate is 8.5%.  So I charge 8.5% on top of the
>>>> subtotal.  My sales tax rate consists of a city rate of 0.25%, a county
>>>> rate of 2.25%, and a state rate of 6.0%.
>>>>
>>>> I recently sent a $150 invoice to a customer through PayPal, which just
>>>> charges the final rate of 8.5%.  So the total invoice amount was $150 +
>>>> $12.75 == $162.75
>>>>
>>>> When I try to enter the invoice in GnuCash, with "Taxable?" checked and
>>>> "Tax included?" _not_ checked for a $150.00 line, it shows the figured
>>>> tax amount as $12.7_6_.  Presumably related to the fact that the city
>>>> tax amount is $0.375 and the county tax amount is $3.375 .  I could see
>>>> this as being a confusing non-bug.
>>>>
 >>> Bump?
 >>>
 >>> --Omari
 >>>
 >> >> Maybe stop right there. WHAT are the actual rules for your 
jurisdictions?
>> There's always something new under the sun, but all jurisdictions that I
>> have lived in so far did not actually charge a percentage for sales tax
>> (perhaps with rounding for fractional cents). Instead they charged and
>> amount AT LEAST that percentage with the state getting every fraction of a
>> cent.
>>
>> Michael D Novack
 >
 > The "problem" with how to handle fractional cents is certainly not unique
 > to GnuCash.  As Michael points out, often there are local rules that 
may or
 > may not apply when calculating taxes or in any other situation where 
exact
 > values may calculate to fractions of a cent, or of any other currency.
 >
 > Loan repayments come to mind as another common example where users 
start to
 > complain when GnuCash disagrees with a financial institution's report.
 > Generally, when the discrepancy is small enough to be attributed to
 > rounding, the user has to acquiesce to the financial institutions' 
report.
 > A larger discrepancy may indicate a calculation error.
 >
 > While it would be possible to add code to GnuCash to follow alternative
 > rounding rules for all cases or for certain types of transactions, I 
doubt
 > that there could be a consensus about which rule to apply where.  This
 > could just make more configuration decisions for users to make at some
 > point in using GnuCash.  I think that the developers are correct to avoid
 > going down that rabbit hole.
 >
 > There is always a way 'fudge' transactions in GnuCash to make the results
 > match an outside reference when the user thinks it is necessary, so 
that is
 > sufficient for even the most fussy user, in my opinion.
 >
 > David

Fundamentally, the issue is that GnuCash is assuming the level of 
currency precision that is appropriate for _all_ tax calculations, and 
doesn't allow the user to adjust that precision.  That seems like a 
problem (which ends up being a minor problem in the US, and maybe a 
less-minor problem elsewhere).

This particular issue doesn't seem that hard to solve.  I can see a 
trivial solution that obviously works, and an elegant and robust-seeming 
solution that might have unexpected corner cases.

### Trivial solution:
Tax tables add a setting for currency precision.  Conveniently, this 
makes it straightforward for this feature to behave properly in 
currencies where even tens of units is a ridiculously small quantity.

### More elegant solution that seems robust, but may have corner cases:
Always figure tax with excessive precision.  Now, round up at the level 
of precision matching the destination account for the figured tax.

The GnuCash tax tables already match a given slice of tax to a specific 
account.  And GnuCash already supports setting the specific level of 
currency precision on a per-account basis.  Why not put those together? 
So yes, if I'm dumping 0.125 cents into an account with 1/100-dollar 
precision, it rounds to $0.13.  But if I'm putting it into an account 
with 1/1000-dollar precision, it stays at $0.125.  And if I'm putting it 
into an account with 1-dollar precision, it rounds up to $1.


In particular, in this case, using three different tax accounts is just 
informational for me.  My jurisdiction specifies a tax rate of 8.5%.  It 
happens to also communicate how we arrived at 8.5%, but the tax rate is 
8.5%, not 6% + 2.25% + 0.25%.  So the amount of tax I should collect 
corresponds to 8.5%, which does not produce the fractional values that 
led to this email thread.  Having a mechanism to vary the levels of 
precision would let me have my informative cake and eat it too.

--Omari