Improve tax handling to allow EU VAT regulation handling

[jdevalk]

To be able to handle all the new tax regulations in the EU per january 1st 2015, we need to add a few "basic" tax handling features to EDD:

• [ ] an option to change a specific tax rate at a specific date (to allow only updating these things like once a month).
• [ ] an option to have multiple types of tax rates per country.
• [ ] an option to specify the type of tax rate to use for a specific product category.

I could personally live without 2 and 3 above for a while, the first is the most "urgent" for me as it would otherwise soon become unmanageable.

[chriscct7]

We had an issue for this as #2137, where we after discussing it at a couple different EDD meetups we decided it would likely be best for the VAT extension to do this as no one else would need those features.

The fact of the matter is the "basic" features of adding multiple tax rates sounds really easy, but I can tell you from when we wrote the tax system at Jigoshop for handling it, its unbelievably complex, and its the beginning of a slippery slope that quickly leads to a tax settings page that looks like the one in WooCommerce, daunting and (for most people) unnecessary. And even they still have open GitHub tickets to add even more settings (since they aren't in compliance with VAT over when VAT is calculated in regards to discounts, see woothemes/woocommerce/issues/4848). Same deal for per-product category tax rates.

We support simple taxes in core, and we've had to spend alot of effort rewriting (twice from scratch) and fixing it. Taxes are complicated, and easy to mess up. The idea of adding significantly more tax logic, probably 2 or 3x as much to handle this proposal's line items, does not sound all to appealing.

Really the only one that is easy is the specific date switch code wise, since it'd just be an if/else, but even then means we'd have to double the size of the tax settings page to let people setup the complete tax settings both before and after said date. Further, it really only would be used once, to help people move to the new VAT rates. You wouldn't use it in any other instance, since most people's tax rate changes are quite simple in comparison. Even something as simple as just that item sounds like extension territory.

I really think though that if we're going to have a VAT extension, all VAT stuff should be in it. If we start splitting functionality between it and core, its going to make things more confusing for both EDD core and the VAT extension author, extremely confusing for our users (what do they need, how does it need to be setup, why does EDD only support part of VAT, etc) and likely lead to more bugs rather than just having all the logic in one place.

I'll let the other EDD core devs sound in on this, but my thought is:

• Core taxes are already comprehensive for most, and adding more tax options, when we're in the process of trying to simplify taxes (like for example removing the before/after discounts option) doesn't help the mission of making EDD simpler to use
• The extension designed to handle VAT taxes should handle this
• If the VAT extension doesn't want to handle this, I think a core sponsored VAT extension vs VAT options in core is the better approach. Only the EU uses VAT. Maybe we could make an equivalent of the VAT extension, so we'd only have 1 of them. Frankly I think I'd just rather have the existing VAT extension support it.
• The idea of more tax selections in core doesn't sound all to appealing

[jdevalk]

I don't think most people get it yet, but to be allowed to sell TO people in the EU, everyone will have to comply with the new EU regulations. Also "only" the EU are more people than the US. The EU consists of 28 countries that all regularly change their VAT rates.

[pippinsplugins]

Could you elaborate on "change a specific tax rate at a specific date" item?

For that, are you wanting to define a tax rate that is used only between Date X and Date Y?

For multiple tax rates per country, are you wanting them to be broken down by postal code? City?

[pippinsplugins]

Note: let's please try and avoid using terms like basic when talking about taxes. Nothing in taxes is basic, especially not when talking about VAT.

[jdevalk]

• Could you elaborate on "change a specific tax rate at a specific date" item? No, say, Belgium might change their high VAT rate from 21 to 22% on april 1st, I'd want to be able to enter that before april 1st so i wouldn't have to make the change at midnight :)
• Multiple tax rates per country most EU countries have at least two tax rates a low and a high one. Luxury goods would be under a high VAT rate, educational stuff (like... ebooks) might be under a low VAT rate.

[pippinsplugins]

1. I think that's the same as I was saying. Let's say the rate is 10% until December 31st, 2014. You'd enter a rate that has an end date of Dec 31st, 2014. You'd then create another rate that is only valid on or after January 1, 2015.
2. How are the rates identified? City code? When a customer is making a purchase, how do we know which one they should receive? That's what I'm asking.

[chriscct7]

