WHMCS causing tax evasion

[Kian]

Before we start keep in mind that in order to explain the issue I am reporting, I'm going to describe you just very simple example. Actually there are even more issues that would be hard to explain. What I am reporting here may seem a minor problem but could lead to serious troubles: tax evasion.

Scenario:

• Tax Type: Inclusive
• Tax Rate: 22%

Let's create an invoice for an item that costs 14 € and focus on the calculations that WHMCS does.

• Amount: 14 €
• Subtotal: 11.48 €
• 22% Tax: 2.52 €
• Total Due: 14 €

We have 2.52 € of tax. Let's see if it's correct. 22% of 11.48 € is 2.5256 €. What is wrong with that?

According to the law of my country, this value must be approximated to 2.53 €. I bet that it's the same also in many other countries. It may seem not a serious question but this is an underpayment of tax.

My Revenue Agency for an amount of 11.48 € expects a tax of 2.53 €. Of course if we sum 11.48 + 2.53 we get 14.01 that is wrong too. The solution to this problem is not easy as you might expect.

Did you know that? Am I missing something? What do you think? How do you deal with such problems?

Edited August 9, 2018 by Kian

[brian!]

10 minutes ago, Kian said:

Did you know that? Am I missing something? What do you think? How do you deal with such problems?

which version of WHMCS are you trying this with?

