The tax categoryid is per SKU, and it's market-independent. So in your case I would suggest to have two SKUs, one for each market. 

I really don't think different SKU per market is good enough.

The SKU is usually a unique entity in the ERP system and in analytics, so dealing with a different SKU-code in EPI, connected to the market does not seem like a good idea. :)

A good example here is a book-store (Which can contain hundered thousands of books). In Norway and Sweden we have the same tax-rates on general goods. 

In Norway we have 0% vat on books, while in Sweden, we have 25 VAT.
But books that contains a CD will in Norway also have 25 VAT.

This means that we will duplicate the size of our catalogue if we have two SKUs per book. 

There is no need to dublicate SKU:s.

You need to setup the two tax categories correctly though:

Have to be done in Commerce Manager, it isn't available in the new UI yet as far as I know:

Commerce Manager->Administration->Catalog System->Tax Categories - for creating the categories
Commerce Manager->Administration->Order System->Tax Configuration - for everything else

Yes it can grow horribly complex with all the different categories to match all possible markets, but that is what support there is.

I know that opportunity, Erik. But it, as you say, it can be horribly complex.

When the products are imported the ERP-system, it is much easier to connect it to the price (As it is in most ERP-systems I've been working with) - Then we don't have to make mappings from the ERP-system-codes to custom codes in EpiServer.

So it is supported, but I really think it should be redesigned - since it's not a good solution.

Redesign is more of a feature request than a commerce question.

To my knowledge there is no way to extend prices with custom fields, the only field you could possibly hijack is the Sale Code one and that only if all your prices are available to all customers so that the field isn't in use.

It would require custom logic for loading the prices thou, episerver library classes assumes you aren't using that field for "all customers".

Although, quite frankly why can't you add a custom CultureSpecific property for the VAT rate on the SKU? Market!=Culture?

I guess you could have an non-translated dictionary with the values in that case.