Sales Tax with GnuCash
Mike or Penny Novack
stepbystepfarm at mtdata.com
Thu Dec 17 13:46:22 EST 2009
Derek Atkins wrote:
>Well, for one thing this was just an example, but really you've never
>seen a tax table with multiple taxes?? That surprises me. Perhaps
>you've never seen them with integral tax rates, but I was just trying to
>keep the example simple. Obviously it can get more complicated that
>that, but unless you have a variable tax rate you can handle everything
>by precomputing.
>
>
I wasn't quite meaning "variable tax rate" though that would be what it
is in effect. I was referring to specific "rounding" rules. The problem
isn't with figuring 5% of $10.00 but correctly figuring the tax that is
nominally 5% for an amount of $10.09 or $10.19 etc. (what are THIS
jurisdiction's rules for that -- is the correct tax $0.51 for both of
those or $0.50 and $0.51 respectively).
>When you have a 'tax on a tax' (e.g., Canadian VAT/PST) you can
>precompute it and enter that as well. For example, if you have a 7%
>VAT and a 5% PST, but you have to pay VAT on the PST, then you can
>precompute the additive VAT taxrate and still enter it. For example,
>if you spend $x then you can compute:
>
> PaidPST = x * PSTrate = x * .05
> PaidVAT = (x + PaidPST) * VATrate = (x + (x * .05)) * .07
> = (1+PSTrate) * x * VATrate = 1.05 * x *.07
>
>So now we want to compute the additive VAT rate, by dividing PaidVat
>by x, so:
>
> RealVatRate = PaidVat/x = (1+PSTrate) * VATrate = 1.05 * .07 = .0735
>
>So you'd create a tax table:
>
> 5% ...PST (5%)
> 7.35% ...VAT (7%)
>
>Voila, you now have you precendence handled in the tax table. It's all
>just very straighforward algebra.
>
>
That solution works if/f you always compute tax A on top of tax B. Again
in my experience this is not always the case. To give an example.
Suppose town X has a "sales tax" that applies to all goods and services
to be applied after a state sales tax that applies to goods and services
except items of clothing costing less than X (my own state does that).
Then you can't solve the problem by simply adjusting the local sales tax
table because whether tax on tax depends upon what the item is and the
amount. Here Federal, State, and "local" tend NOT to agree in all
details. Go to the automotive shop and buy a pair of tires and a gallon
of antifreeze and the sales tax on the tires is on top of a federal tax
that applies to tires but doesn't exist for the antifreeze.
All I am trying to say here is that "more complicated" when you have to
be right to the penny. Tracking down small out of balances in an
accounting system are a pain in the neck. ROFLOL I had to carry a
special account "bank error" for a couple of months till a one cent
discrepancy was dealt with (data entry error at the bank's end but had
to wait for an administrative decision whether they were going to charge
our account for the penny or forgive it seeing as the account of a
"charitable" org.)
Michael D Novack, FLMI
PS: Keep in mind, what I used to do for a living. For my sins had to try
to get the clients to understand that what their new system was going to
have to do not quite so simple as first appeared. Or to somehow mange to
cobble together a fix when a system had gone into production coded a bit
naively (especially when the programmers were stumped "why is it
sometimes coming out off by a penny?" or whatever).
More information about the gnucash-user
mailing list