This article is relevant if you are using NetSuite’s US Sales Tax engine and you need to accommodate special tax situations.
Background
Since its inception, NetSuite has supplied a US-based sales tax engine. Over the last couple of years, in support of NetSuite’s global ambitions, it has evolved to offer a more robust SuiteTax engine that allows for third parties to more seamlessly plug into the NetSuite transaction services. Thus NetSuite is taking seriously tax calculations as part of its fundamental architecture.
There is a good place for third-party tax engines as they offer additional services, such as agency reporting and tax filing. Third-party tax engines also keep up with some of the specific tax policies that are often applied to items such as food and clothing. NetSuite’s sales tax engine is basic simply providing tax agency reports and basic “on/off” switches if a product is taxable.
Nonetheless, the NetSuite US-based sales tax engine works well if you are shipping hard goods across the United States. With some straightforward configuration, you can define tax codes that are driven by postal zip codes to identify the state, county, and city tax requirements.
Yet, there may be times that a locality demands other tax requirements that the NetSuite sales tax engine may not meet. The question becomes, do you go to a third-party tax engine or do you produce refinement of the existing tax engine to solve the challenge?
Two clients encountered this situation. In one business, located in Chicago, they were imposed a “Cloud Services” tax. In another client, located in Tennessee, they were imposed a “Luxury Tax”. Instead of going to a new tax engine that produces switching and ongoing costs for a relatively simple problem, our client decided to work with our firm to specifically solve the challenge leveraging NetSuite’s platform customization capacities.
Enhancement Pattern to Solve NetSuite Additional Tax Requirements
As this is NetSuite’s core function, the assumption is that the zip code lookup pattern is sufficient to find the locality for which the tax applies. Thus, we want to trigger additional action by referencing a taxcode on a sales transaction.
By creating a custom table that holds the taxcode and a percentage rate, we add additional tax lines to the sales transaction and reference the product item in question. Naturally, if there are specific product attributes that trigger the applicability criteria, these too can be specified.
Working with one of our clients, Boban D., senior analyst, produced an implementation that is flexible so that orders can be acquired from any source, such as CSV or other integration, and trigger the enhanced tax treatment.
Upon save of the order, each line is reviewed for applicability. If an item qualifies, an additional line is added with an other-charge item type to calculate the additional tax value. An appropriate memo is added to the description to help the customer understand the nature of the charge. We route the GL accounting to the same liability account used in the standard tax configuration.
The algorithm is smart because it heals itself — meaning every time the sales transaction is saved, previous add-on tax entries are removed and added back so that any changes in applicable item quantity or price are accounted for.
Click on images to see the pattern.
Enhance NetSuite’s Built-in Sales Tax Engine
The example above is a good application of the core NetSuite platform. We worked with the client to listen to their requirements and adapt to their situation — saving them the trouble and expense of going with a third-party tax engine. Built-in sales tax reports were reviewed so that the tax line enhancement could be identified to facilitate the tax reporting obligation.
If you found this article relevant, feel free to sign up for notifications to new articles as I post them. If you are ready to tackle your NetSuite sales tax challenge, let’s have a conversation.