How can we improve WHMCS?

It doesn't have to be complicated. Instead of trying to complicate this by using "rules" we just need to be able to setup our own tax table like ALL OTHER BILLING SYSTEM ALREADY DOES. Then via the clients profile we select that table item we created and your done, thats it. No complicated rules. Just select and go.

The tax rules already allow for Country > State, we just need Country > State > County. Just need another level. Some may need Country > State > County > City but for most I think the 3 levels would be fine. IT doesn't have to be complicated, we just need an additional level.

To ScottN's question - Such integration may or may not be possible, but it is a slightly different question regardless. That particular product is intended for those with crazy layers such that it is near impossible for any human to know what is actually accurate. I know across the border from us there is a city where they have different taxes depending on where you are within the city. Fortunately we don't do business there but a product like this would likely be the only solution short of mental therapy.

In our case, we know how much taxes we should charge in any given situation, but collecting that data for all of our customers on a continuous basis for proper submission to the taxing authority is very different from knowing how much customer X should be paying. If we only wanted to make sure that each customer paid their fair share we could just adjust their monthly rate, but that is not what this is about. It matters very little how much customers actually pay. It matters a lot how much we submit and being able to back up that number in case of an audit. Technically none of us has to collect any sales tax as a line item. It could be added into the cost of the product and people just pay your set price. The thing is the taxes would have to come out of that amount exactly as if you collected it as a separate line item or not. The reason for that point is to illustrate that it is the reports and management of these numbers that matters more than the actual charges.

This relates to comments such as those from ThomasB above. Submitting too much taxes is never going to be questioned as he stated, but what we can never do is charge a customer more tax than we actually pay in. It would be far safer to just raise the price of your product than to risk that kind of an audit. All that would take is one customer questioning their local government why you are charging more taxes than are due to get someone's attention. At least if your answer was that you just overpay, they might stop looking there.

It is my guess that the reason they have not done anything about this is largely because everyone's "simple solution" is slightly different from everyone else's. For example, the zip code solution would not work for us. It would certainly allow for getting closer than the existing options, but it wouldn't be right because we have to pay differently based on county lines and potentially someday even city borders which not only cross zip code boundaries but zip code boundaries cross in the other direction as well.

The only way a proper solution can be implemented is that the end results allows and open ended selection where you assign certain fields to be the tracking source. In our custom code, we asked that it be made to link to a single custom field which we use to keep track of the county since that is what we needed to reference. ,The admin interface would need to be able to allow you to select the desired (not hard coded) tracking field so that if zip codes worked for you, just select that....if we need county and it is not normally stored, we would assign a custom field. Others might want to select the city name.

Using that logic, a worst case scenario is that some users might use a custom field named ".5% tax" and another named "1% tax" (obviously named appropriately by the admin so that it makes sense to their use case). The problem is that there are so many variants of what people want, it is impossible to make everyone happy by "just doing it this way". It needs to be a solution much like what already exists except extended further to allow any field to be the reference source....not just the State.

I don't say all of that trying to imply it would be easy to implement. Sadly I think that most of the people this issue affects have just found some sort of compromise such as those mentioned above. The WHMCS staff doesn't hear all of the pain they have inflicted and so they assume that the number of customers this affects is really small. I don't know how many many it affects, I just know that I am one of them and that there are certainly others.

Oh, that was a good point about the name being likely misspelled though. We deal with that directly by making it a drop down selection. For obvious reasons that could potentially get ugly if the list is too long, but we are used to seeing lists of 50 states to select from and so it works pretty well at the scales we need. Again, other people might have different opinions on that matter which is why the software itself needs to just let us select whatever reference field we need.

I wonder if some type of 3rd party integration would be possible, such as this product:

https://www.serviceobjects.com/products/ecommerce/fasttax

Our options right now are move systems or continue charging WV residents an additional 1% for the municipal tax that they may or may not actually need to pay. Our city tax dept said it would be similar to someone coming from another county and purchasing an item from a brick and mortar store the way we are having to do it now so it isn't too bad (its more money for them so of course it isn't "too bad"). I would love to see a solution to this but luckily a majority of our in state customers are tax exempt, I just feel bad for the remaining ones that are not. I hope this feature comes up for reevaluation soon.

The way I imagine it is tax based on a zip code, this would allow us to set up taxes for cities. Just allow us to enter all the zip codes are for that city under the tax rule and WHMCS could do a simple comparison based on the customers entered zip to apply the tax. It would rule out issues that could arise with customer input from a string for city which is a lot more likely to be misspelled as compared to a 5 digit zip code.

Oh, my... That is frightening. That sort of solution would cost us untold thousands. Hopefully you can recover some of that in tax prep. The problem is that a "solution" like that is a deal breaker - plain and simple. Sadly, our solution will run out of its useful life at some point and if nothing has been done to fix this we will be forced to migrate elsewhere. At the moment we are holding out against all hope that they will come through before then, but it is looking more and more like WHMCS is just not interested in the USA market. We have been using the software for so long, it will certainly be difficult to leave it behind but we aren't willing to give tens of thousands of dollars to the local government just because our software doesn't know what else to do. I just don't even know what to say....this whole situation is just sad.

Mtindor hit it on the head, we charge all WV residents an additional 1% regardless of city.

I wish I had a great solution to report. In fact I don't even have a workaround. What we ended up doing is to charge WV customers 6% and then remit 7% to the state of WV. Essentially we are paying the state of WV more than they deserve. I'd argue that they don't deserve a dime. I'd argue that it's the "other" state's job to collect taxes from its residents. But we have neither the staff or money to fight that one. Thanks WHMCS for costing us time and money.

