<p>A few weeks ago we have made recent fix to Craft Commerce in 2.x that takes into account the removed tax from a line item when calculated the other tax rate.</p>

<p><a href="https://github.com/craftcms/commerce/blob/develop/CHANGELOG-v2.md#fixed-7" rel="nofollow noreferrer">https://github.com/craftcms/commerce/blob/develop/CHANGELOG-v2.md#fixed-7</a></p>

<p>With a single included VAT rate that matches the default zone:</p>

<p><a href="https://i.sstatic.net/IarqS.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/IarqS.png" alt="German VAT"></a></p>

<p>And then with the removed default VAT tax, and the new tax added, now are the same amounts if they are the same %:</p>

<p><a href="https://i.sstatic.net/BTVuJ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/BTVuJ.png" alt="UK VAT first removes the German VAT and adds the UK Vat"></a></p>

<p>Let us know if you have tried the latest Commerce release and if it fixes the issues you mention.</p>

CC BY-SA 4.0
2019-03-26T06:14:07.207Z
As for the rounding system in Craft Commerce, we are adding rounding options: https://github.com/craftcms/commerce/pull/697#issuecomment-471134340
Luke Holder
CC BY-SA 4.0
2019-03-26T06:09:59.007Z
2019-03-26T06:09:59.007Z
Luke Holder
<p>We've just completed our first Craft Commerce website at <a href="https://basedesign.com" rel="nofollow noreferrer">Base Design</a>. Overall everything went well but we encountered issues with taxes and the way VAT works on online sales in the EU. Craft Commerce didn't seem to integrate as well as expected with those taxes and we eventually had to use a few tricks we're not proud of to make it work as expected (or so we thought).</p>

<p>As we are about to start a new e-commerce project in a few months I took a bit of time to see what changed in Craft Commerce since then and what we could have done better... but stumbled on more issues.</p>

<p>Disclaimer: it's a long one, sorry about that.</p>

<h2>A bit of context</h2>

<p>As you know, the EU is made of a bunch of different countries. Every country has its own laws and, for this reason, taxes vary from country to country in the EU.</p>

<p>For example, the standard VAT rate (VAT is for "Value-Added Tax", the most <em>popular</em> tax in the EU) is 20% in France and the Netherlands, 21% in Belgium and Latvia, 27% in Hungary and 17% in Luxembourg. But of course lots of exceptions exist and these exceptions are country-based.</p>

<p>All that to help you understand that when talking about VAT in the EU, we're actually talking about different VATs in every country. Luckily for us, the VAT that needs to be used on an e-commerce website is the one of the country where the company selling the products is established, not the one of the country where the goods are being bought from. It means that the same VAT can be applied to all sales on a website... where VAT is relevant (actually this <a href="http://www.vatlive.com/eu-vat-rules/distance-selling/distance-selling-eu-vat-thresholds/" rel="nofollow noreferrer">isn't always true</a> but let's ignore that for now). Good!</p>

<p>Where it gets complex is that VAT is not always due. For example, if a French company buys from an company established in a <strong>different</strong> EU country they won't be asked to pay any VAT. This rule only applies to companies; individuals can't benefit from this tax exemption. Be careful though: if a company is buying from another company in the same country this exemption won't apply and the VAT will still need to be paid.</p>

<p>Also, when some goods are being sold to individuals or companies outside of the EU, VAT shouldn't be applied either.</p>

<h2>Example</h2>

<p>I recently created this list that sums up most cases. The assumption made is that the subject company is Belgium-based and selling a 100€-worth product.</p>

<ul>
<li>If customer is a BE  citizen<br>
&rArr; 121€ with 21% VAT line</li>
<li>If customer is a BE  company<br>
&rArr; 121€ with 21% VAT line</li>
<li>If customer is a EU  (not BE) citizen<br>
&rArr; 121€ with 21% VAT
line</li>
<li>If customer is a EU  (not BE) company<br>
&rArr; 100€ with "Intra-EU
VAT" VAT line</li>
<li>If customer is a ROW*  citizen<br>
&rArr; 100€ with no mention of VAT</li>
<li>If customer is a ROW*  company<br>
&rArr; 100€ with no mention of VAT</li>
</ul>

<p><strong><em>ROW</strong> means Rest of the World.</em></p>

<h2>How we applied this logic to Craft Commerce</h2>

<p>In our minds, there were two different ways we could apply this logic to Craft Commerce.</p>

