# Gnucash Business: Proposal: handling multiple tax accounts

Kevin Benton KevinB@webex.com
Thu, 13 Jun 2002 20:50:19 -0700

```No, I'm not.  As a merchant, I use Price = Total / ( 1 + STAP ).  Then, from
there, you can re-compute each tax.  The customer already paid the total,
which is why you need to compute the price for your gross sales forms.
Think about it this way - if I as a merchant tell my customers that tax is
included, and I fill out all my tax forms, do I want to pay tax on the price
or the total (price + included tax)?  I think I'll pay tax on the price of
the goods to the customer.  You can pay tax on both if you'd really like.
Your government will take your money either way.  :)  When it comes time to
audit records, it's common practice to put down the cost of goods to the
a price that includes tax, you've decided what the customer cost (pre-tax)
is even if you haven't calculated it yet.

Let's use a simple example.

Let's say that I advertise my spiffy widget for \$1100 each (tax included).
Let's also say that my aggregate tax rate (city+county+state+others) is 10%.
What we need to do is figure out what the price of the item would have been
if tax were not included.  That's going to be less than \$1100, right?  Ok -
knowing that, let's figure out what the cost would be if we had not included
tax.  Again, we know the total price (\$1100), and the sales tax aggregate
percentage (10%).  To compute the amount of tax that was paid, we must first
compute the price of the widget without tax.  Price = Total / ( 1 + STAP ).
So, if Total is 1100 and 1 + STAP = 1.1, then we have Price = 1100 / 1.1.
Price = 1000.  So, if the price is \$1000 and the total paid is \$1100, then
the aggregate tax amount is \$100.  From there, you can slice up the
percentages of the \$100 for each of the taxes you paid.

Let's work it the other way just as an exercise.  Let's say that you chose
to advertise your product for \$1100 each (tax included) but you forgot that
you included the tax already.  Remember that our original formula is Total =
Price * ( 1 + STAP ).  Note that this is the same as Total = Price + ( Price
* STAP ).  There you'd have Total = 1100 * ( 1 + 0.10 ) = 1100 * 1.1 = 1210.
Notice here that the difference between the price and the total is now \$110.
That's an additional 10% higher.  So, in other words, you're actually going
to pay tax on your tax!  YUCK!

Have I confused you enough yet?

When computing sales tax for sales when tax is included in the price of the
sale, for tax reporting purposes use this formula:

Tax Paid By Customer = Total - ( Total / ( 1 + STAP ) )

How did I get it?

Tax Paid By Customer = Total - Price

What's Price?  Just like we figured out before...

Price = Total / ( 1 + STAP )

RECAP...
****************************************************************************
******************************************
Total Paid By Customer = Sale Price Tax Not Included * ( 1 + Sales Tax
Aggregate Percentage ) )
Price Paid By Customer = Sale Price Tax Included / ( 1 + Sales Tax Aggregate
Percentage )
Tax Paid By Customer = Sale Price Tax Included - ( Sale Price Tax Included /
( 1 + Sales Tax Aggregate Percentage ) )
****************************************************************************
******************************************

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

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

at it from the customer point of view, not the merchant.  I'm asking
from a merchant point of view.

-derek

Kevin Benton <KevinB@webex.com> writes:

> If my read of it is correct, the customer already paid sales tax.
> Therefore, you would use the formula...
>
> Price = Total / ( 1 + STAP )
>
> as below.  You'd work backwards.  If you don't, you wind up paying more
tax
> as a merchant while your customer gets a free discount.  :/
>
> 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 7:02 PM
> To: Kevin Benton
> Subject: Re: Gnucash Business: Proposal: handling multiple tax accounts
>
>
> Thanks, but this wasn't quite what I was asking.  I was asking a
> procedural question, not a mathematical question.  I was asking how
> the process works for determining prices; do you start with the final
> price and work backwards, or do you work forwards?  Following that,
> does it imply that the "TaxIncluded" flag means work backwards, too?
> That would mean that you enter the final price and the tax is computed
> backwards from that?  It also doesn't answer the "where do you set the
> TaxIncluded flag" question....
>
> But thanks for making the math simple for others on the list ;)
>
> -derek
>
> Kevin Benton <KevinB@webex.com> writes:
>
> > 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
> > taxes.
> >
> > 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
> > Cc: gnucash-devel@gnucash.org
> > Subject: Re: Gnucash Business: Proposal: handling multiple tax accounts
> >
> >
> >
> > > 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
> > > 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
> >
> > > 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
> > --
> >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> >        Member, MIT Student Information Processing Board  (SIPB)
> >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> >        warlord@MIT.EDU                        PGP key available
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel@lists.gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@MIT.EDU                        PGP key available

--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board  (SIPB)
URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
warlord@MIT.EDU                        PGP key available

```