So, Mike and Thomas, your situation is exactly what we have here as well. Out of curiosity how are you guys handling it without the functionality existing in WHMCS?

I imagine it won't do any good, but I certainly want this topic to stay alive. I was hoping that "Denied" meant that they are working on a better variant than this asked for. That is a reach, granted, but it makes me feel better than assuming they have abandoned us. If everyone leaves a comment here will they notice?

I see this feature request has been "Denied". I'm not sure if that means it'll never be considered again. But, since I can comment, I will comment that WHMCS really does need to provide this functionality. Although most web hosting companies within the US likely do not currently collect sales tax for states outside of those where they are physically doing business [eg: have established nexus], individual states are becoming more and more insistent that companies out of state charge sales tax to that state's customers and then remit said sales tax to that state. If you were to scour through all that you can find online regarding this, you will see that some states specifically exempt web hosting companies while others make exceptions if nexus hasn't been established. But there are other states that do require this. And many web hosting companies have neither the money, time or staff to devote to handling a tax audit if some other state insists that the webhosting company should be collecting taxes. This is only going to get worse as time goes on, as states are obviously unable to adequately collect sales tax directly from their residents and are using all methods available to force out-of-state companies to take on the burden of doing that.

I respectfully request that WHMCS reconsider and start to actively think about this can be implemented within WHMCS.

To give you just one example, in West Virginia the current sales tax is 6%, with perhaps less than two dozen counties / municipalities adding an additional 0.5% to 1.0% sales tax on top of that. So if West Virginia deems that an Ohio company has established nexus with West Virginia, then West Virginia now wants the Ohio company to charge the sales tax rate of the county/municipality that the West Virginia customer lives in. There is no way to currently do this in WHMCS, but this needs to be implemented. It's not as simple as setting up a Tax Rule for all of West Virginia, because although West Virginia has a sales tax of 6%, various municipalities have a tax rate of 6.5-7.0% that must be charged to customers living in those municipalities.

Mike

We have a similar problem in Canada and a feature request with some uptake at https://requests.whmcs.com/topic/specify-second-level-tax-on-specific-products-pst-is-not-charged-on-every-product-in-bc ... but it has been a long time and no interest in fixing the issue as it seems.

I have been able to set up a variant of OpenCart and WooCommerce to work with our taxes out of the box. I think either solution could be working as a tax replacement for WHMCS.
Once implemented it is easy to move all the existing data with no issues in the upgrade process. A new default tax would be created that copies the old system and then we could make changes and additions as we need.

In a backwards sort of way, I have a partial answer to your question, Cole. Back in 2008 when we started using WHMCS (and Sponsored Development was still a thing) we had the WHMCS team code a solution for us. The solution we went with was to assign a custom field which was then used by the tax "engine" to calculate an additional level of tax. In our case, we needed the County tax, but it could be named anything you might want. This field references a simple lookup that assigns the correct tax and auto calculates based on the county selection just as the state level tax already works. We just have to maintain a list of counties that we do business in.

The thing is, this is not as simple as making a field to link to a tax calculation. It is also necessary to create a new report which breaks out the collected taxes to be reported correctly and also to modify the invoice to display the new data to the customer. Of note though, is that much of this has already been done for our solution. It would need to be cleaned up for general use so that it wasn't hard coded to a specific custom field and that would require a new admin control to interface with that. Then our custom report would need to be reworked to be generic and for most people it would probably be necessary to update the invoice unless it was decided that everyone should do that themselves.

All of that adds up to significant development just to achieve a single new tax layer. I don't believe it is proper for the WHMCS team to write it that way. They should go a bit further and add in as many tax layers as the user wishes. That final request is where the hesitation seems to come in for the WHMCS team because it is one thing to jerry-rig in a single tax layer to fit our needs and it is a very different thing to make it so open ended that it will handle every imaginable possibility. I know for certain that whatever they come up with will leave people asking for strange use cases, but they should be able to get it pretty close!

If anyone is about to ask if they can borrow/rent/buy our custom code, here is where the problem lies. The changes that were necessary to make this work are in the core itself. It is not possible to update beyond very minor incremental updates without breaking our modifications. You can't just transfer the modified files most of the time as that breaks the core. For a long time we paid to have our custom work updated as new versions came out, but since Sponsored Development became a thing of the past this is no longer something they are willing to do. This leaves us hanging on to old versions and even security updates have to be tested carefully. Once you hit one that breaks things, it is all stop. For this reason we would be very pleased if our modifications were used as the basis for a new, fully functional system. If the WHMCS team could look at what they created for us and either use it as a starting point or maybe just inspiration, that might be a thing. Our solution has worked perfectly for a very long time so hopefully it can provide some sort of value here. That would be a win-win for everyone.

I think that a "configurable options" style tax system would be amazing. Use a similar build to be able to build different tax groups -- for example, a "state" group that we could populate, a "city", a "county" group, that we could populate ourselves, or do by zip code, or by region, however we choose. Then we could add product-specific tax-types, e.g. voice taxes, perhaps different rates for different services by locale etc (stacking).

Then, per-product, be able to select from the configurable-tax-options drop downs to choose which taxes apply to this product.

This may regionalize product offerings, which could be hard for nationwide domestic folks, but seriously, those companies are already in tax hell - and if they're not, they should be. Setting up a system for rules to match an order against possible tax group matches shouldn't be too bad. Lots of mapping, but hey, this is the US tax pain.

Being able to create our own, very custom taxes is critical to us, and very, very painful. I'm sure /everyone/ using WHMCS for products other than just straight webhosting feels the same pain, or is aware of it and ignoring it because it is very difficult right now.