[VATMOSS: the misunderstanding of "proof"](https://remysharp.com/2014/12/30/vatmoss-proof "Permanent Link: VATMOSS: the misunderstanding of \"proof\"")

The proof required for any web site selling digital products or services is 2 pieces of data, but if these are in conflict (i.e. the country doesn’t match up) then you’ll need a 3rd.

This is actually a bit of joke, because if the 3rd is also in conflict, you need another until you do actually have two items of data that resolves to a single country.

The suggestions of what this can be are actually a bit wishy-washy. You’re fine if your first 2 items match, but getting a 3rd is the problem.

Here are the suggestions from HMRC:

[Source: Twitter, November 27, 2014](https://twitter.com/HMRCcustomers/status/537996346838761472)

This has been further clarified by others to this list (which you’ll see most posts suggesting):

Let’s separate this list into what we can feasibly collect before the transaction occurs.

Jane living in the UK, working for Italian company Air Italy (the airline) as a developer and she needs a subscription to my product.

My product is going to get for 3 pieces of information on purchase of my product:

As the address the web site asks for, she puts the company head office address (she’s guessing and assuming that this is actually the billing address, but she’s unsure), her company uses a VPN to access the internet through their ISP and the landline number is +44…​

The result is:

However, as she pays she has two options:

If she uses her personal bank card, the country location is UK, and the money she has in her UK bank account is taxed under UK tax law.

If she uses her business bard card, then country location it Italy, and the money (in that bank account) is correctly taxed under Italian tax law.

Making the initial 3 pieces of information utterly redundant, and the card country origin the ultimate source of truth.

Some businesses won’t be able to get the card holder bank origin before actually applying the correct VAT. In this case, then you have to make the assumption based on the non-conflicting data.

However, if you’re using a system like Stripe (as I am), then you get full details about the card data before you finalise the transaction cost.

If the bank that holds the card is based Italy (for instance) then the individual who opened the account must provide proof of citizenship to their Italian bank or if it was opened by a business, then the business must legally operate in that country.

Both of these facts require that the individual or business pay taxes in Italy, and therefore if the card says it’s registered in Italy, there’s no other option that to charge them Italian VAT rates.

Therefore: if you have the card country origin, you don’t need anything else.

I’ve no idea how, but I’d love to see this proposed to the HMRC and HM Treasury groups that are discussing these problems behind closed doors.

Published 30-Dec 2014 under #business. [Edit this post](https://github.com/remy/remysharp.com/blob/main/public/blog/vatmoss-proof.md)

Lock Thread

Login

Add Comment[M ↓   Markdown]()

[Upvotes]()[Newest]()[Oldest]()


Ben

0 points

8 years ago

Daft question, but: Why can’t you just ask the customer where they are? How is the statement of the customer that they are e.g. in the UK not a piece of evidence?


Rachel Andrew

0 points

9 years ago

re the "notes you can’t see", I don’t have access to anything you don’t. You should look at the data in the EU explanatory notes regarding what they term as "over the top" services. Granted they are a horror to read but there are various examples in there.

Your reliance on bank details struggles when it comes to the reality of payment processing. You are using one very specific PSP - Stripe and they have a far more modern and usable API than many other PSPs - including PayPal.

The method you are using also means you cannot show total, VAT inclusive price. My understanding of UK consumer law at least is that you need to show VAT inclusive prices if you sell mainly to consumers. Your service and our product I think has a strong argument that we really sell mainly to businesses or individuals who operate as a business of some sort. However that won’t be the case for many sellers. In that case relying on bank data would only work if you were going to show a total price and swallow the fluctuations in VAT yourself (which is what I believe many people intend to do anyhow).

Even when selling to businesses you are going to upset people if the amount they are charged is more than they were expecting. Chargebacks and annoyed customers will be the likely result.

I think the only sane way forward is the conclusion that most people are coming to, which is we need to ask the customer where they mostly are. Whether that be via just asking country or taking a full address. Then back up that statement with whatever other information you can gather, be that IP address, information from their browser, bank info and so on. Then implement good reporting to let you see if any customers have mismatched to the extent where you are not sure where to report the VAT being due.

To push for a system that relies on PSP data is going to involve all of the PSPs giving everyone access to that data and every third party system updating to use that data up front. That’s a huge leap, and more complex that a system that allows the customer declaration to be the primary "evidence" and asking merchants to collect as much as is possible to back that presumption up.


rem

0 points

9 years ago

Regarding the note, I see it now (in point 2), but in fact it applies to all 5 of the points.

By no means am I saying that the other data points should be ignored, only that the bank origin is the single data point that you should need alone to prove their location and thus the correct VAT to apply.

It’s correct to say that I’m currently showing prices as "£x + VAT". Indeed I was before I knew about the EU VAT changes. However, I also believe that we in the UK (and probably the EU) need to have the same kind of approach as the US when they show "$x + taxes". Since the final number is entirely dependant on a variable.

But I see a bigger problem. Lets say that you capture billing address and IP address. Both point to the Italy, so you charge 22% VAT. However, when the charge goes through, it’s executed with an UK credit card (which should have been charged at 20% VAT).

Current situation: your VAT records are right. Actual situation: the customer has been overcharged and they have an incorrect tax claim to make in the UK.

I can only see that in this case, the 2 non-conflicting data points are thrown aside, the bank origin is used to establish the right VAT and a refund is issued to the customer.


Rachel Andrew

0 points

9 years ago

I agree that it is likely we will go the way of the US in showing prices exc. of tax but that isn’t the case at the moment for people selling to consumers. So until that changes people selling to consumers need a method of showing price.

Your second point is exactly why we need to go with where people state they are. Unless people are actively lying about their location they probably know where they are and what VAT applies. If they are lying then it is up to the business to decide whether just to pay the extra VAT and report correctly or to chase the customer.


mkarnicki

0 points

5 years ago

I know these comments are 3 years old, but I would still like to relate to "The method you are using also means you cannot show total, VAT inclusive price." I don’t see how that’s related?

Could ask the customer for the billing address (and show applicable VAT before purchase based on that), then when the purchase is made, fail if the billing country is different from the card issuing country.

[Commento](https://commento.io)