Gnucash Business: Proposal: handling multiple tax accounts

Kevin Benton
Thu, 13 Jun 2002 17:50:56 -0700

Anyone who operates a vending machine business has this problem.  A little
algebra helps on this one.

Total is the total advertised price (including tax)
Price is the actual price without sales tax.
For this equation, STAP is the Sales Tax Aggregate Percentage including all

Total = Price * (1 + STAP)
Since the total and tax rates are known, we need to get price by itself.
First, let's get Price on the left like we're used to...

Price * (1 + STAP) = Total
Then, what we do to the left side, we must do to the right.

Price * (1 + STAP) / (1 + STAP) = Total / (1 + STAP)

Price = Total / (1 + STAP)

Try it for yourself - plug in the numbers off a receipt you've been given
and see if it works both ways.

$1.00 item taxed at 5% requires a payment of $1.05.
Price = $1.05 / (1 + 0.05) = $1.00

Imagine that... :)  Now you know how to compute sales tax backwards and
forwards. :)

Kevin Benton

WebEx Communications, Inc. accepts no liability in relation to any personal
emails, or any content of any email that does not relate directly to the
business of WebEx Communications, Inc.

-----Original Message-----
From: Derek Atkins [mailto:warlord@MIT.EDU]
Sent: Thursday, June 13, 2002 5:59 PM
To: Conrad Canterford
Subject: Re: Gnucash Business: Proposal: handling multiple tax accounts

Conrad Canterford <> writes:

> To do it properly, its a little more complicated than that. In
> Australia, an extra option "Tax included" would also be appreciated, as
> a large number of small businesses (and especially any retail business)
> will advertise and invoice the *tax inclusive* price. Asking whoever is
> doing the accounts to deduct the tax from every invoice as its entered
> is not going to make you any friends...  :-)

Where should this "tax included" option be stored?  Since prices
are advertized with-tax, how is the tax calculation made?

> I think a global table would be preferable. If someone is running
> multiple entities, this might save them re-entering a lot of data. If
> they are not, well it makes no difference to them.

What do you mean, "global table"?

> >   b) How do you reference tax tables for "posted" entries?
> >      - Tax Tables are immutable.
> >      - Tax Tables are mutable until they are "used" (at which point
> >        they become immutable).
> Personally, I'd go for this one.
> >        I think this might be too confusing for a user.
> Why? A simple dialog pops up saying "I'm sorry, but this entry is in use
> by an invoice and cannot be changed.".
> >      - Tax Tables are mutable, however when you post an invoice the
> >        Tax Table code creates an internal, immutable copy that is
> >        linked to the mutable tax table in question.
> This is really just an enhanced version of (b) as far as I'm concerned.
> Basically (if you think of it the other way around), when the user goes
> to change a tax table entry that's been used, the system automatically
> creates a new version of that entry and isolates the old one. This is
> just as prone to confuse a user as (b). However, I think any of the
> other options are also likely to confuse users, just in different ways.

The reason I prefer this last appoach is that:

 1) to the user, the tax table is always mutable.  They can change it
    at will, but
 2) any posted invoices will refer back to the tax table that existed
    when it was posted, and
 3) all the magic happens under the covers, as far as the user is
    concerned, and
 4) it will save space by reusing tax-tables as much as possible.

Thanks for your feedback.

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available
gnucash-devel mailing list