Table of Contents

Taxes Setup

Mitchell Paul-Soumis Updated by Mitchell Paul-Soumis

Read Time: 6 mins

Tax Creation in Sonar

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

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:

  1. State Tax
  2. County Tax
  3. 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.

On the customer's transactions:

Statement Example:

invoice_7.pdf

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 geo taxes, on the other hand, will always be based on the GPS coordinates of the serviceable address.

Putting it another way: 

  1. City tax is based on the "City" field of the address
  2. 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 in order to resolve the difference. The section below covers this process in detail.

Tax Overrides on an Account

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:

  1. From the Accounts window, click on any account name, then from the sidebar that appears click on "Manage"
  2. From the Account Management view, click on the Billing Tab, followed by the Taxes tab:
  3. From here, you can add a tax override by using the "Add Tax Override" button:

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:

  1. 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. such as 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.
  2. 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.

How did we do?

Billing Defaults

General Ledger Codes: Overview

Contact