CORE-11836 Problem VAT calculation on whmcs 7.4

[brian!]

let's take @Remitur's idea about nails at 0.01 each...

On 07/02/2018 at 12:59 AM, Remitur said:

assume I'm selling nails, and the price is 0,01 each plus VAT (20%)

So, if I'm going to sell 100 nails to a customer:

• according to tax office, final price is 0,01 x 100 + VAT = 1,20
  (of these, 20 cents are taxes)
   
• according to you, final price is (0,01 + VAT) x 100 = 1,00
  (with zero taxes)
  Very happy the customer, very unhappy the tax office...

in the cart, it correctly shows the price including VAT...

yet when the invoice is generated, the VAT is 0.00... i've tested this on two v7.4.2 dev installations - one of mine and the Softaculous WHMCS Demo - both give the same error.

this is a 3-month old bug... I dread to think how many users are blissfully unaware of this occurring.... we can debate all day what features WHMCS should or should not have, but I would have thought the ability to calculate tax correctly and consistently isn't up for discussion.

[WHMCS John]

Hi all,

We appreciate that the change in the way the calculations are performed has caused some concern. Our team is reviewing the comments here regularly and will be continuing to evaluate the impacts of this change and any further changes that may be possible to ensure the accuracy and consistency of calculations.

The decision to change to calculating taxes per line item was made for a number of both technical and business reasons, as well as to bring parity to the way we calculate taxes and the way it is done by a number of leading accounting packages.  In addition this brings a level of consistency accross the various different areas of the product and gives us the foundation for more invoicing features and functionality we expect to introduce in the future for which this level of granularity will be important.

To address some of the points raised here directly:

@Esi and @brian!
When making this change, we evaluated the behaviour of a number of leading accounting packages. Having just re-created this scenario in two of those, I found it produced the same tax computation as you see in WHMCS. The taxes are calculated per line item, rounded on each item and then summed. This is what appears to be the established industry convention.

@J-B
We have been able to reproduce this rounding down issue when negative line items are manually added to an invoice. This has been assigned case CORE-11960 to ensure that it is rounded up when appropriate.
A hotfix has been produced and is available at: https://whmcs.community/topic/283901-core-11960-ensure-tax-is-rounded-up-for-negative-amount-line-items-when-applicable/
 
@Remitur and @brian!
I appreciate the point you are raising. 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.

Please keep the feedback coming.
 

[brian!]

39 minutes ago, WHMCS John said:

In addition this brings a level of consistency across the various different areas of the product and gives us the foundation for more invoicing features and functionality we expect to introduce in the future for which this level of granularity will be important.

oh Lord... foundations built on quicksand never lead to solid buildings!

please get this stuff right now before you go any further with it.

40 minutes ago, WHMCS John said:

I appreciate the point you are raising. 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.

I was doing that to save time and prove a point... i'm not going to sit here and test 101 permutations of line items to see if they all work correctly (especially when I can't see the code used) - I had assumed there were staff employed internally to do that sort of thing.

I would have thought testing with unlikely events is perfectly legitimate and to be encouraged... you're not to know how others are using their WHMCS installs - they may be selling physical products and using quantities might seem a logical/simple solution... they're not necessarily going to know or want to use config options... least of all because they may naively assume that a billing solution could calculate VAT correctly under all circumstances - not just the "likely" ones.

let me repeat the example I gave you yesterday when I changed the product price to 1.01

let's ignore for now that I think the VAT value shown in the cart is correct, why isn't the same VAT value used in the invoice?? all throughout this thread, you've been using the word CONSISTENCY, yet in an extreme case (apparently!), WHMCS is behaving in an inconsistent way.

if this glorious revolution of calculating the VAT is working correctly, shouldn't both values be the same ? you can argue they should be x or y - but they definitely shouldn't be both x AND y.

surely the only way they can be different is if they're being calculated using different methods... that's not consistency.... there shouldn't really be any scenarios where the price shown @ checkout is different from the invoice delivered just seconds later.