<p><strong>1. Deduce VAT when not needed</strong></p>

<p>The first way to make this work would have been to input all product prices with a VAT-included price. If we use the above example, the product price would have been 121€.</p>

<p>The price displayed on the website by default would have been that price and we could have remove the VAT taxes when the customer was either a EU company (not BE) or a ROW citizen or company.</p>

<p>To make this work, we created the following Tax Rate: </p>

<p><a href="https://i.sstatic.net/1CTyR.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/1CTyR.png" alt="tax rule for BE"></a></p>

<p>Up until then, everything worked as expected on orders that would be shipped to Belgium. Company or individual will always be billed 121€.</p>

<p>Then we needed to take care of the rest of the EU and created the following Tax Rate:</p>

<p><a href="https://i.sstatic.net/HrU2n.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/HrU2n.png" alt="tax rule for EU"></a></p>

<p>By doing this, when an order from a EU citizen (not BE) was created, we were asking Craft Commerce to:</p>

<ol>
<li>remove the original BE Tax Rate and condition</li>
<li>apply the EU Tax Rate and condition</li>
<li>if it's a EU company, don't add the tax</li>
<li>output the total</li>
</ol>

<p>But this is where we had to stop. Indeed, the taxes calculation there wasn't correct. This is what we got:</p>

<p><a href="https://i.sstatic.net/SlpCy.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/SlpCy.png" alt="resulting math"></a></p>

<p>Notice the two "Tax" lines. They both have a value of 21% but only the first one is calculated the way we expect it to be (121€ &divide; 1.21). The second one should equal to 121€ &divide; 1.21 &times; 0.21 = 21€ but it is actually equal to 25.41€ (121€ &times; 0.21). Basically it just doesn't take into account the previous tax adjustments when calculating the new adjustment.</p>

<p>We realised that this way of calculating taxes might be relevant in some regions and contexts and Craft Commerce was probably developed in that optic. So at this point we were only bummed that there wasn't any option to make it possible for a tax adjustment to be aware of all previous tax adjustments.</p>

<p>But we still had another option in mind.</p>

<p><strong>2. Add VAT when needed</strong></p>

<p>The alternative we thought of was to input all product prices without VAT. If we use the example above, the product price would have been 100€.</p>

<p>To display the default price on the website, we would create a helper that would show that default price &times; 1.21 => 121€. It made us work way more than  expected but still, it worked quite well.</p>

<p>Creating the different tax rules for Belgium, the EU and the ROW was then easier and we didn't expect any issue anymore.</p>

<p>But an annoying one eventually appeared: rounding errors. Let's take the example of a product that must appear at 55€ on the website.</p>

<p>Following the previous logic, this product should be added to Craft at a price of 45.4545€ (55€ &divide; 1.21). When we show the price on the website, we use the helper and the resulting price is 45.4545€ &times; 1.21 = 54,9999€ which we round to 55€. All good.</p>

<p>Now when we enter the checkout process it was too dangerous to use our helper. So we started relying on the Craft Commerce engine. But that engine calculates prices in another way as what we had anticipated. Basically, it will only use the first 2 decimals. So 45.45€ (our base price with 2 decimals) &times; 1.21 is now worth 54.99€. It looks inconsistent.</p>

<p>You'll say we could just adapt our base price but that's actually not a good idea. First, 45.46€ &times; 1.21 will amount to 55.01€, not 55€.</p>

<p>On top of that, when we add the same product multiple times in our basket, the price becomes:</p>

<ul>
<li>45.45€ &times; 1.21 &times; <strong>2</strong>: 109.99€</li>
<li>45.45€ &times; 1.21 &times; <strong>3</strong>: 164.98€</li>
<li>45.45€ &times; 1.21 &times; <strong>4</strong>: 219.98€</li>
<li>45.45€ &times; 1.21 &times; <strong>5</strong>: 274.97€</li>
<li>45.45€ &times; 1.21 &times; <strong>6</strong>: 329.97€</li>
</ul>

<p>So what the customer would actually see now looks like this: 54,99€ &times; 6 equals to 329,97€. <strong>Remember, what we wanted was: 55€ &times; 6 equals to 330€</strong>.</p>

<p>It's not professional.</p>

<h2>The solution</h2>

<p>Well, this is where we need help. As you can see, none of these options are viable: the first one outputs wrong totals and the second one doesn't output nicely-rounded numbers.</p>