You only have to comply with the VAT regulations if you are based in the EU. Most of the world (88% by countries, 93% by population) will never see this issue. Nevertheless, its not something that we idealistically want to put in core. I still think this should be done in the VAT extension. A prime example of why is WooCommerce whose:

• Tax system settings page is extraordinarily complex
• Tax system often has bugs because of its complexity
• Tax system doesn't even handle tens of dozens of VAT exemptions (places in the EU that are not subject to VAT, and types of consumers who are exempt from VAT)
• and yet is still not VAT compliant if you're not calculating taxes on the gateway because of taxes and discounts

EDD's core is designed to be simple and in order to handle everything VAT requires, we'd have to have a page with more settings than on the WooCommerce once to actually get VAT compliant since they aren't, then double that entire blob to support VAT rates changing over assuming they all change over on the same date. If they change over on different dates, that's exponentially more settings.

There's hundreds of exemptions from VAT. You would have to break them down by city at least and then by type of consumer (are they purchasing it for a soccer club?). Example, Spain's Canary Island residents, unlike the rest of Spain, are completely excluded from VAT. In Sweden, purchases for soccer teams are also VAT exempt.

What might be a prudent move for the EDD VAT author is to integrate with a tax service like Taxomo or TaxCloud, so the rates that are used are always right and require shop owners never to have to set tax rates up and all of those exemptions are handled, but that's up for him to decide.

[pippinsplugins]

I think we can at least put some of it in core. Before making a final decision on any of it, let's at least flesh out what it will look like.

[jdevalk]

@chriscct7: you're wrong. If you want to sell to people in the EU, you'll have to comply.

@pippinsplugins: "How are the rates identified? City code? When a customer is making a purchase, how do we know which one they should receive? That's what I'm asking." So this is where US VAT is very different from EU VAT. It depends on both the type of product and the origin of the customer.

[chriscct7]

The United States does not have a VAT. There's no national tax on digital products or services, and only ones that are implemented by individual states that only apply if your company is both registered as a business (not required for some types of businesses) and based in that state.

Whether or not the European Union even has the legal authority to charge any VAT on outside EU to inside EU transactions is highly questionable, with the only legal basis is an agreement that work should be put toward a digital VAT at the 1998 OECD meeting in Ottawa. No legal basis exists for bringing a non-EU based electronic vendor within the purview of the EU VAT scheme without the requirement of fixed or permanent establishment. There are questions over whether VAT to a non-EU country would be considered a tariff and if so, would that mean the tariff (VAT) should be imposed where the physical internet line comes ashore from the Atlantic Ocean, since that would be the physical point of import.

Further compounding the problem is the EU's own framework on the law. "electronic services" has been defined differently in several places across the 5 laws that actually make up the change, ranging from all digital services and goods (like PDFs and hosting) to only services that "require minimalistic human intervention". The latter of which would mean no change for most EDD users, as goods isn't included, and the types of services that meet that definition is extremely narrow. Hopefully they'll go back and correct all 5 of the directives to use the same definition at some point.

Further, the law change is only valid for those residents of countries who agreed to the 1998 Ottawa OECD agreeement. If you're in a country like Bolivia, which is not part of the EU and did not sign the agreement, the EU has absolutely zero basis on which to require vendors in Bolivia to collect EU VAT, regardless of whether or not the EU wants to write a law that says they must or not. The only VAT collection that the EU can mandate is an import style tax paid by and self-reported by the consumer inside the EU.

