Wrong tax calculation

[dathwa]

Hello. Looks like we still have tax calculation issues.
E.g. Cart value is £50.00. Tax is 20%.

Tax seems to be calculated per line, introducing rounding errors.
See image below...
10 / 1.2 = 8.33
5 items * 8.33 = 41.65 pre-tax value
10 - 8.33 = 1.67
5 items * 1.67 = 8.35 Tax (wrong)

The correct calculation should be...

50 / 1.2 = 41.67 pre-tax value
50 - 41.67 = 8.33 is the correct tax value

Is there any chance this will be fixed in 3.2, and do we have a time-line yet for this?

Still a great plugin. Thanks all for the work.

[SamBrishes]

Hello,

thanks for your message. To be honest, I wasn't quite sure if taxes are calculated "per line" or using the net-worth of "all lines" within the same rate.

Invoice Tools

Thus, I tried "professional" invoice experts, such as Invoice Ninja and PayPal Business. However, in your case, you've 5 products, not stackable, each one as a separate invoice item. According to both, PayPal and Invoice Ninja, the calculation per line is correct.

Invoice Ninja (5 lines)	Invoice Ninja (5 quantity)	PayPal (5 lines)

Internet

Well, that doesn't have to be right for sure... Thus, I consulted the internet. Since I'm Austrian, I tried to find a correct answer according to Austrian / German laws (we've pretty much the same, just different tax rates). And ended up with bare hands and even more questions...

ChatGPT

Well.. last but not least, I asked ChatGPT (I know, that's pretty much worthless in front of any judge, but anyways)

Final Answer

First of all, it's not a rounding error, it is a deliberate and correct calculation. Which makes me happy, since I did code this part of my PriceBag class right. YaY

Of course, that doesn't help you any further. So my suggested solution would be to configure this calculation as a additional setting. This way everyone can decide for themselves whether the calculation should be made per invoice item or per tax-rate stack. However, this will take some time, since PriceBag only supports the first way atm.

Is there any chance this will be fixed in 3.2, and do we have a time-line yet for this?

This part of the calculation / PriceBag system was supposed to be shipped in 3.2 (as this was also the most problematic part of the mall extension). However, since 3.2 has been delayed due to the release of OC v3.6 anyway, I guess I'll try to find some time adding the "configurable" tax-calculation part.

So yes, should be fixed in 3.2.

~ Sam.

[SamBrishes]

Since, I'm not running a company / writing invoices myself...

@tobias-kuendig How is this regulated in Switzerland? Tax calculation per invoice line or per "tax-rate stack" (net value of all products of the same VAT regulation)?

I'm pretty sure that this part of the law is similar for all three DACH countries.

[dathwa]

Hi @SamBrishes
Thanks for the analysis. Much appreciated. It's a whole can of worms, I know. FWIW, our client is UK based in the UK, and leans towards a "tax-rate stack". I'll feed this post back to them. Certainly, an option to switch between either approach would be ideal.

[dathwa]

Hi @SamBrishes.
Using the out of the box, 'tax per line' approach , I think the totalPreTaxes and totalProductPreTaxes in offline_mall_orders
must be wrong. The "total pre taxes" should be 41.65. Make sense?

[SamBrishes]

Hello,

sorry for the long wait. I fell ill and then sank into work after.

Anyways, I could ask a professional accountant how VAT is calculated correctly and the sad truth is, that there is no correct way... or too many correct ways... depends on how you want to see it.

So both "VAT per line" and "VAT based on total" are valid. There is no preferred solution in any way, and rounding errors due to different calculations are accepted by state tax authorities. Thus. as already said, the best way is to support both, VAT-per-Line and VAT-on-Total calculations. In addition to both, we may can also add an additional option which prevents labelling VAT at all, as necessary for (at least) all DACH* countries under certain conditions.

However, the calculation of this itself is not really difficult, but the calculation of discounts requires a little more work, especially when different VATs are used.

Sincerely,
Sam.

*DACH stands go Germany-Austria-Switzerland

[dathwa]

Hi @SamBrishes.
I hope you've made a full recovery.
Yes - it's not a perfect science.
I look forward to any improvemnts on this, especially with discounts.
Cheers.