<p>To us, the solution to the first option could be that we would be allowed to check the "The tax is already included in the taxable subject" in multiple Tax rates. I understand that this would change a few things in the way Craft Commerce works but it is how I expected it to work from the beginning.</p>

<p>The solution to the second option would be that Craft Commerce doesn't round numbers to 2 decimals when processing them. It might be simpler but that option still looks a bit dirty in my opinion.</p>

<p>We're probably not the first ones encountering this issue so we were wondering how others handled the situation. Maybe another solution exists? In any case, I'd be very interested to discuss it with anyone who is developing a Craft Commerce website for a EU-based company.</p>

<p>Thanks in advance!</p>

CC BY-SA 3.0
2017-06-12T20:37:02.657Z
I'm curious, on solution two, when you say "helper" are you talking about Adjusters? https://craftcommerce.com/docs/adjusters
Natetronn
CC BY-SA 3.0
2017-06-12T21:52:27.517Z
@Natetronn No, sorry, I should have more clear. It was in the context of showing the price in the frontend. To me helpers are simple Twig macros that are used to do a single thing. In this context, transforming the '100.0000' float into a '121€' string.
Pierre Stoffe
CC BY-SA 3.0
2017-06-12T21:56:26.083Z
@Natetronn But actually, even though I excluded that solution a few hours ago, using custom adjusters might not be such a bad idea after all. You gave me something to dig into at least, thanks!
Pierre Stoffe
CC BY-SA 3.0
2017-06-12T23:11:19.990Z
I see. You labeled in plugin-craftcommerce and why I asked. And yes, something to dig into. Off the top of my head, I was thinking you could use an Adjuster to make the numbers round using PHP `round()`. I also wonder what else is available to you in there. Also, FWIW, Twig has [round](https://twig.sensiolabs.org/doc/2.x/filters/round.html) and [number_formant](https://twig.sensiolabs.org/doc/2.x/filters/number_format.html) filters.
Natetronn
CC BY-SA 3.0
2017-06-13T08:09:44.447Z
Oh yes, if I'm not mistaken 'plugin-craftcommerce' is the tag for Craft Commerce (which is a plugin), not for plugins built on top of Craft Commerce :) I'll look into custom adjusters today and will post the results back here. Thanks!
Pierre Stoffe
CC BY-SA 3.0
2017-06-13T19:35:09.417Z
Oh yeah, that's true; Craft Commerce is a plugin. It's so freaking huge you might as well call it a CMS, though. lol
Natetronn
CC BY-SA 3.0
2017-09-14T15:44:55.193Z
Not a technical solution, but since you're calculating backwards from the price + VAT, are you able to adjust the original item price. In this case, 45.46€? Or even 45.4546€?
Stephen Callender
CC BY-SA 3.0
2017-09-15T05:04:49.807Z
@PierreStoffe Can you please send a DB dump of your installation with the orders in the example in the question to support@craftcommerce.com - Also let me know the order ID or order Number of the cart you used in the example.
Luke Holder
CC BY-SA 4.0
2024-03-19T07:23:49.650Z
@PierreStoffe as this post has received a ton of traffic (and is for Craft 2) would you consider either closing or marking a solution?
cherrykoda
<plugin-craftcommerce>
Issues with Craft Commerce and VAT taxes
# Issues with Craft Commerce and VAT taxes

(Asked by: username_0 on 2017-06-12)

We've just completed our first Craft Commerce website at [Base Design](https://basedesign.com). Overall everything went well but we encountered issues with taxes and the way VAT works on online sales in the EU. Craft Commerce didn't seem to integrate as well as expected with those taxes and we eventually had to use a few tricks we're not proud of to make it work as expected (or so we thought).

As we are about to start a new e-commerce project in a few months I took a bit of time to see what changed in Craft Commerce since then and what we could have done better... but stumbled on more issues.

Disclaimer: it's a long one, sorry about that.

## A bit of context

As you know, the EU is made of a bunch of different countries. Every country has its own laws and, for this reason, taxes vary from country to country in the EU.

For example, the standard VAT rate (VAT is for "Value-Added Tax", the most *popular* tax in the EU) is 20% in France and the Netherlands, 21% in Belgium and Latvia, 27% in Hungary and 17% in Luxembourg. But of course lots of exceptions exist and these exceptions are country-based.

All that to help you understand that when talking about VAT in the EU, we're actually talking about different VATs in every country. Luckily for us, the VAT that needs to be used on an e-commerce website is the one of the country where the company selling the products is established, not the one of the country where the goods are being bought from. It means that the same VAT can be applied to all sales on a website... where VAT is relevant (actually this [isn't always true](http://www.vatlive.com/eu-vat-rules/distance-selling/distance-selling-eu-vat-thresholds/) but let's ignore that for now). Good!

Where it gets complex is that VAT is not always due. For example, if a French company buys from an company established in a **different** EU country they won't be asked to pay any VAT. This rule only applies to companies; individuals can't benefit from this tax exemption. Be careful though: if a company is buying from another company in the same country this exemption won't apply and the VAT will still need to be paid.

Also, when some goods are being sold to individuals or companies outside of the EU, VAT shouldn't be applied either.

## Example

I recently created this list that sums up most cases. The assumption made is that the subject company is Belgium-based and selling a 100€-worth product.

* If customer is a BE citizen  
  ⇒ 121€ with 21% VAT line
* If customer is a BE company  
  ⇒ 121€ with 21% VAT line
* If customer is a EU (not BE) citizen  
  ⇒ 121€ with 21% VAT
  line
* If customer is a EU (not BE) company  
  ⇒ 100€ with "Intra-EU
  VAT" VAT line
* If customer is a ROW\* citizen  
  ⇒ 100€ with no mention of VAT
* If customer is a ROW\* company  
  ⇒ 100€ with no mention of VAT

***ROW*** means Rest of the World.

## How we applied this logic to Craft Commerce

In our minds, there were two different ways we could apply this logic to Craft Commerce.

**1. Deduce VAT when not needed**

The first way to make this work would have been to input all product prices with a VAT-included price. If we use the above example, the product price would have been 121€.

The price displayed on the website by default would have been that price and we could have remove the VAT taxes when the customer was either a EU company (not BE) or a ROW citizen or company.

To make this work, we created the following Tax Rate:

[![tax rule for BE](https://i.sstatic.net/1CTyR.png)](https://i.sstatic.net/1CTyR.png)

Up until then, everything worked as expected on orders that would be shipped to Belgium. Company or individual will always be billed 121€.

Then we needed to take care of the rest of the EU and created the following Tax Rate:

[![tax rule for EU](https://i.sstatic.net/HrU2n.png)](https://i.sstatic.net/HrU2n.png)

By doing this, when an order from a EU citizen (not BE) was created, we were asking Craft Commerce to:

1. remove the original BE Tax Rate and condition
2. apply the EU Tax Rate and condition
3. if it's a EU company, don't add the tax
4. output the total

But this is where we had to stop. Indeed, the taxes calculation there wasn't correct. This is what we got:

[![resulting math](https://i.sstatic.net/SlpCy.png)](https://i.sstatic.net/SlpCy.png)

Notice the two "Tax" lines. They both have a value of 21% but only the first one is calculated the way we expect it to be (121€ ÷ 1.21). The second one should equal to 121€ ÷ 1.21 × 0.21 = 21€ but it is actually equal to 25.41€ (121€ × 0.21). Basically it just doesn't take into account the previous tax adjustments when calculating the new adjustment.

We realised that this way of calculating taxes might be relevant in some regions and contexts and Craft Commerce was probably developed in that optic. So at this point we were only bummed that there wasn't any option to make it possible for a tax adjustment to be aware of all previous tax adjustments.

But we still had another option in mind.

**2. Add VAT when needed**

The alternative we thought of was to input all product prices without VAT. If we use the example above, the product price would have been 100€.

To display the default price on the website, we would create a helper that would show that default price × 1.21 => 121€. It made us work way more than expected but still, it worked quite well.

Creating the different tax rules for Belgium, the EU and the ROW was then easier and we didn't expect any issue anymore.

But an annoying one eventually appeared: rounding errors. Let's take the example of a product that must appear at 55€ on the website.

Following the previous logic, this product should be added to Craft at a price of 45.4545€ (55€ ÷ 1.21). When we show the price on the website, we use the helper and the resulting price is 45.4545€ × 1.21 = 54,9999€ which we round to 55€. All good.

Now when we enter the checkout process it was too dangerous to use our helper. So we started relying on the Craft Commerce engine. But that engine calculates prices in another way as what we had anticipated. Basically, it will only use the first 2 decimals. So 45.45€ (our base price with 2 decimals) × 1.21 is now worth 54.99€. It looks inconsistent.

You'll say we could just adapt our base price but that's actually not a good idea. First, 45.46€ × 1.21 will amount to 55.01€, not 55€.

On top of that, when we add the same product multiple times in our basket, the price becomes:

* 45.45€ × 1.21 × **2**: 109.99€
* 45.45€ × 1.21 × **3**: 164.98€
* 45.45€ × 1.21 × **4**: 219.98€
* 45.45€ × 1.21 × **5**: 274.97€
* 45.45€ × 1.21 × **6**: 329.97€

So what the customer would actually see now looks like this: 54,99€ × 6 equals to 329,97€. **Remember, what we wanted was: 55€ × 6 equals to 330€**.

It's not professional.

## The solution

Well, this is where we need help. As you can see, none of these options are viable: the first one outputs wrong totals and the second one doesn't output nicely-rounded numbers.

To us, the solution to the first option could be that we would be allowed to check the "The tax is already included in the taxable subject" in multiple Tax rates. I understand that this would change a few things in the way Craft Commerce works but it is how I expected it to work from the beginning.

The solution to the second option would be that Craft Commerce doesn't round numbers to 2 decimals when processing them. It might be simpler but that option still looks a bit dirty in my opinion.

We're probably not the first ones encountering this issue so we were wondering how others handled the situation. Maybe another solution exists? In any case, I'd be very interested to discuss it with anyone who is developing a Craft Commerce website for a EU-based company.

Thanks in advance!

**Tags:** plugin-craftcommerce

> **Comments:**
> **username_1**: I'm curious, on solution two, when you say "helper" are you talking about Adjusters? https://craftcommerce.com/docs/adjusters  
> **username_0**: @username_1 No, sorry, I should have more clear. It was in the context of showing the price in the frontend. To me helpers are simple Twig macros that are used to do a single thing. In this context, transforming the '100.0000' float into a '121€' string.  
> **username_0**: @username_1 But actually, even though I excluded that solution a few hours ago, using custom adjusters might not be such a bad idea after all. You gave me something to dig into at least, thanks!  
> **username_1**: I see. You labeled in plugin-craftcommerce and why I asked. And yes, something to dig into. Off the top of my head, I was thinking you could use an Adjuster to make the numbers round using PHP `round()`. I also wonder what else is available to you in there. Also, FWIW, Twig has [round](https://twig.sensiolabs.org/doc/2.x/filters/round.html) and [number_formant](https://twig.sensiolabs.org/doc/2.x/filters/number_format.html) filters.  
> **username_0**: Oh yes, if I'm not mistaken 'plugin-craftcommerce' is the tag for Craft Commerce (which is a plugin), not for plugins built on top of Craft Commerce :) I'll look into custom adjusters today and will post the results back here. Thanks!  
> **username_1**: Oh yeah, that's true; Craft Commerce is a plugin. It's so freaking huge you might as well call it a CMS, though. lol  
> **username_2**: Not a technical solution, but since you're calculating backwards from the price + VAT, are you able to adjust the original item price. In this case, 45.46€? Or even 45.4546€?  
> **username_3**: @PierreStoffe Can you please send a DB dump of your installation with the orders in the example in the question to support@craftcommerce.com - Also let me know the order ID or order Number of the cart you used in the example.  
> **username_4**: @PierreStoffe as this post has received a ton of traffic (and is for Craft 2) would you consider either closing or marking a solution?  

---

## 1 answers

### Answer by username_3 on 2019-03-26. Score: 1 | Accepted answer

A few weeks ago we have made recent fix to Craft Commerce in 2.x that takes into account the removed tax from a line item when calculated the other tax rate.

<https://github.com/craftcms/commerce/blob/develop/CHANGELOG-v2.md#fixed-7>

With a single included VAT rate that matches the default zone:

[![German VAT](https://i.sstatic.net/IarqS.png)](https://i.sstatic.net/IarqS.png)

And then with the removed default VAT tax, and the new tax added, now are the same amounts if they are the same %:

[![UK VAT first removes the German VAT and adds the UK Vat](https://i.sstatic.net/BTVuJ.png)](https://i.sstatic.net/BTVuJ.png)

Let us know if you have tried the latest Commerce release and if it fixes the issues you mention.

> **Comments:**
> **username_3**: As for the rounding system in Craft Commerce, we are adding rounding options: https://github.com/craftcms/commerce/pull/697#issuecomment-471134340  

---

