As taxes are created, they must be applied to services before they'll generate any charges. The charges they generate will automatically be added to the price of the service, and will be invoiced alongside it. Tax Exemptions, Geographical Tax Application, and Tax Overrides can all complicate the application of taxes with Sonar.
For a simpler, but just as effective alternative to the native Taxation engine in Sonar, consider deploying Avalara in your instance. Avalara bypasses individual tax creation, and automatically manages exemptions, geographical restrictions, and deployment.
Tax Creation in Sonar
Permissions for Tax Creation
To be permitted to manage and create new Taxes, the following permissions must be enabled for your user role:
How to
Creating a new Tax is done by going to Settings -> Billing -> Taxes, then clicking on "Create Tax"
Tax creation requires 4 fields to be filled out: Name, Application, Rate, and Type.
The name section is what appears on the invoice and the account
The application indicates whether it should be a flat rate or a percentage of the sum which is applied as taxes
The rate is the amount (so 5 would be either 5 dollars or 5 percent depending on the application selection)
The type picker allows you to set if it's global to every customer, or dependent on a certain geographical zone
Once created, a Global Tax is done here - it's applied to all customer accounts in your instance. Geographical taxes will require additional configuration.
Geographical Taxes Extra Configuration
When you create a Geographical Tax in Sonar, you then need to configure a Geo Tax Zone.
Configuring a Geo Tax Zone will only tax the residents of that zone, and configuring the actual zone itself is very flexible. The only mandatory fields are the Name and the Rate.
If you enter multiple distinct fields, the Tax will only apply to individuals which meet all criteria
Geo Tax Zones and Default Tax Rates
The first thing to know about Geographical Service Taxes is how they interact with configured Default Tax Rates. Geo Taxes are designed to be created and applied to individuals in a limited geography, Default Tax Rates allow you to assign a percentage tax to anyone who falls outside the configured Geo Tax Zones.
For example, If you plan to create a State Tax and you enter a percentage rate of "5%" during initial tax creation, this rate will apply to everyone outside whichever specific state you create:
For a more visual example, take a look at this completed State Tax build out:
In this example, the States of Michigan, Wisconsin, and North Dakota are receiving their correctly defined Geographical Taxes. Any subscribers from outside of those 3 states will have the 5% Default Tax Rate applied to them, regardless of their State's actual Tax Rate.
Default Tax Rates can be useful for approximating an overall tax rate in the event you allow subscriptions from outside your existing taxable service zone. This can provide your team with additional time to deploy accurate tax changes, if needed.
When configuring Geo Tax Zones in Sonar, it's common practice to set the default rate to 0% rather than try to approximate an average tax rate for customers outside your Geo Tax Zones. This simplifies total tax calculations at the end of the fiscal year.
Multiple Service Zone Configuration
While Sonar does support integration with Avalara for automated taxation, the software is designed to be robust enough to enable you to create multiple layers of taxation that appear on a line-by-line basis during transactions.
The Default Tax Rate (the RATE column) should be set to 0% when servicing multiple zones, as the rate set there will apply to serviced customers that fall outside the set zones.
When you provide service to customers in multiple cities, counties, or states, you will need to ensure you have all the layers built. Rate-building occurs on a size basis, starting from the broadest service area to the smallest. As you can see below, the taxes were built in the following order:
State Tax
County Tax
City Tax
If you have multiple state-level taxes (such as a technology tax), these secondary taxes should be entered in as a unique Geographical Tax. See SCIENTIFIC & CULTURAL FAC in the image above.
The way this system works together allows you to nest multiple Geo Tax Zones within one layer, such as in the case of distinct cities within Colorado:
By nesting these cities under a single Geographical Tax, you minimize not only the number of items, but the number of taxes applied to a service.
Finally, with the taxes configured in this nested manner, you and your customers will be able to see all taxes leveraged against the service as it's charged and invoiced. The description provides the Tax name and the Geo Tax Zone name for the customer's view.
On the customer's transactions:
Invoice Example:
Customers will be able to see all taxes leveraged against the service on page 2 of the invoice.
Considerations with Geographical Taxation
Taxation can be a confusing topic, so in this section of the article, a few complicated scenarios will be explored and explained.
Difference Between Serviceable Address vs. Geolocation
There may be situations when you have an account where the serviceable address is different from the geolocation. In this scenario, the geographical tax will be applied based on the serviceable address. This is because geography-based taxes check for a match in the serviceable address fields, regardless of the actual latitude and longitude for the geolocation.
For example, if you have an account where the serviceable address is input for Boulder, Colorado but the corresponding geolocation (lat/long coordinates) fall within another city (e.g., in Denver), a geo tax for Boulder, CO would still be applied for this address — not a tax for Denver, CO. County-based geotaxes, on the other hand, will always be based on the GPS coordinates of the serviceable address.
Putting it another way:
City tax is based on the "City" field of the address
County tax is based on the GPS coordinates specified
Taxation Between Parent & Child Accounts
If you've spent any amount of time using Parent and Child accounts in Sonar, you may be wondering how services will be billed when the child account is in a different geographical tax zone.
With Sonar, Geographical Taxes are always applied based on the location of the specific account's serviceable address, which means that while the Parent account will pay the generated invoices, the services on the Child account will always be taxed what's relevant to its geographic location.
Determining Taxation in Edge Cases
In some cases, you may have an account that falls geographically within a city, county, or zip that should be taxed at a different rate. In these cases, such as a serviceable address existing at the edge of a city that gets taxed differently, a tax override would need to be set on the account to resolve the difference. The section below covers this process in detail.
Applying Taxes
Permissions
Applying Taxes requires different permissions than tax creations. To manage the services and apply taxes, you'll need to ensure the following permissions are included on the role:
Services
Now that you've created the required geographical or global taxes that may apply to your customers, you need to determine how these charges will be applied. In Sonar, each tax is applied to a Service, and as these services are invoiced, the taxation value is calculated based on the parameters you set.
To add taxes to a service in your instance, follow the below steps:
Click on Settings → expand the Billing tab → click on Services
Adding a tax to a service can be done to a new service or to an existing service, and in each case, you'll need to locate the "Taxes" section in the modal, located in roughly the same place:
Clicking on the “+” symbol will present you with a scrollable list of all your taxes.
Each tax that should apply to this service will need to be selected as a new line by clicking "+" multiple times. Clicking on "-" will remove the added tax.
The most common error during the process of adding taxes to a service is not filling out the exemption amount. If the service is not exempt from any amount of taxes, ensure you enter "$0" as seen in the image.
Once the changes or new service is saved with the taxes added to it, they will be automatically calculated and applied during invoice generation.
Tax Overrides on an Account
Tax Overrides function differently compared to Tax Exemptions, which require Avalara. For more information, take a look at the Tax Exemptions - How To article.
Permissions
Configuring Tax Overrides on an account requires separate permissions from the other tools in the taxation suite:
Application
Whenever a tax is applied to an account, you also have the option to apply a tax override. A Tax Override in Sonar allows you to exclude a specific account from the taxes specified during the override's creation. You can add an override to any account by following the directions below:
From the Accounts window, click on an account name:
From the Account Management view, click on the Billing Tab, followed by the Taxes tab, then click on “Add Tax Override”:The modal that opens allows you to select which of your instance's taxes to override, and what the new rate should be:
You can select any tax on your instance to override, even if the customer is not currently being affected by that tax.
When to Use a Tax Override
Using a tax override is a way to manually adjust taxes for specific individuals. While there may be several general reasons you'll need to modify the tax rate, this section will highlight some examples that have necessitated such action by customers using Sonar in the past.
These are only general examples of how Tax Overrides could be used in place of a unique service or other workarounds. Specific handling of individual and organizational taxes should always be considered from your specific country, state/province, and county legislature and requirements.
Example 1: Tax Exemptions by Area or Individual
The scenario may arise where you have groups of people who are exempt from all or some applicable taxes, or who are living in an area where services provided are exempt from being taxed. For example, the GST (or HST in certain provinces) is a tax applied to nearly all goods and services within Canada. However, as outlined in Article 87 of the Indian Act, certain peoples in Canada can be exempt from the taxes charged on services performed on a reserve. In a situation like this, it would mean that any internet services supplied in those areas would therefore not be taxed. There are two ways to approach this scenario:
A unique service could be created that would not be taxed; this service would be used solely for those accounts receiving service in the specified location (e.g. on a reserve). Using this solution does introduce the risk of the service being erroneously applied to accounts that do not meet the criteria, but does allow you to quickly service numerous tax-exempt locations.
For each account within the tax-exempt geographical area, you would apply a tax override to the individual accounts belonging to those members of the community, for the given rate of the tax within the area of service. This option does require a small investment of time for each account, but it's easier to credit back taxes paid than account for unpaid taxes as in the first scenario.
While accounts themselves can be made tax-exempt, this function would prevent any taxes from being charged to the particular customer. For example, if you made an account tax-exempt it would not be charged for any taxes, even if taxes besides the GST/HST should still apply.
Example 2: City and Zip Tax Rate Discrepancies Due to Specific Location
In some cases, you may have two customers that, at least based on their civic address, belong to the same City and Zip Code. The reality may be much more complicated. We'll examine a scenario in which Alice and Bob need to be taxed at different rates despite their addresses being part of the same City and Zip Code.
Alice lives inside City C, in a downtown apartment. Bob lives on the outskirts of City C, enjoying the rural life. Both Alice and Bob are paying for the same service with your organization, and this service has the geographical state, county, and city taxes applied. Because the serviceable address belongs to the same City and Zip Code, Sonar's geographical taxation system has no way of knowing that due to Bob's rural location outside of City C he actually pays 0.5% less tax than Alice who lives downtown.
In order to resolve this discrepancy, and not overcharge Bob, a tax override should be placed on his account to reduce the rate of the taxation in order to accommodate Bob's specific location.
Example 3: VOIP Service Fees on an Otherwise Tax-Exempt Organization
Due to the nature of how Sonar handles taxation and fees, certain mandatory fees need to be added as a Global Tax. An example of such a fee is the E911 fee charged on VOIP services.
Because this fee needs to be applied universally across all accounts, it is typically added as a Flat Rate, Global Tax within Sonar. This means that Tax-Exempt Organizations, such as churches, receiving these VOIP services cannot be made directly tax-exempt within their account's billing parameters. Each tax applied to their account as a result of the services they subscribe to needs to be manually overridden in order to prevent taxes from being invoiced while still allowing mandatory service fees to be collected.
Updated
by Mitchell Paul-Soumis
The most common error during the process of adding taxes to a service is not filling out the exemption amount. If the service is not exempt from any amount of taxes, ensure you enter "$0" as seen in the image.
