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 customer (without tax), plus additional taxes added on. When you advertise 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 business of WebEx Communications, Inc. -----Original Message----- From: Derek Atkins [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 8:56 PM To: Kevin Benton Cc: Conrad Canterford; [EMAIL PROTECTED] Subject: Re: Gnucash Business: Proposal: handling multiple tax accounts You're still not answering the question I'm asking... You're looking at it from the customer point of view, not the merchant. I'm asking from a merchant point of view. -derek Kevin Benton <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 7:02 PM > To: Kevin Benton > Cc: Conrad Canterford; [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]] > > Sent: Thursday, June 13, 2002 5:59 PM > > To: Conrad Canterford > > Cc: [EMAIL PROTECTED] > > Subject: Re: Gnucash Business: Proposal: handling multiple tax accounts > > > > > > Conrad Canterford <[EMAIL PROTECTED]> 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 > > -- > > 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 > > [EMAIL PROTECTED] PGP key available > > _______________________________________________ > > gnucash-devel mailing list > > [EMAIL PROTECTED] > > http://www.gnucash.org/cgi-bin/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 > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
