[Danny]

Tax calculation is a complicated matter. We have put a lot of attention of this aspect in order to make sure LemonStand was flexible and usable for merchants in (just about) all countries.

We are in the midst of revising some aspects of LemonStands tax engine. We have already released some updates, but are working on a more pieces to complete it.

We're asking for your help to define the problems some of you face, and gather information about your requirements.

You can read and discuss information specifically about Australian tax issues (and some UK) here: http://forum.lemonst...n-tax-problems/

This particular topic is meant to discuss tax issues in a broader sense, so that we can implement the tax engine in a way that is flexible enough for everyone. Here are some specific issues we are working on:

• How to allow products be displayed with tax included and not included[/*]
  
• How to calculate discounts when taxes are included[/*]
  
• How to decide between which taxes should be included, when the visitors location is unknown[/*]
  
• VAT number needs to be provided with validation date. However, how will this affect merchants in countries that do not use VAT but still want to display products that include taxes in their price?[/*]

Please join in on the discussion

[Aleksey]

Hi, guys!

Today I talked to iD in Skype and he proposed the following exercise about the tax included mode.

Quote

If the base product price is $35.00, tax is 17.5% (UK), then the display price is $41.125. The problem is how to represent $41.125 to the customer. Because you can't display it to 3 dp, it confuses people. So should it be $41.13? Well, for a single item yes. But how about 2 items? Should that be 2 * $41.125 = $82.25 or 2 * 41.13 = $82.26?

He suggests storing catalog prices with taxes already included as a solution. While this solution is good for some stores, it is not universal. If a tax rate changed, you would need to update prices of all products in your store. Another issue is that the tax rate could be different for different buyer locations.

Do you have any thoughts on the matter?

Thank you!

Aleksey

[infradawn]

Hi Aleksey,

And this was going to be just a short note :D


Based on our chat I've been shaking the bugs out of this one and here's what I came away with:

Assumptions:

Catalog prices do not include tax

Calculate the Tax:

For all products, calculate the "price including tax" by applying one or more tax rules to the catalog price.

The figure for "price including tax" is then rounded to suit the store currency. In the UK rounding would be to two decimal places. In other locales as needed by the store currency. The rounding options may be: round up, round down, round even, round arithmetic, or custom.

The figure for "rounded price including tax" is now used as the unit tax inclusive price of the product, and will be used wherever multiple product price calculations are required. You can think of it as similar to the option "catalog prices include tax" but calculated on the fly.

The Implications:

The whole exercise is to arrive at a neat tax inclusive price to display to the customer, that multiplies cleanly where more than 1 of the product is ordered. To do this the tax inclusive price has been rounded to make it fit our criteria. The result of this is that a small adjustment has been introduced to the base price. Think of it this way, because the tax rate is constant, the adjustment must be accounted for by a change in the base price. An example makes it clear:

Catalog Price: $35.00
Price including tax (17.5%): $35.00 + $6.125 = $41.125
Rounded price including tax (using round even method): $41.12
17.5 % tax component of $41.12: $6.1242553191489361702127659574468
Actual product price giving rise to a tax inclusive price of $41.12: $34.995744680851063829787234042553
Difference between catalog price and the actual price sold at: $0.0042553191489361702127659574468085

So, in this example the product is sold for $0.004255... less than the price it states in the store catalog. Is this a problem? Well, if it results in a product being sold at up to $0.005 less than the catalog price, and you're selling ten thousand of the item, then maybe it's a concern. In practice, if the round even method is chosen, then across many products the gains and losses will tend to cancel out. If you commonly construct prices like 4.95, 14.95, 49.95, etc, or one product line shifts in the thousands and all others are mostly in singles then particular sensitivity can distort the general cancelling behaviour. In those scenarios, the catalog price and/or the rounding method can be adjusted to compensate.


A few further considerations will doubtless shake out. The ones that come to mind now are:

Integration with payment gateways to ensure no $0.01 discrepancies. Because the catalog price is no longer the true price of the product.
Displaying prices both with and without tax may have a bearing on the chosen rounding method because, for example, if you always round up, the customer will see.

Thanks for staying to the end

iD

This post has been edited by infradawn: 18 May 2010 - 08:22 AM

[Danny]

After some internal discussions, we have come to some conclusions. While not set in stone, at this point it seems like the way forward.

The whole issue essentially comes down to pennies. Pennies that throw off amounts, and can cause problems when comparing orders in the shopping cart to various forms of POS software. As well, things need to be done in a certain way to adhere to government guidelines/rules.

Including tax in prices is possible. Tax can be calculated and added on top of product price, or reverse calculated if the merchant wants to provide a "tax included" price and let LemonStand figure out the amounts to arrive at that value.

The issue comes when trying to reconcile catalog prices with final cart prices. Because 3 items with tax calculated individually are not going to add up to 3 items with tax calculated on the sub-total.

We feel that this minor difference is a non-issue. The important thing is that the FINAL price is correct. As long as the customer is charged the correct amount, and adhering to standards, that's all that matters.
I don't believe any customer is going to be concerned that the catalog says a product is $41.13 / each including tax. But if they purchase 3, it comes to $123.38 instead of $123.39. The former being the amount if they took the product with tax included individually and multiplied by 3.

Taxes should be calculated on a sub-total, not a per item. Therefore, there is no way to make them match up perfectly, because LemonStand cannot predict how many products someone will purchase.

As I stated above, the important thing is that LemonStand accurately calculates taxes at checkout and charges the customer the proper amount. The invoice needs to be right.

If the customer wants to start doing math in their head, and then is upset that things are a few pennies off... well, they are simply incorrect. Taxes aren't calculated that way. They should be calculated on sub-totals of products and then rounded.

This makes things simple. Products that include tax are rounded as per standard methods.
Products in the cart are sub-totaled and tax is calculated on that. Therefore, the invoices amount will be correct. If the customer wants to do math in their head or calculator first, they could be a few pennies off. This is their error and should not alarm anyone.

With this implemented, LemonStand will have a more accurate a comprehensive tax system than any other shopping cart that we're aware of.
By no means is this simple to implement, but the concept is easy enough to grasp and it will be possible to solve with some testing.

[infradawn]

I sell handmade paper by the sheet. I sell each sheet for $0.75. The customer orders 100 sheets. The customer must pay 19% tax. The customer reviews his cart and sees:

Item              Quantity   Unit price (inc tax)    Total (inc tax)
-----------------------------------------------------------------------
Handmade Paper    100        0.89                    89.25

The customer is puzzled.

This is not a customer experience that will improve conversion rate.

iD

[Danny]

Personally, I don't think many customers would be puzzled by that. It's simple math. $.89 includes tax. The sub-total + tax is not going to be the same as an individual unit + tax multiplied by quantity. This is how numbers and tax work. This is true in a store as well. If someone purchases 1 chocolate bar, and then comes back and purchases 100. The values are not going to be the same.

Whether this would affect conversion rates could only be determined through testing. I suspect it would not hurt anything except in a VERY severe case. In my opinion, this example isn't one.

A simple fix for this problem would be to also show the "without tax" price in the cart. Showing the customer the $.75 before tax price would allow them to add it up themselves and see that the total amount is right. However, I would think VERY few customers would see a problem and actually do that, or abandon the cart because of it.

Nonetheless, we're still looking at this. But we also need to not overly complicate matters in an attempt to manipulate numbers so that it doesn't confuse customers that don't understand how to add on tax.

[infradawn]

Hi Danny,

I had this conversation with Aleksey. In a physical store with prices displayed including tax the customer expects the price of 100 bars of chocolate to be exactly 100 times the price of 1 bar of chocolate. EXACTLY! The customer may feel that some bulk discount might be negotiable but that's another story. The point is that the price for 100 of the product is exactly 100 times the price for 1 of the product.

It's been a while since I was in a store in North America and I can't actually remember if the first time tax appears is at checkout or not. But in the EU it's as I describe. In the UK even the till receipt doesn't show the tax component. If the customer wants to see a tax breakdown then a 'VAT Receipt' has to be specifically requested.

So, keep store catalog prices exclusive of tax. Then, depending on the tax rate appropriate for the current customer calculate a value for catalog price inc tax, round it, and stick with it. You now have a second store catalog price (that incudes tax), dynamically created and suitable for use when the store must display tax inclusive prices, and best is, it multiplies cleanly.

If the store displays tax exclusive prices use the catalog price consistently, if the store displays tax inclusive prices use the dynamically generated tax inclusive price consistently. You wouldn't be the first cart to do this. CS-Cart, I believe, handles tax this way.


iD

This post has been edited by infradawn: 19 May 2010 - 11:49 PM

[Danny]

So you are saying, that in the UK, taxes ARE NOT calculated based on the sub-total? You must, because otherwise, your chocolate bar example would be wrong.

In North America and Canada (and likely many other places) this is law. Taxes cannot be calculated per-item and then multiplied. This is why we're having problems. Because we're fighting with numbers. It's a problem that cannot be reconciled, because UK and NA stores must calculate taxes differently.

When you buy chocolate bars here... it would show something like below:

Chocolate bar
    4 @ $.75            $3.00

Subtotal                $3.00
GST                     $.15

TOTAL                   $3.15

If that is the problem in a nutshell, we shouldn't complicate it :) It's nothing more than difference as to how taxes are calculated.

Problem: In the UK, tax is calculated per item, and multiple items are then simply multiplied. In the USA, Canada, etc. taxes are supposed to be calculated on sub-totals. So products of same tax class need to be added together, and then tax is calculated based on that.

Is that correct in your mind?

If it is, then rounding is not really the issue. Standard rounding should apply. But as you said, price should inc tax and stick with it. Then multiply the clean number.

If that is the case, then the solution resides in making it possible for LemonStand to calculate taxes different as an option. This essentially means we need 2 or 3 different versions of the tax engine to serve merchants from countries with varying methods of calculating tax.

[infradawn]

This is necessarilly very UK-centric. But it does illustrate that different models to the N. American tax model exist.

This is the current position in the UK:

If you are registered for VAT you must give any VAT-registered customers a VAT invoice for any standard-rated or reduced-rated goods or services you sell them.

A VAT Receipt has to show, by law (amongst other things):

the unit price or rate, excluding VAT
the quantity of goods or the extent of the services
the rate of VAT that applies to what's being sold
the total amount payable, excluding VAT
the rate of any cash discount
the total amount of VAT charged

If you are a retailer, you do not need to issue a VAT invoice or receipt unless your customer asks for one.

So, in the UK, in a physical retail store the corresponding till receipt to your example would look like this (if you got a receipt at all):

Chocolate Bar     4 @ 0.75
-----------------------------------------
Total             3.00

There is a tax component but it's not explicitly shown.


Now, to answer your question "so you are saying, that in the UK, taxes ARE NOT calculated based on the sub-total?": No, I am not.

There was a recent case that threw light on how this is handled in the EU:

Quote

'Some companies have attempted to make substantial VAT savings, by rounding down fractions of a penny of tax owed on individual items sold.

Dutch company Albert Heijn had tried to make a claim for a VAT repayment on the basis of rounding down every item sold, rather than on the usual basis of rounding up or down on the basis of a basket of goods.

The ECJ ruled that the issues were not a matter for community law, and that member states could make their own mind up'

Now I don't know of any member state that has 'made up it's mind' to loose revenue! So my understanding is that if you calculate tax on each individual chocolate bar, round down, and then sum, you're going to be in trouble if you attempt this on anything other than a single item sale. I see no contradiction with this ruling and the method for calculating tax inclusive price I set out above, although discussion is always healthy. I'm not infalible :D

For eCommerce, my interpretation is that calculating tax on the sub-total of each product in a tax class is the correct approach. I've said this elsewhere in the forums. I cannot see how a tax jurisdiction could challenge such an approach.


So, back to my earlier thoughts on tax inclusive prices. The challenge is how to make those tax inclusive prices multiply cleanly. I believe that a eCommerce store's first responsibility is to maximize conversion. Making the customer comfortable with the numbers is part of that effort. I think the primary difficulty here has been communicating the fundamental differences between the N. American tax model and other tax models.

Thought it important to make this point again: this is a price display issue, not a tax calculation issue. Danny, you'll be relieved that I see no requirement for multiple tax engines.

BTW, the reason a physical store where all prices are inclusive of tax is able to sell 100 chocolate bars at exactly 100 times the price of 1 chocolate bar is because the ex tax price of the single product is constructed specifically so that when tax is added the tax inclusive price can be expressed exactly to 2DP, or to whatever your store currency requires.


Hope it helps

iD

This post has been edited by infradawn: 20 May 2010 - 04:37 AM

[Danny]

If tax is indeed calculated on the sub-total, then the only way to get clean multiplication using a consistent rounding method, is to artificially choose product prices that give the illusion that they always multiply cleanly. Otherwise, when you choose a number like $.75 (exclusive, and tax rate is 19%) it will not multiply cleanly. It isn't possible. You can argue with numbers all day long, but it will end up at $89.25 if the customer orders 100. And if the customer orders one, it will always end up at $.89, every time.

How can this be solved programatically? I'm going to argue that it can't.

The product display rules imposed by your government have created this problem, and I don't see any way to solve the problem illustrated in your $.89 product example. The customer cannot see past 2 decimal points. The numbers might not be visible, but they are indeed there.

We have defined the problem countless times, but have not come up with any sound logic that could be implemented programmatically to solve this. We have ideas about how to force numbers to multiply cleanly, but that would not be legal.

The bottom line is, this is a problem even physical store keepers would certainly have. If a store keeper sold something for $.89 tax inc, and tax rate was 19%, then this problem would exist. It's not possible for it not to! If you can show me otherwise, please do so. Cash registers employ a consistent rounding scheme as well, just like eCommerce software.

Everyone is on the same page regarding the problem. We have differing opinions about whether this is a problem at all, or the extent of it. But we should focus on a solution that can be described programmatically. That's what we have done, and nothing has surfaced yet.

[Danny]

Here are some screenshots taken from Checkout App. This is a cash register application that many people use around the world, including the UK. Would you consider this a bad customer experience?

[infradawn]

Hi Danny,

This is getting a bit one-on-one :lol: It would be useful to have other input.

Anyhow, using the same procedure I went through earlier in this thread, but using the $0.75 Handmade Paper example:

Catalog Price: $0.75
Add tax (19%): $0.75 + $0.1425 = $0.8925
Round (using round even method): $0.89
Calculate what the catalog price would have to be to give a tax inclusive price of $0.89 [Solve for n in: n(1+tax) = 0.89]: $0.7478991596638655

Now, wherever the catalog price would have been used, the figure $0.7478991596638655 is used instead. Job done.

Remember, in this scenario all prices are mandated to be shown including tax. So the customer never sees $0.7478991596638655, only ever sees $0.89 and any multiple of it (all of them clean).

The customer reviews his cart and sees:

Item              Quantity   Unit price (inc tax)    Total (inc tax)
-----------------------------------------------------------------------
Handmade Paper    100        0.89                    89.00

Happy customer :)

Ok, so we lost $0.0021... margin on each individual item. I can live with that. Across many products the losses and gains even out.


You're right I'm altering the base product price to suit the tax on a per locale basis. Nothing illegal because I will still account for the correct amount of tax. And as a store owner I can choose to alter prices as I wish. In actuality the adjustment will never be greater than $0.005 up or down.


Lemonstand doesn't even have to implement this method if it's not to your liking, just give me a hook into the tax engine so I can supply a custom function to supply it with $0.7478991596638655 rather than $0.75.


iD

This post has been edited by infradawn: 20 May 2010 - 10:57 PM

[Danny]

Yes, that is the solution I thought of too. basically, LemonStand would need to alter the price. This becomes a huge user interface challenge, not to mention makes things quite complex. Most merchants won't want software to say "no, I think the price should ACTUALLY be $____".

But there may be a way to create a clever interface to make it simple to manage. But it won't be simple on the back-end. And that can lead to problems down stream.

Another problem is how to report this. To do your accounting, you would need to record $0.7478991596638655 not $.75
But this number could not be found on the invoice, or else the customer may see it.

It could possibly be present in some hidden field, that is available if an order is exported, but that is not what I'd call a "simple solution".

It is an interesting idea, and we'll look into it. Maybe there is a simple way to implement this.

Regarding more input... I don't think anyone else seems to be interesting in this many decimal places :)

[infradawn]

A very good piece on international tax calculation from Elastic Path:

http://www.elasticpa...nternationally/

iD

[Aleksey]

Hi, iD!

Thank you very much! I like this sentence from the website: "When it comes to writing code to calculate taxes on orders, the simplest and best recommendation is: Let someone else do it" ;-)

Aleksey

[Andrew]

Danny, on 19 May 2010 - 09:01 PM, said:

Personally, I don't think many customers would be puzzled by that. It's simple math. $.89 includes tax. The sub-total + tax is not going to be the same as an individual unit + tax multiplied by quantity. This is how numbers and tax work. This is true in a store as well. If someone purchases 1 chocolate bar, and then comes back and purchases 100. The values are not going to be the same.

I know I'm waaay late on this discussion, but I just wanted to chime on the notion that 'it's simple math'. In Australia 0.89 x 100 = 89.00 - any different result is not a case of simple math, it's a simple case of being wrong. I think it's probably a cultural since in Australia the customer doesn't ever have to think about tax. The price on the ticket is the price. The price of 100 items is exactly 100x the price of one. Having lived in Canada for a short time it was quite a shock to have to always do tax math. As a foreigner it was hard to know if an item was tax inclusive or not, e.g. the local lunch shop included tax in the price, the camera store didn't. And on top of that you had to know if PST was included etc... and lets not start on tipping! (c:

So the issue for Australian's is that when a cart doesn't obey 100 x .89 = 89.00 rule it creates a very bad impression. From the customers perspective you either can't do simple math or you're being sneaky. Neither of which is good. I realise under the hood it's very complex, but in Aus this complexity is the responsibility of the merchant, not the customer. Customers don't have to know what taxes apply and don't have to calculate this in their head. They don't particularly like being forced to do either.

Quote

Whether this would affect conversion rates could only be determined through testing. I suspect it would not hurt anything except in a VERY severe case. In my opinion, this example isn't one.

You might be right (but I'd like evidence!) but for an Australian merchant selling to Australian customers it's just a really bad look.

Quote

A simple fix for this problem would be to also show the "without tax" price in the cart. Showing the customer the $.75 before tax price would allow them to add it up themselves and see that the total amount is right. However, I would think VERY few customers would see a problem and actually do that, or abandon the cart because of it.

Prices are almost universally quoted with GST included here, especially everyday goods and services. Displaying prices without GST is at best inconvenient (since your customer can't easily compare your prices with other outlets without doing math in their head) and at worst looks like your trying to look cheaper than you actually are. And in a competitive environment I don't want to be the guy forcing customers to do math or looking sneaky.

Quote

Nonetheless, we're still looking at this. But we also need to not overly complicate matters in an attempt to manipulate numbers so that it doesn't confuse customers that don't understand how to add on tax.

Cool (c: Although as I hope I've conveyed above, it's so much about people who "can't add on tax", it's about not forcing customers to know tax law and do math in their head when all of your competitors are kind enough to do these calculations for you (c:

Cheers
Andrew

[Danny]

Andrew, on 06 December 2011 - 08:40 PM, said:

Cool (c: Although as I hope I've conveyed above, it's so much about people who "can't add on tax", it's about not forcing customers to know tax law and do math in their head when all of your competitors are kind enough to do these calculations for you (c:

As we we have determined above, that is how numbers multiply. It's still very unclear how one might expect software to solve the problem that is introduced when a country uses tax inclusive prices (I wish we did too!), with clean multiplication, as it simply can't work unless the pre-tax price is intelligently altered so that it can be multiplied cleanly. Do you know of any software that solves the problem elegantly?

Infradawn's solution sounds interesting, but seems like it would create some problems with reporting, or at least an annoyance. Do you really want to import sales showing prices of $0.7478991596638655 rather than $0.75?
Your accountant would likely hate you

[reddbridgemark]

UK VAT rate is now 20%, in other european states it is less or more. Here are the VAT rules for the UK http://www.hmrc.gov.uk/vat/ and here and some import/export VAT rules for the UK http://www.hmrc.gov....ports/goods.htm and here is some other information about VAT in the european union http://ec.europa.eu/...ng/index_en.htm

Before anyone gets into tackling intra-country distance selling thresholds, or issues such as cities outside the eu that have multiple tax codes not based on post code, (which, in any case, may be better solved by third party modules,) it seems more to me that the core fundamental issues on to which everything is converging are primarily 'correct information to customers' and 'accurate sales data for accounting purposes'.

I think distinguishing between a 'tax inclusive' and 'tax exclusive' operating environment is probably un-necessary and a bit of a red herring. Keeping things pared back and operating on ex-tax unit prices keeps things simple and provides flexibility to do what is is you need to. As an example, a lot of UK retailers do show the VAT component on their receipts, either to automatically make it easy for businesses to shop there or sometimes just for transparency reasons, even if they don't have to; so some countries may be hybrids and some countries may have cultural even if not legal requirements.

If your items have correct tax codes allocated to them for the shopper's location, then multiplying (Y ex-tax unit * by X tax code = Z inclusive price) * by units bought, I think works each time. If you had set a rounding rule for your final inclusive prices, then you could show your total tax for the order to your customers by sum(inclusive prices) - sum(ex-tax unit costs).

As for how to show inclusive prices on the front end, again - presentational mainly - multiplying Y single ex-tax unit by X tax code = Z inclusive price, can call on the methodology of the above para to show the tax component of the price if necessary. The ability/feasibility to show inclusive tax dependent on the location of your shopper if you sell across multiple jurisdictions will I think be dictated by how friendly that operating environment is to that, but presuming that it is amenable to doing that practically then if unable to auto-detect the jurisdiction (geo-code, or perhaps domain name variant) and fetch matching tax codes, then it shows prices calculated from your default jurisdiction tax codes, you point out what tax it's inclusive of and give the customer the ability to change that. I can't really envisage anything more transparent than that. Re this part, I think the only thing LemonStands to do to make this happen is be able to group tax codes by 'jurisdiction' and set which one you want to use as default.

For both accounting requirements and deciding how to present prices to customers in terms of correct rounding, each jurisdiction could also have a value of either Round Result Up, Round Result Down, or Normal Rounding, plus an on/off option for Precise. If Precise is on then the precise tax calculation liability is stored in the database, but the value presented to the customer is still rounded up or down as required. If Precise is not on, then just the rounded up/down figure is stored. I believe that should accommodate both worlds.

[Andrew]

Before I bable on, I think reddbridgemark's analysis is excellent and the approach would work perfectly for me (although I'm without doubt the lest least qualified here, and by a very long way).

Quote

As we we have determined above, that is how numbers multiply. It's still very unclear how one might expect software to solve the problem that is introduced when a country uses tax inclusive prices (I wish we did too!), with clean multiplication, as it simply can't work unless the pre-tax price is intelligently altered so that it can be multiplied cleanly. Do you know of any software that solves the problem elegantly?

Yeah, tax inclusive is nice for customers (c: That and no 1c & 2c pieces.

I think the problem for me is simpler since I'm only trying to solve it for a constrained group of customers (I can't speak for other tax inc environments). I only want nice multiples when I'm selling Aus to Aus. And in this case if my ex-tax price is high precision and computed using my local tax rates then the math should follow (unless I'm missing something). If I'm selling to other tax jurisdictions, then I'm happy to live with the price for multiples not being exact multiples of the unit price etc. It sounds like this is normal and readily accepted tax-ex locations anyway, especially since you don't know the actual price without doing math in your head, and if you don't you've got nothing to compare it too when you buy 10. I also suspect that when you're buying from a tax-inc jurisdiction other than your own you don't care about these issues so much (I know I don't).

Besides, I can't see that nice multiples are even possible across multiple tax jurisdictions without specifying a price per jurisdiction - and if your going to that length you're probably defining multiple stores too as I imagine there are all sorts of other when issues for international retailers selling to specific locales like export/import laws & restrictions/exclusivity agreements etc. This is a problem for a whole different class of retailer than those I'm dealing with.

Quote

Infradawn's solution sounds interesting, but seems like it would create some problems with reporting, or at least an annoyance. Do you really want to import sales showing prices of $0.7478991596638655 rather than $0.75?
Your accountant would likely hate you

As I understand it this is pretty much what happens in Australia anyway (since it's an inherent side effect of defining the tax inclusive price as a whole number of cents). According to my accountant the high precision tax amounts are totalled for the invoice then rounded to the cent.

Again, I think reddbridgemark's approach sounds right and would solve my issues. A default tax jurisdiction, all amounts stored in high precision, rounding at the end. Sales to the same jurisdiction are nice, sales elsewhere live with the way math the works.

In the mean time I have the issues that I can't even manually enter a high precision ex-tax price since it gets rounded to 2 dp. This leaves me with with tax-inc prices like 4.99 or 5.01. As an aside, this makes it stand out even more as in Aus since our lowest demoninator coin is the 5c and prices are often a multiple of it (though not always).

At this stage it looks like I'll have to create 2 faux tax classes (GST & GST Free both with 0% taxes) and then manually change invoicing and reporting code compute & display the GST amounts appropriately. If there are other Australian's watching is this what you're doing?

Thanks & cheers

[christhesoul]

Our stores are UK based. All my clients without exception want to add prices including VAT. We then only show the VAT on the invoice (with a simple calculation). We tried it without tax, but the issue of multiple items and rounding looked silly to end users.

For UK users, I'd simply like to be able to add tax on a per product basis. So I have a base price field and a tax field. The tax field could have a calculate button (which looks to a site-wide VAT rate), but I have complete control of the rounding. The front end price is also displayed, but not editable since it's one field added to the other.

Maybe there's a massive hole in this theory, but it'd do the job for me I think.