WHMCS changed the way tax is calculated in v7.4 (though they didn't tell - or even ask - us first!) and that's detailed in the thread below...

that eventually (5-6 months) led to a change being made in v7.5 on the Tax Rules page where you are now given the choice of two methods of how to calculate the tax.

[Kian]

Then it's even worse. The issue I'm describing probably exists since the first release of WHMCS. Before v7.4 it was just more rare to happen.

Before it was possible to get a deficit of 0.01 per invoice. Now you can get a deficit of 0.01 per line! Say that you have 10x items that cost 14 € each. Now there's an issue of 0.06 € which even worse! Oh damn... you can't belive what I'm facing because of this issue.

[Remitur]

Does this issue happen only with sum which does not allow exact VAT splitting?

That's to say: 14,00 is an unlucky number, because:

11.47 + 22% = 13.99

11.48 + 22% = 14.01

So, the question is: if you set the price to 13.99 or 14.01 instead of 14.00, doe everything works fine?

If it's so, the fix is: never use prices which can't be exactly splitted, and put your "vat inclusive price" to 13.99 ...

Another fix: keep that tax officer which thaught about creating a 22% rate vat, and hang it up!

(BTW: it seems that sometimes VAT will be bring to 22,5% ... I'm waiting for accountancy software developers commiting suicide about this... 😄 )

 

[Kian]

I didn't talk about possible fixes on purpose because the question would become wider. I already have a possible fix but it took me 328 lines of codes and 40 queries! Why? Because the initial fix causes chain problems. Every time you fix a problem a new one takes its place.

What the hell... with 6 items (14 € each) I'm underpaying taxes by 0.03 already just on one invoice! Not to mention that the numbers on invoice are wrong. This issue is severe.

Recap:

• Tax evasion
• Wrong numbers on invoice
• If credit is applyed on the invoice you're also stealing money from your customers

2 hours ago, brian! said:

that eventually (5-6 months) led to a change being made in v7.5 on the Tax Rules page where you are now given the choice of two methods of how to calculate the tax.

This is crazy.

Edited August 9, 2018 by Kian

[Remitur]

I agree it's an ssue (and that WHMCS's guys should fix this and others rounding issues in invoices).

But it's quite common... I know of others billing softwares with same issue.

And also of an automatic cash register which did the same... until the release of an update of the firmware ... somewhat about two years later the bug was discovered... 😄

But about WHMCS: it should not happen for more than 1c in invoice: AFAIK, the VAT in single rows are calculated with 3 decimals, so it should not happen

Setup => payments => tax rules => tax calculation method =>  Calculate based on collective sum of the taxable line items

[Remitur]

More: there're situations which does not allow any solution.

i.e.: If you do two different sells of € 7 each (that's to say; € 5,74 + 22% = 7), and then you issue a single invoice at the end of month, your invoice will be 5,75 + 5,74 = 11,48 + 22% = 14,01

There's no solution, but the hanging of tax officer... 😄

 

[brian!]

when you have to start double-checking that billing software is calculating the correct figures in an invoice, then that's game over - if WHMCS does nothing else correctly, it at least needs to be accurate when billing under all circumstances - and not just those that WHMCS themselves find acceptable.

I lost a lot of faith in WHMCS over that v7.4 tax fiasco.. and it was dwindling even before that!

6 minutes ago, Remitur said:

There's no solution, but the hanging of tax officer... 😄

we'll leave that as a last resort... 

[Kian]

Sadly for me it's more than an issue 😤 I'm generating monthly invoices so that people can pay them with a single payment. Administrators can save a lot of paperwork and transaction fees. After 6 months of development the module was almost complete (there are tons of other features) but now I have to face this.

1 hour ago, Remitur said:

Another fix: keep that tax officer which thaught about creating a 22% rate vat, and hang it up!

The problem is not with 22%. It can happen in tens of other ways:

• Specific tax rate
• Specific tax rate 2
• Specific combination of tax rate & invoice amount
• Specific invoice amount
• Specific overpayments
• Specific credit usage
• Specific credit usage & overpayments
• Specific credit usage & tax rate
• Specific credit csage & invoice amount
• Specific credit Usage & tax rate & invoice amount
• Specific coupon codes
• Specific coupon codes & tax rate
• Specific coupon codes & tax rate 2

I can go on forever.

21 minutes ago, brian! said:

when you have to start double-checking that billing software is calculating the correct figures in an invoice, then that's game over - if WHMCS does nothing else correctly, it at least needs to be accurate when billing under all circumstances - and not just those that WHMCS themselves find acceptable.

I lost a lot of faith in WHMCS over that v7.4 tax fiasco.. and it was dwindling even before that!

we'll leave that as a last resort... 

If only they could allow me to run my code to perform the right calculation myself. I'm forced to run FORTY queries to fix this mess. I can adapt to anything but this is too much. Alternatively the should fix the core so that it performs the right calculations. Damn, damn, damn. This is the first time I'm stuck with WHMCS.

Edited August 9, 2018 by Kian

[Remitur]

Just an idea:

• leave WHMCS create the invoice, with wrong tax
• then, through an hook, before sending it to the user:
  • get the data of the invoice from tblinvoices
  • check if subtotal, tax, taxrate and total are right
  • if not right: correct them and update using mysql

Doing so, just a single issue may still exist: the one I describe before (two single sells of 7, but it's impossible to get an invoice of 14; or any combination of numbers which sum is not possible to divide by 1.22)
But this issue is only for a single cent for invoice, and only if you have unlucky numbers. 

(only possible fix to this last issue: insert another row in the invoice, as "rounding", of +0.01 or -0.01, tax exempt)

BTW: being a rounding issue, it's tax exempt (in our crazy country, they did not decided if it's "escluso art. 15" or "fuori campo IVA", but both fit) 

 

[Kian]

@WHMCS John I'm quoting part of your message from CORE-11836 - Problem VAT calculation on whmcs 7.4 thread that is now closed.

Quote

However we feel the scenario of 100 line items of 0.01 each in reality is unlikely. Percentages of small numbers are always going to result in very small numbers. In such a scenario, what we would expect to see is a quantity configurable option used at the product level which would result in a single line item, with quantity 100, and value of $1.00, and the tax would then be calculated appropriately.

This is not true. There are tens of different ways you can use to reproduce the issue. Let me quote myself:

25 minutes ago, Kian said:

It can happen in tens of other ways:

• Specific tax rate
• Specific tax rate 2
• Specific combination of tax rate & invoice amount
• Specific invoice amount
• Specific overpayments
• Specific credit usage
• Specific credit usage & overpayments
• Specific credit usage & tax rate
• Specific credit usage & invoice amount
• Specific credit usage & tax rate & invoice amount
• Specific coupon codes
• Specific coupon codes & tax rate
• Specific coupon codes & tax rate 2 

I can go on forever.

This is mathematical problem that can occur in various ways most of which are random and unpredictable. It could be caused by the use of credit, coupon codes, specific prices and tax rates, overpayments, late fees, redemption fees, promotions, special prices, addons, configurable options, bundles, domain addons and most important with a mix of everything I just mentioned.

[yggdrasil]

If you are calculating 2.5256 you will get a different result than just 2.xx because it would be rounded to 2.53 with just two decimals. At 5 you round directly to the next number...You can't have 2.52256 Euros so its 2.53.

You can replicate this in many softwares that make the same mistake. I even had one financial institution that one a year was off by one cent. If you are using Euros or USD you should only do 2 decimals, not more. If I learned one thing is not to use WHMCS for accounting, even after discussing this with CPA, some stuff is weird with WHMCS. The way it does credits, refunds and currencies is completely incorrect. Once you do proper double accounting on accrual or cash basis mode you can spot all the issues and your accounting software does the proper tax numbers correctly.

I think the bug you hit is that WHMCS is not rounding them correctly in some fields so you are off by a few cents. This is incredible simple to fix if you had access to the code. All you need to do is reduce the decimals. 0.00 should be done in all code calculations (for Euros), I bet they are doing 0.000 in the tax part while 0.00 for the rest and so its not rounding correctly on the final amount.

Edited August 9, 2018 by yggdrasil

[Kian]

16 minutes ago, Remitur said:

Just an idea:

• leave WHMCS create the invoice, with wrong tax
• then, through an hook, before sending it to the user:
  • get the data of the invoice from tblinvoices
  • check if subtotal, tax, taxrate and total are right
  • if not right: correct them and update using mysql

Doing so, just a single issue may still exist: the one I describe before (two single sells of 7, but it's impossible to get an invoice of 14; or any combination of numbers which sum is not possible to divide by 1.22)
But this issue is only for a single cent for invoice, and only if you have unlucky numbers. 

(only possible fix to this last issue: insert another row in the invoice, as "rounding", of +0.01 or -0.01, tax exempt)

BTW: being a rounding issue, it's tax exempt (in our crazy country, they did not decided if it's "escluso art. 15" or "fuori campo IVA", but both fit) 

 

You can't fix it one time. You have to fix it everytime a transaction, credit, coupon code is applied/removed, an item or a note is added, an administrator clicks Save Changes, on invoice creation (via cron and manually) and so on. That's why in this precise moment I need to run 40 queries in 3 or 4 action hooks to get the job done. It works but it makes no sense. I'm not even able to add comments to my own code since I'm lost every 10 lines.

It's easy to fix in the core but it's a nightmare from hooks/APIs.

Edited August 9, 2018 by Kian

[Remitur]

14 minutes ago, Kian said:

I'm quoting part of your message from CORE-11836 - Problem VAT calculation on whmcs 7.4 thread that is now closed.

The thread is closed because this issue has been fixed in 7.5

(see "Tax calculation method" in https://docs.whmcs.com/Tax/VAT )