1 hour ago, WHMCS John said:

When making this change, we evaluated the behaviour of a number of leading accounting packages. Having just re-created this scenario in two of those, I found it produced the same tax computation as you see in WHMCS. The taxes are calculated per line item, rounded on each item and then summed. This is what appears to be the established industry convention.

out of curiosity, I quickly tried this on a leading online invoicing solution (which I can name if you want me to), and it calculates the VAT as it does in the WHMCS cart (correctly in my opinion), not the WHMCS invoice...

now it's probably pointless getting into a debate about which is the "correct" method (as I don't think we'll agree) - but surely whatever the circumstances, the values needs to be the same in both cart and invoice.

[WHMCS John]

Hi @brian!,

Thanks for your response. I've opened case #CORE-12008 to investigate the discrepancy between the order summary and invoices in this particular case.

[ju5t]

I was pointed at this post by WHMCS as we are having exactly the same problems as others have expressed already. I don't think there is much I can bring to the table apart from to further stress how ridiculous this change has been and how many problems it has been causing us.

One thing I did find is that in our attempts to work around the issue by illegally changing the VAT-amount is that WHMCS puts it back when customers pay their bills. Yes. WHMCS forces this change throughout the application even at points where it should't. This leaves corrected invoices marked as unpaid with 1 to 20 cents or more depending on the number of lines on the invoice. Both changes were illegal and punishable by law, but hey, so far WHMCS doesn't seem to care much.

You have taken two (for us) foreign accounting companies and based your decision on them to pick a standard. What kind of research is that?

We were told to switch accounting software as a solution. After 8 years this is the only suggestion you get. This is absolutely shocking.

As I've also pointed out in the ticket I raised with WHMCS we understand that calculating tax per invoice line is the way forward. There's nothing wrong with that. Though you should have made rounding tax at the invoice line level optional or something that can be adjusted through a hook or other means. You're leaving your customers to dry and that's something I don't appreciate after working with WHMCS for so long now. I'm really disappointed in how this case is being handled and the lack of priority it seemingly gets.

[Remitur]

6 hours ago, WHMCS John said:

The decision to change to calculating taxes per line item was made for a number of both technical and business reasons, as well as to bring parity to the way we calculate taxes and the way it is done by a number of leading accounting packages.

Can you please specify what would be these "leading accounting packages"?
I've worked with a number of different accounting software, but never met anyone doing so...

About official rules on VAT calculation and rounding: each country has its own rules, but they're roughly consistent.

A brief reference:  http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A62007CJ0302

report that:

Quote

You may round down the total VAT payable on all goods and services shown on a VAT invoice to a whole penny. You can ignore any fraction of a penny.

That's to say: rounding has to be done only at invoice-evel, not to row-level.

But, if you want an (very unusual) rounding at row level. the same document specify that it's possible: but each row's VAT has to be rounded to 1/10 of penny. and the total amount in invoice may be later rounded to the nearest whole penny.

So, if you want keep WHMCS calculating VAT at row level, it can be done... but you need to modify the process in order to calculate one more decimal position for every single VAT amount: that's to say, not penny, but tenth of a penny; not cents, but tenth of a cent. 

Is it worthwhile?

I, as WHMCS user, never felt such a need...

[ju5t]

4 hours ago, Remitur said:

But, if you want an (very unusual) rounding at row level. the same document specify that it's possible: but each row's VAT has to be rounded to 1/10 of penny. and the total amount in invoice may be later rounded to the nearest whole penny.

They are giving you two options.

• down to the nearest 0.1 p – for example, 86.76 p would be rounded down to 86.7 p; or
• to the nearest 1 p or 0.5 p – for example, 86.76 p would be rounded up to 87 p.

WHMCS has chosen to round to the nearest penny. This is not necessarily incorrect but it should be an optional setting so you can choose where rounding should take place. Our accounting software for one can't deal with this change and I have asked them to provide us with a similar option, but to be fair, they haven't changed their VAT calculation in the middle of the game.

