Jump to content
WHMCS John

Tax Configuration - Share Your Experience

Recommended Posts

Hi testers!

One of the key new features in WHMCS 7.7 is Simplified Tax Setup and Configuration + Additional Tax Features. During the pre-release testing we want to hear about your experiences with this feature.

Some potential starting points for discussion are:

  • Did you find any of the labelling or UI on the Setup > Payments > Tax Configuration unclear or confusing?
  • Did the Tax and VAT options enable successfully
  • Were you able to place an order with the VAT Number validation and tax exempt options enabled, and was the tax handled as expected?
  • If previously using the EU VAT Addon, did all the settings migrate across from the addon to the native settings correctly?
  • If previously using the EU VAT Addon, did the Migrate Custom Field tool copy across VAT Numbers from the custom field to the native field correctly?

In addition to resolving any errors which might occur, understanding any pain points is of particular interest to us. Your input will help us tweak messaging in the product or documentation and publish support articles.

Thanks for your help in the pre-release testing!

Share this post


Link to post
Share on other sites

 Is the Tax ID/VAT Number field optional? We already have our own implementation and would like to maintain it untouched at this moment. Maybe using the migration tool after some time as we need to be sure it works correctly with our implementation.

Are you validating the Tax ID/VAT Number in any way for singular person or just for EU Companies?

You're also implementing this field for contacts. Please make sure we can activate/deactivate this behavior. At this moment we require each customer account = one fiscal entity and would like to deactivate that option for contacts.

From what I understand, customers could request that different services on the same customer account be billed to different tax entities using the sub-contacts.

Share this post


Link to post
Share on other sites

Hi @cenourinha,

The new native tax fields will appear on client and contact records when the 7.7 update is applied.

A migration tool is provided to copy VAT numbers from the custom field to the native field. This is triggered manually in the new Tax Configuration page. It does not happen automatically upon updating, so can be performed at your convenience.

When VAT Validation is enabled, the values entered will continue to be validated against http://ec.europa.eu/taxation_customs/vies/ as usual.

The fields are currently always on, but we'd be interested to understand more about your use-case for not using them.

Share this post


Link to post
Share on other sites

By activating this fields by default and not have an option to disable then on clients and/or contacts, you will be overriding previous implementations. At this moment we require a separate customer account if the customer wants to be billed with different details.

If i understand correctly, with VAT/Fiscal Number for Contacts, you will enable customers to have multiple billing entities within the same Client Account. While this may be good for some companies, we would like to stay with the actual system and disable that field for contacts (at least for the moment) as we have integration with external billing software that needs to be rewritten if this is the path we choose to go. So we request you to make those fields optional (Enable/Disabled for Customers/Contacts by Admin).

Also, at this moment our VAT/Fiscal Number field is being filled with the country-code followed by the number (Example: GB927774676), will you implementation work the same way? You will use VIES (http://ec.europa.eu/taxation_customs/vies/) to validate VAT IDs and thats great for companies, but the Fiscal Number of Individuals doesn't validate with VIES, will you be validating them using another method or no validation at all?

What about the edition of the fields, will customers be able to edit them after the initial registration? At this moment we block the edition of those fields and require customers to signup a new account if they want to use a different VAT-ID/Fiscal Number.

Share this post


Link to post
Share on other sites

Hi @cenourinha,

VIES is used to validate VAT numbers exclusively. Is there a similar inter-EU system for individuals?

In what way would clients being able to edit the VAT ID field be a disadvantage? I'd like to understand why changing the tax ID requires a new client account in your workflow?

For example; if the name were to be changed on the client account to a new owner, surely they might also need to change the VAT number to that of the new owner?

Share this post


Link to post
Share on other sites

We are outside the EU and have no need/desire to collect any tax IDs from our customers. We wouldn't want our customers thinking that we are requesting their tax ID - tax ID numbers are considered sensitive here, and we have no reason to collect them.

  • Like 1

Share this post


Link to post
Share on other sites

I think we are using our own validation class that is based on this JS to validate fiscal numbers: https://formvalidation.io/guide/validators/vat/ i also i'm able to validate my fiscal number with this tool: https://ec.europa.eu/taxation_customs/tin/tinRequest.html

We don't allow First Name, Last Name, Company Name or VAT-ID/Fiscal Number change unless it is justified:

  • People or companies do not change their name every day;
  • We use VAT-ID/Fiscal number as a required field as we also use it as a unique ID;
  • We don't allow the same VAT-ID/Fiscal Number to be used twice.
  • If you (customer) signup a contract with a company (us), you can't simply change your contract details at the middle of the game, at least in our country. (For example, if i get Internet service from a ISP, normally with a contract (12-24 months), i can't just log-in into my ISPs client area and change the name and VAT-ID/Fiscal Number in the contract.)

When customers pay an WHMCS Invoice, we need then to process the final legal invoice with a certified software (At least in some European Countries). If we allow customers to change those details, we are allowing them to pay the invoice with XXX details, changing those details to YYY and then get a legal invoice with different data from the whmcs invoice.

Please, if you do a change like this, make sure you're doing it correctly or at least don't make it mandatory. Have the options in place so this can be flexible and work correctly for most of the cases.

Share this post


Link to post
Share on other sites
On 25/12/2018 at 10:34, WH user said:

We are outside the EU and have no need/desire to collect any tax IDs from our customers. We wouldn't want our customers thinking that we are requesting their tax ID - tax ID numbers are considered sensitive here, and we have no reason to collect them.

Do you sell to EU business clients? If so, you're required by EU law to put the business's VAT/TAX ID on the invoice.