That being said, I think the law and its applications on businesses outside the EU will become clarified (and probably nullified) during 2015. I think it will be interesting to watch the EU to actually try to enforce a change that (as a recent study put, 63% of digital businesses in the EU and US don't even know exist).

If you were to comply with digital VAT in the strictest regards, you would have to calculate the rate based on (at minimum):

• Type of good ( is it a taxable type under VAT, is it a luxury item, can it be consumed at the physical location of the purchaser, can the purchaser only consume the item at their current physical location VAT jurisdiction)
• Current physical location of the purchaser ( if the item can be consumed immediately and only within the VAT jurisdiction they are currently in )
• Residence of the purchaser
• Address of the seller
• Whether or not the purchaser is a consumer or a business
• Is the person currently in motion (in a train? in a plane? where did they depart from? where are they going to? where are they now?)

From there you'd have to handle thousands of exceptions.

Imagine a person going to Sweden who buys a PDF on how to play soccer better for his soccer club on a plane. If the plane is in Sweden (landed) or over Swedish airspace, the PDF is VAT free under Swedish VAT laws, whereas if the plane is in the air and is not in Sweden or at the point of destination, the VAT is charged at the current location if and only if the PDF cannot be re-read once the plane lands. But then again, if you are in the VAT jurisdiction of origin where the plane hasn't taken off, its VAT at destination. Bare in mind however that if the plane is in the air, and the ebook can be read only throughout the entirely of the flight, VAT at point of origin.

And if you think the Swedish plane example is confusing, that example is straightforward compared to the example they have of a electronic service while on a cruise they have in the "explanatory notes" of the EU VAT commission's website, which spans 6 very long paragraphs. Note to self: don't try to do client work while on vacation in the EU.

With that said, its impractical to try to shove the logic to make tens of thousands of exceptional VAT cases complaint within core. The best we can do is make it so the VAT plugin and potential integrations with Taxamo or TaxCloud can be easier.

I think we can also look at adding dates (allowing a before and after) on a per country basis, and multiple per country, but we would need to be be extremely careful about not cluttering our UI with those features, which while not VAT specific non EU customers would rarely use. I think it would be interesting it we supplied the ability to make date change and type of taxes the VAT plugin could simply automatically generate the tax rules on install. Or it could (aforementioned) hook into a service that does the rules automatically.

We should also beef up the countries and provinces list in core. Those are going to be used alot more with future taxes like the new VAT.

So we could do

• [ ] Tax change date
• [ ] Integration w/taxamo and/or taxcloud and/or similar service
• [ ] Multiple tax rates per country
• [ ] Better core country/state/province dropdowns

If only the EU could simply charge a straight % across the board, no exceptions, where its the same for everyone b2b, b2c, and no difference between countries, or simply no VAT on digital goods, life would be so simple. Maybe one day :)

[chriscct7]

The other option to, is we could let the gateways determine the tax rate if someone only sold one type of good

[chriscct7]

It should be noted, the VAT extension for EDD was already updated to take most of this stuff into account. They handle the tax rate change according to the update details.

[pippinsplugins]

Guys, let's leave tax laws of each country out of this discussion and focus on what we can do to make it better for a wider audience.

[pippinsplugins]

@jdevalk So if it's based on the item being purchased and the location, can we do it based in postal code alone?

[jdevalk]

Country + province is enough

— Joost de Valk

If this email contains typo’s and is short, it might be sent from my mobile device. If it’s long that might still be true in which case I truly like you.

On Fri, Nov 21, 2014 at 11:55 PM, Pippin Williamson notifications@github.com wrote:

@jdevalk So if it's based on the item being purchased and the location, can we do it based in postal code alone?

Reply to this email directly or view it on GitHub: https://github.com/easydigitaldownloads/Easy-Digital-Downloads/issues/2805#issuecomment-64051053

[pippinsplugins]

What about the countries that don't use provinces? Do you happen to know how it is expected to be handled then?

[jdevalk]

Then country is enough. Country is enough for 99% of cases, actually it's just that there are some weird regions that are part of a country but not in Europe and thus not in the EU or where VAT rates are lower (like on the Canary Islands) which is why you need province.

[pippinsplugins]

Great, that makes things a lot simpler.

I'm going to milestone this for 2.3 to see if we can make some progress here. Any and all pull requests and further suggestions welcomed.

[Chillax14]

Along with collecting 2 pieces of non conflicting for every transaction and storing these transactions for 10 years, there are also a number of other requirements you need to take into account to comply with the 2015 VAT change. -