@WHMCS John this is something WHMCS needs to address. I have also mentioned this in the conversation we had via email. Instead of proactively helping us to find a solution for this, for which I even offered to pay, we were told to get different accounting software. I don't feel like WHMCS is taking its customers very serious on this matter. Why is that?

[WHMCS John]

Hi all,

Thanks for your continued feedback and discussion on this matter.

We understand this is an important issue for some users, and as such I'm pleased to advise that in version 7.5 RC1, a new option has been added to the Tax Rules page which will allow you to choose how tax is calculated by WHMCS throughout:

• Calculate individually per line item (Default)
• Calculate based on collective sum of the taxable line items

The documentation for this is located at: https://docs.whmcs.com/Tax/VAT#Tax_Calculation_Method

 

This is a non-trivial change, so whilst 7.5 is in the pre-release testing phase we are keen to get as many people as possible to test out both modes, and ensure everything is working as you expect.

Therefore I invite all participants in this thread to install WHMCS 7.5 RC1 in a test environment and give it a thorough testing before stable release:

• https://blog.whmcs.com/133429/whmcs-75-reaches-release-candidate-status
• https://preview.whmcs.com/
• https://whmcs.community/forum/413-v75-beta-discussion/

The pre-release testing phase is always your best opportunity to provide feedback for quick iteration before everything is locked in for the stable release, so please let us know!

 

[ju5t]

I ran a few tests on our test environment. Looks good. I didn't find any issues so far. I appreciate the quick resolution @WHMCS John!

[wellend]

Dear WHMCS

Can you tell us when this fix will go live please?

A client just advised us that their invoice had calculated differently to usual by several pence.  When I checked I found that a number of our invoices this month are incorrect - whereas they've always calculated just fine.  There is now a discrepancy between what WHMCS calculates and what our accounting package calculates (FreeAgent - fairly mainstream!). 

It was very wrong of you to mess with the calculation unexpectedly on what is our live client-facing system.  It's also wrong to say that the change corrects things for us in the EU.  It's wrong for us too.  Who calculates the tax on a line by line basis?

Thought I was going mad until I discovered this thread.

Arrrgh!

[WHMCS ChrisD]

@wellend the changes for Tax Calculation option are part of the changes introduced in WHMCS 7.5.0 which is currently in RC status I don't have an exact stable release date at this time however it shouldn't be too far away.

[ju5t]

This has a pretty big impact on us and the longer it takes for this release to be out the bigger of a problem it becomes.

Why is it taking so long? I would appreciate a bit more openness about releases from WHMCS so we know what we can tell our customers aside from 'sorry, our supplier made a mistake'. As that story gets old and we're getting the blame.

[WHMCS John]

Hi @ju5t,

New feature releases typically spend a month in pre-release testing. Our latest blog post mentions that 7.5 stable release will be made next week.

Please take part in the testing process and let us know your feedback: https://whmcs.community/forum/413-v75-beta-discussion/

[iserver]

In his line as always WHMCS. When an error is involved, since time immemorial, its developer and CEO currently, it seems that he does not care much.

A question that is not tribal, as it is that an accounting program, made in Europe, does not even comply with European regulations, but not only that, it does not even comply with the most basic rules of rounding, and that provokes not a little problems, it is a question, to move forward in future versions.

The problem is that above, prices rise as if it were a super-pro software, and does not measure up. The pity, is that many of us have been years and years, and to migrate is complicated, but sooner or later, many of us will migrate.

Hopefully they solve this, and many other flaws in their wonderful system de-normalized databases.

[wellend]

@iserver I agree in that this was a real problem for us too.  But v7.5 is out now and does resolve this issue.  Since we upgraded we can now set the option correctly.

So sometimes people do care and things do get resolved!  
:o)

I'd like WHMCS to think harder about implementing alterations to financial calculations in the future though.  This particular problem was very foreseeable by anyone with a bit of basic accounts knowledge.