Share this post


Link to post
Share on other sites

Hi @WH user,

Thanks for your feedback and taking part in the pre-release testing.

On 12/25/2018 at 9:34 AM, WH user said:

We are outside the EU and have no need/desire to collect any tax IDs from our customers. We wouldn't want our customers thinking that we are requesting their tax ID - tax ID numbers are considered sensitive here, and we have no reason to collect them.

To help me understand your use-case can I just clarify; you wish to charge Sales Tax to customers, but do not need to collect a Tax ID from them.

Is that correct?

Should the field be hidden everywhere (shopping cart, registration page, client area details page and admin area)?

Would it work for you if the field was hidden in the public and client-facing pages, but still present in the admin area?

 

If one does not need to collect sales tax, then disabling the tax system will also disable the Tax ID field.

 

 

@cenourinha,

Thanks for that link.

On 12/25/2018 at 12:16 PM, cenourinha said:

I think we are using our own validation class that is based on this JS to validate fiscal numbers: https://formvalidation.io/guide/validators/vat/ i also i'm able to validate my fiscal number with this tool: https://ec.europa.eu/taxation_customs/tin/tinRequest.html

We weren't looking to add TIN validation as part of this work because it's not something we've seen requested to date . I'd be interested to consider this as a new request so that we can understand the reasons for using this service and gauge whether other users would find it beneficial; it seems quite limited as it doesn't check whether the IDs have actually been issued.

It'd also be useful to hear your thoughts in the new request on how the TIN field might be labelled to clients/staff and how WHMCS would determine whether to use VIES or TIN.

Share this post


Link to post
Share on other sites

There's no point in using the WebService for TIN validation. It provides just a formal validation that can be included and implemented locally. In fact such WebServices are not linked to any Tax Register. You just need to understand the formula to calculate and check TIN for every EU country. Personally I spent days to validate TIN for italian customers but it's doable.

3 hours ago, WHMCS John said:

It'd also be useful to hear your thoughts in the new request on how the TIN field might be labelled to clients/staff and how WHMCS would determine whether to use VIES or TIN.

Intra-EU customers with VAT Number provided should be checked against VIES but it's more complicated. If you really want to comply to EU regulations, you can't simply implement checks against VIES or TIN. It would make no sense. First you should focus on things like legal status (sole proprietorship, corporation, organization, public administration, individual), the concept of intra/extra EU and own country, split payment and tens of other new trendy stuff like the damned 🤬 electronic invoicing. There's a lot of work involved and every year there's something that changes. The funny thing is that every single accountant has his own interpretations of the law... 😑

Share this post


Link to post
Share on other sites

It doesn't need to validate via webservice, but is essential to validate the format. This seem to work correctly: https://formvalidation.io/guide/validators/vat/

This validation will prevent someone to fill the field with invalid/false information that will then not be valide for usage in a external certified billing software.

Regarding the field label, it would depend on the language. In Portugal its called NIF (Número de Identificação Fiscal / Fiscal Identification Number) for individuals or NIPC (Número de Identificação de Pessoa Colectiva / Collective Person Identification Number) for companies, but NIF works great for both.

In our implementation we call it "NIF" in Portuguese and "VAT-ID/Fiscal Number" for other languages.

Edited by cenourinha

Share this post


Link to post
Share on other sites
On 12/27/2018 at 9:08 AM, WHMCS John said:

To help me understand your use-case can I just clarify; you wish to charge Sales Tax to customers, but do not need to collect a Tax ID from them.

Is that correct?

Should the field be hidden everywhere (shopping cart, registration page, client area details page and admin area)?

Would it work for you if the field was hidden in the public and client-facing pages, but still present in the admin area?

We are required to charge sales tax, but we do not request a tax ID. This is common throughout both the US & Canada. The field needs to be hidden in any client facing page, but it would be fine to still have it be present in the admin area.

The only circumstance here where we would ask for a tax ID would be if someone had a special tax exemption. But that would be a different type of tax ID than what tax ID would mean to most people. It's a very rare situation - it's never something we've done so far.

I suspect this is out of scope for your current project, but it would also be helpful in the future if we could mark level 1 vs level 2 tax for specific products. We have to charge both level 1 & level 2 taxes on what we are currently selling, but there are other things we'd like to sell for which we would need to charge only level 1 tax.

Share this post


Link to post
Share on other sites

Hi @WH user,

In 7.7 RC-1 we've added an extra option on the Tax Configuration page called "Customer Tax IDs/VAT Numbers".

Set this to the Off position and you can charge sales tax without displaying the Tax ID field to clients.

 

Please give the Release Candidate a try, and let us know if that meets your requirements.

Share this post


Link to post
Share on other sites

The problems i see with your implementation:

  • It doesn't validate the Fiscal Number (Customer will be able to put fake information there)
  • The field is optional (You should have an option for those who require it to be mandatory)
  • It allows customer to freely edit the field wherever he wants (Allowing multiple fake VAT-IDs/Fiscal Numbers)  Fixed: dpijZjJ.png
  • The field isn't filled with the country-code as suffix (Example: PT123456789)

Video: https://streamable.com/haqh5

Share this post


Link to post
Share on other sites

I forgot to mention that should be possible to enable/disable the Tax-ID/VAT-ID field for Contacts.

Share this post


Link to post
Share on other sites

Agreed with what @cenourinha said. Portuguese system and, actually EU fiscal system isn't easy, we need to make sure it actually works how it's supposed to be, or else we'll run into troubles really fast.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

By using this site, you agree to our Terms of Use & Guidelines