Service Objects has been returning location-based tax rates in the DOTS FastTax API since 2001. Back then, we identified sales tax rates using only zip code. Since zip codes could cross multiple city and county borders, we were returning the rate most likely to be accurate based on preferred city and county. That evolved to returning multiple results based on a zip code, with each result containing a unique city, county and state. This was more accurate, but still involved a level of human intervention as multiple rates could be returned.
The service improved further as Service Objects developed its DOTS Address Validation services, which allowed us to get even more precise in determining the right area for the tax rates. Users could now submit a full address to the API and in most cases get a single accurate result, pinpointing the result to a location that had a clear tax rate.
However, if a given address was bad – or maybe even good but too messy to validate – it would not return a result and users would need to failover to the zip code level operations. Rural addresses which fall outside of city boundaries could wreak havoc if the proper location is not identified.
Last year, Service Objects introduced a new operation, GetBestMatch, to solve these challenges.
GetBestMatch in FastTax is designed to find the best rate possible and return a clean result. It uses the latest algorithms from Address Validation – US to clean and validate the toughest addresses and failing that, validates that the other data points are valid in order to return a zip level rate.
The service can also return an address level rate through the analysis of the nearby area, even if the address is bad. If an area can be proven to have a consistent rate for a zip, city or county and we know the address would be within one of those areas with 100% certainty, it can be deduced that since any address within that area has the same rate, the rate we return would be accurate at the address level. This extra analysis means that GetBestMatch can more precisely return accurate rates more often than its predecessor operations.
Additional returns offer more insight
To add even more accuracy to the service, GetBestMatch also does boundary analysis to ensure the most accurate location is used in the tax calculations. The main piece of information returned to users here is the “IsUnincorporated” note. IsUnincorporated helps users identify locations that might be considered part of the city but actually are not. This example shows what that might look like:
823 Holiday Dam Rd, Honea Path, SC, 29654
<Zip>29654-9430</Zip> <City>Honea Path</City> <County>Anderson</County> <StateName>South Carolina</StateName> <TaxRate>0.070</TaxRate> <StateRate>0.06</StateRate> <CityRate>0</CityRate> <CountyRate>0.010</CountyRate> <NotesDesc>IsUnincorporated</NotesDesc> <MatchLevel>Address</MatchLevel>
This is a partial return of the operation including the Note IsUnincorporated. This notifies the user that the CityRate, if it exists, should not be used in the final TaxRate. We have decided not to modify the original found result (TaxRate and CityRate) but return the IsUnincorporated result so that the user can handle it however they wish. In an upcoming release we will be adding a new return “UnincorporatedTaxRate” to simplify all of this.
The improved rates of return for address level checks also come with a few new challenges. Since we can return accurate rates even if the address is extremely messy, there might be times when we do not always have an accurate city or county to return. We know the rate is accurate but not necessarily exactly where the location is located. For example:
11900 Hunting, Pickerington, OH, 34147
<Zip>43147</Zip> <City/> <County>Fairfield</County> <StateName>Ohio</StateName> <StateAbbreviation>OH</StateAbbreviation> <TaxRate>0.06750</TaxRate> <StateRate>0.05750</StateRate> <CityRate>0</CityRate> <CountyRate>0.01000</CountyRate> <MatchLevel>Address</MatchLevel>
This is a bad address. However, through extra validation we know the other parts of the address are good. We know the zip code and county are good, but it’s possible for multiple cities to fall within these boundaries. Analysis shows the rates would be the same regardless so while we are not able to accurately tell what city is attached to the address, we still know every address in the potential area would have the same rate, so we can confidently say the rate would be good for the address. Another example shows an even more obvious reason why we might not have a value:
8538 Smith Street, Wales, MI, 48027
<Zip>48027</Zip> <City>Wales</City> <County/> <StateName>Michigan</StateName> <StateAbbreviation>MI</StateAbbreviation> <TaxRate>0.06000</TaxRate> <StateRate>0.06000</StateRate> <CityRate>0</CityRate> <CountyRate>0</CountyRate> <MatchLevel>Address</MatchLevel>
Again, the address is bad, but this one is easy. Michigan only has a state rate, which means that all addresses within Michigan will have the same state rate. The analysis of city, county and zip shows a consistent city and zip, but the county could be multiple results. So, we can display city and zip code but not county. FastTax is not intended to be an address validation service, but a helpful tip is to look at the Zip return. If the Zip is 5 digits, it meant something happened during validation and the address did not pass inspection.
The latest GetBestMatch updates also added support for the US Territories (Guam, Micronesia, American Samoa etc.) Here is an abbreviated example of an address in Guam:
Bldg 30 Farenholt, Tutahan, 96910
<Zip>96910</Zip> <City>Hagatna</City> <County>Guam</County> <StateAbbreviation>GU</StateAbbreviation> <TaxRate>0.05000</TaxRate> <StateRate>0.05000</StateRate> <CityRate>0</CityRate> <CountyRate>0</CountyRate> <MatchLevel>Address</MatchLevel>
In addition, we already supported military locations within the United States, but now there is support for all of the remote bases around the world as well. An abbreviated example of that can be seen here:
Unit 28103, USAG Graf Chaplain, APO, AE, 09002
<Zip>09002</Zip> <City>Apo</City> <StateAbbreviation>AE</StateAbbreviation> <TaxRate>0.00000</TaxRate> <StateRate>0.00000</StateRate> <CityRate>0</CityRate> <CountyRate>0</CountyRate> <MatchLevel>Address</MatchLevel>
Since all of these locations, even the ones abroad, had US assigned postal codes; making sure we could return results was of utmost importance. We now have a complete list of results covering all areas associated with the United States.
Finally, the latest operation also now supports JSON responses as one of our last services to be converted. This operation was also created to be more dynamic, information components outputs allow us to add new results on the fly without breaking any client integrations, like those using SOAP. Fields such as CountyFIPs have already been added, and the new field UnincorporatedTaxRate will also be added here. These fields allow us to work with our clients to add custom logic or results that might not otherwise be available.
Is there a custom logic you’d like to see in FastTax? Reach out and let us know, or get your free trial key and start testing today.