1. quarterly FX rates(if you are a US based merchants selling in dollars you need to get the RX rates from the ECB,
2. keeping up to date with VAT rate changes (do you know that there are 2 countries changing VAT rates on the 1st of January?) 3.Invoicing - there are 12 countries that you must comply with local invoicing requirements.
   Also you must bare in mind that if you develop a solution and you end up calculating VAT the wrong way for the users of the plugin - who takes responsibility?

Be carefully about VAT in the Canary Island, I would seek some advice.

Regarding someone buying an e-service on a plane - it is wherever the plane has taken off from is deemed to be the country where VAT should be paid.

[chriscct7]

The plane example is adapted from a European Commission Taxation and Customs Union guide example.

I don't think we're going to put invoice capability (beyond what EDD already provides) in core, since we have 2 extensions for generating invoices (in PDF & HTML format). Anything specific to VAT, like invoice styling, FX rates, and VAT rates, are going to be handled in the VAT extension.

We only have to store 2 proofs, and IP address and the billing address of the customer are both on the list. Requiring the billing address and capturing the IP address would require trivial amount of effort.I'm almost wondering on the double information if this information isn't already stored by the gateways.

Re:canary islands: We're just going to improve the dropdowns for countries and states/provinces so its more inclusive. Actual tax rate adjustments for specific provinces will be up to the user/VAT extension.

[Chillax14]

What happens if the IP address and the billing address don't match?

[chriscct7]

An IP address is a number assigned to a device on a computer network which is used for identification. Think of an IP address kinda like the numbers on the sides of books in a library. If you know the number of a book you want, you can see it using the number. Basically, an IP "address" isn't like a physical address, so they'll never match.

[chriscct7]

In case you were asking about a scenario where a customer's home IP address doesn't match a billing address, there's no solution to that. Most home internet providers don't provide static IP addresses, so the ones people have change all the time. Also, people could be buying things at places like schools, malls or libraries. There's nothing we can do about that unfortunately.

[Chillax14]

When I asked about the ip and billing address not matching - I meant if they were conflicting pieces of evidence. How will your plugin work?

[pippinsplugins]

We will only be collecting the information. It is not our job to determine of the submitted information is 100% accurate.

[Chillax14]

Ok, but take a website using your plugin how many transactions out of a 100 do you think will be accurate when you only use the ip and the billing address to ?

[pippinsplugins]

In my experience, the vast majority will be accurate.

[stephenharris]

While @jdevalk is correcting in asserting that US businesses selling to the EU are (in theory) required to comply, your right in pointing enforcing that is difficult to imagine (but you may want to consider http://en.wikipedia.org/wiki/Transatlantic_Trade_and_Investment_Partnership)

In any case I'm not convinced think this should be a core feature in EDD, and there is no harm in putting this into an extension.

@chriscct7 IP and billing address "matching" it only refers to the member state of the consumer. So validation in this respect would mean looking up the country and checking matches the billing address country.

In terms of "dynamic" VAT rates that @jdevalk was referring to with (1), I think @pippinsplugins hits the nail on the end. The only VAT rate that matters is in the one in effect now, but it's difficult to programatically update these rates when appropriate.

With view of this I'm proposing (in an extension) the following:

• Automating the creation of tax regions: i.e. 28 EU states and "non-EU" with the appropriate tax rate.
• Automatically parsing some source of current EU tax rates (probably using a hash to detect rate changes, prompting an update). This might leave a window of inaccurate VAT rates, but I am not too concerned.
• A client side and/or server side to check that IP address and billing country "match"
• The ability for a consumer to identify themselves as a business by providing a VAT number (checkout field)
• The ability to export a summary of tax regions sold to in a given date range (for ease of filling out VAT returns)

I have not looked thoroughly at EDD's source yet to ascertain whether any changes might be required for this to be practicable, but given your helpfully liberal application of hooks I suspect not.

@jdevalk makes some good points regarding different VAT categories, and I might add that EU small businesses which don't subscribe to VATMOSS but instead register with the VAT regime of each MSC may still enjoy the VAT threshold for purchases made by consumers in their own country - and may wish to have the option of passing the 0% VAT rate onto their consumers.

But these are discussions for the extension.

[pippinsplugins]

Pinging @bseddon as the author of the current EDD VAT extension to see what feedback he has. If possible, I'd love for all features contained in an extension to reside within a single extension to keep things as non-confusing as possible.

[bseddon]

Pippin is correct. Nothing about taxes is simple. It always looks like "all you gotta do is.." but the devil (and a devil with the ability to put away Al Capone) is in the detail. I believe our plugin meets the requirements. I put it together because I know our main business (financial risk management) has to be compliant.

At the risk of appearing self interested, this is functionality that is best in an extension. Not because there are not features from which EDD will benefit (for example, adding rates for all the EU countries) but because this topic is about regulation. From Jan 1st, EDD becomes a non-starter for any business in the EU if it does not have credible support for VAT. Adding this feature and that feature to EDD, no matter how desirable, is unlikely to meet all the regulatory requirements. Even if some EDD users have the legal and technical skills to combine these features into a viable, compliant tool, most will not. Creating an extension that 'just works' takes time and effort and by vesting these requirements in an extension maintained by people with a direct interest in the outcome seems like a sensible way forward for the majority of EDD users. Should my extension be the only one? Of course not. Want to create an alternative, knock yourself out. But I don't think the solution is to focus on features because this focus will miss the need to focus on the overriding need for a compliant solution in EDD.

In any event, we will be maintaining this plugin because as a business owner I want the assurance of being compliant and I'm not sure the core EDD source is the place I want to go for that assurance. An unrelated code change might have an unintended consequence on my compliance status. Plus, I think it will be highly desirable, especially in the period during which we adapt to the new rules, that updates affecting VAT compliance are not constrained by the release cycle of the core EDD.

The rules before and after Jan 1st are available on an EU commission web site and the tax departments of most EU member states have summaries on their web sites. Here is the one from mine, HMRC.

There are several different combinations of rules driving the requirement. But first let me say that all businesses, anywhere in the world, that sell to EU businesses or citizens should be collecting VAT and remitting it to one of the EU member states. This is not new. It's been a requirement since 2005. Of course it is not directly enforceable and, to my knowledge, no one does it but that's not the point. If at some point in the future the vendor chooses to incorporate in the EU or sell itself to a third party, it will likely face an audit as part of the disclosure process. Any uncollected/unpaid VAT may be regarded as a liability by the auditors which could affect the value of the vendor's business. This at least appears to be the view of Deloittes, one of the 'big four' accounting firms. If you are an owner of a non-EU business it is your judgement whether this is likely to be an issue. The challenge is that VAT, unlike US sale tax, is levied at rates around the 20% mark or higher so any potential liability may be significant.

Business or consumer

The first condition is whether or not the buyer of a product from a web site is an EU business or a consumer. If the buyer is a business then there is no tax to charge. Any EU business will use the 'recharge' mechanism to account for the tax in their books and offset the resulting output tax against other input taxes.

However it is a requirement that a vendor document their assertion that the buyer is a business by collecting the VAT number of the business. VAT numbers are issued to all EU businesses on request and can be validated through the EU commission's VIES web site/service. This information must be retained for 10 years. For years, my tax authority has required that we submit a quarterly list of sales to other EU member states which documents the VAT number of any business buyer and net value of the sale. I know from the personal experience of having entered a VAT number incorrectly on one return that these returns are checked and offenders receive a stiff letter warning of dire the consequences of submitting invalid VAT numbers (technically in English VAT Registration Number or VRN).

So our plugin does the VAT number check, using the SOAP interface exposed by the EU commission's VIES site, and also compares the buyer's declared company name with that stored by the EU commission as further (but optional on the part of the vendor) verification. The plugin also produces a report of the sales to businesses so the quarterly report can be completed. The VAT number is recorded in the payment record as part of the user_info array.

Consumer today

If the buyer is a consumer in an EU member state then VAT must be charged. At the moment this is simple because the VAT is applied using the prevailing rate of the country of the vendor's incorporation (or if they are a non-EU entity the EU member with which they have registered). VAT is not charged on sales to buyers outside the EU, even by vendors from within the EU.

EDD already handles this: set the EDD default rate to zero and define rates for each EU member state with an initial value set to the rate of the country of the vendor (20% in my case). Our plugin adds a button to the Taxes settings page that automatically adds a rate for each member state.

You can see this setup process in a video on YouTube.

At the moment we only allow for the standard rate of VAT. This suits the vast majority of users however they are able to override this on a product-by-product basis if it turns out a non-standard rate applies to one or more products.

Consumer from Jan 1st

From Jan 1st nothing changes when considering sales to businesses. However from this date VAT must be charged at the rate prevailing in 'the country of supply' (roughly, but not necessarily, where the buyer resides). This has two consequences.

One is that vendors must maintain VAT rates for each EU member state. The plugin already creates a tax rate for each EU member state and to make life a bit easier for users we've added the ability to import the prevailing standard rates by adding a button on to the Taxes settings page. The EU commission site and authoritative source of rate information does not support retrieving rates automatically and will only export in PDF format. So we've added, and intend to maintain, a list of current rates on our web site that the plugin is able to download. Whenever it becomes possible to pull them directly from the EU commission we will make that happen. If you know how to do that already, please let me know.

The other consequence of the rule change is that it is necessary to determine the country of supply and, so, the VAT rate to use. For physical goods there is no problem - it's the country in which the goods will be used. For digital services (the main target of the Jan 1st rule change) the rules (see the links above) state that two, non-contradictory pieces of evidence must be collected and retained for 10 years.

The web sites of the EU commission and of my tax authority give several examples of potential evidence such as the address of the buyer's bank account or of a buyers SIM card if appropriate or just the location of the user if the service purchased is geographically constrained. However relevant to sales of a digital service from an EDD powered web site, is the country of the IP address of the buyer (visitor) and that of the declared billing address. If these two are in agreement then you are done. However if these two do not agree (and there will be many instances in Europe when they do not) a site can ask the buyer to 'self-certify' that the billing address is the country of supply.

So our plugin verifies whether the country code of the user's IP address does match the country code of the billing address. If there is a match then the purchase can proceed. If there is no match then user is prompted to self-certify. The purchase will not proceed until the user checks a box. See this video, also on YouTube, to see this in action.

The VAT rate applied to a consumer sale and the self-certification status are recorded in the payment record so they can be accessed later as with any other property of a sale.

The plugin also includes a new sales-by-country report to make VAT reporting easier. The payment history export is also augmented to export IP address, VAT Rate and self-certification status so this information can be imported into, say, an accounting package.

I think @stephenharris summarises the requirements for sales to consumers nicely and our plugin does all these thing and more.

Adding features to EDD will be great and if they appear I expect I will use them. However features do not make a solution and what I am trying to do, and what I believe is needed, is to create a plugin that is a drop-in-and-forget extension that is useable by any EDD user not just those familiar with PHP, WordPress, EDD and VAT legislation.

Does the extension currently support all possible scenarios? Probably not. But by creating an extension any features and requirements identified by one user are then shared by others as part of a complete solution, features and compliance improvements they will receive by updating their version of the plugin. If the inevitable case-law means the rules must be interpreted in a specific way then the plugin can updated to reflect these interpretations and all EDD users (plugin users anyway) are kept compliant.

[stephenharris]

I should apologise - I neglected even to consider the fact that there might be an existing solution. @bseddon - you are correct that your plug-in does cover all the required features, with the exception of automatic updates of VAT. I realise there isn't an official computer parseable source of VAT rates, so I will probably use your plug-in in conjunction with a small one written by myself to implement auto-updates since I trust an official source over my commitment to keeping myself aware of the changes :). Thanks for posting here.

[rene-hermenau]

Adding this feature and that feature to EDD, no matter how desirable, is unlikely to meet all the regulatory requirements...Creating an extension that 'just works' takes time and effort and by vesting these requirements in an extension maintained by people with a direct interest in the outcome seems like a sensible way forward for the majority of EDD

A good point! I installed today the VAT Add-On by @bseddon and its a great piece of software which just works. On the other hand, having this in core is probably something european people will expect when they install it because its a requirement for every EU shop owner. Their need for a complete tax compliant ecommerce software must be treated very carefully for the future success of edd (in the EU). From the perspective of a developer i absolutely understand when this complex EU tax regulations and requirements does not flow into the edd core, but the reason for this missing edd feature should be described clear on the installation process in 2015 to not hold away people from using edd.

As a shop owner i prefer a payable Add-On, ( developed by someone who is using it for himself in the EU) instead using one of the transaction-fee charged tax webservices which will spring out like mushrooms soon or a tax implementation made by edd core developer which sits in the US and who has not to worry about complex EU regulatories. Don´t take this amiss @pippinsplugins I know you guys are able to do this, but i want you to make edd better and not to worry about this dumb and contraproductive EU stuff :-)

[pippinsplugins]

Thank you everyone for your valuable feedback.

I think it's clear that the existing VAT plugin from @bseddon is the best option for those stores that want to be wholly compliant. That leaves us with the simple question of:

what should we go ahead and add to EDD core in order to make things a bit easier for users, both those using the VAT add-on and those not using it?

I think these two items should be added:

1. Multiple tax rates per country using states/provinces and/or zip/postal codes
2. Multiple tax categories

Does that seem like a good plan to everyone? If so, I'm going to open each of these as a separate issue so their development can be more easily tracked.

[Chillax14]

@pippinsplugins I have continued to follow this conversion and what I see is that you are happy to build an half compliant plugin for your digital good platform? Every one of your users who sell into or in Europe is affected by this EU VAT change. Please correct me if I am wrong but I don't think you understand what happens if a merchant using your plugin is found to be non compliant ... also the additional work that needs to done to be fully compliant.

I think it is great you are proactive to offer a solution but you can't offer half solution - tax authorities won't accept half attempts to be compliant..

[bseddon]

My view is that you analogy is wrong. When a UK company uses EDD to sell software to a US company it does not include VAT and to justify this it should also provide, and the US buyer should demand, an IRS form W8-BEN to certify that no tax withholding is required on the payment of the invoice. It's been this way for many years. By your own logic I should be demanding that the EDD core comes with a W8-BEN module. By rights I should be even more surprised that EDD does not come with a W8-BEN module because this a tax requirement of the US government. Of course I don't because it would be unreasonable.

EDD is not compliant for GST in Australia (though it does if you use my plugin), or Brazil or China. Are really suggesting that all budding ecommerce packages should support all tax regimes around the world out-of-the-box?

Sometimes we have to choose to take the bits we want and understand why we want them. Then judge whether or not the lack of a feature in the core vs an extension vs not being there at all justifies looking at another platform. Perhaps that's the situation in which your find yourself.

[Chillax14]

My Friend, I think you have taken my comment the wrong way. I know that EDD is not obligated to look after VAT or TAX on a merchant's sales but... what if you heard Drupal was promoting a half compliant EU VAT plugin. What would you think? Would you use it?

Tax is a thing you can't do in half measures.

[chriscct7]

@Chillax14 If you are going to comply with the law, and continue to sell digital goods & services to EU customers, your options are:

• Use the EU VAT extension
• Use the Taxamo extension when it comes out

If you are not going to comply with the law, and do not with to sell digital goods and services to EU customers, we have an extension for that as well.

[chriscct7]

At this point, each proposal for EDD core to implement has been split off into issues #2818, #2819, #2820, and #2821.

[pippinsplugins]

@Chillax14 It's not about being 100% compliant with VAT in EDD core; it's that EDD cannot possibly in any imaginable scenario be 100% compliant with every law around the world. It's simply not possible. We have to make decisions around what is best to put in EDD core for the majority of users and then allow the other features to be handled by extensions. That's one of the beautiful things about plugins that are as extensible as EDD: they can realistically support every country and every law in the world, it just requires certain extensions for some people.

[bseddon]

@stephenharris Checking an official source for updates is a good idea. Your comment also prompted me to add an admin notice to the plugin that will appear when the rates available on our site have updated so users do not have to trust themselves to know if our rates have been updated. It doesn't alter the need for your check but it's another aid to users to help them be compliant.

[Chillax14]

@chriscct7- You mention that the two possibilities are the EU VAT extension and the Taxamo extension - when is the Taxamo extension going to be available?

[chriscct7]

We aren't sure. @pippinsplugins is working on that right now.

[polimorfico]

@pippinsplugins, we already updated our EDD VAT Calculator pluging to deal with all the VAT scenarios in the EU.

[pippinsplugins]

Thanks @polimorfico I'll take a look at that.

[bethroberts22]

Just to let you know we’ve updated our EU EDD VAT plugin to give users, particularly US sellers, the ability to restrict sales to EU consumers because these sales require that even non-EU businesses register for VAT with the tax authority of an EU member state. Vendors will probably want to continue selling to EU businesses because different rules apply and these sales do not require VAT registration. http://www.lyquidity.com/wpstore/

[pippinsplugins]

Thanks for the update @bethroberts22

Note for all: an extension for Taxamo.com integration is getting released any day. It will be free on WordPress.org

[pippinsplugins]

I think this can be closed now and continued with #2819 (multiple rates per country) and #2820 (multiple tax types).