fastdivision
commented
6 years ago Hi @andrewhavens, thanks for taking the time to share your use case and specific examples of jurisdictions that go beyond a 1-to-1 pairing. The jurisdiction names we now return in our tax endpoint simply mirror our rates endpoint because developers wanted to display the names in a simplified tax breakdown without making multiple API requests.
Ideally, we'd expose more jurisdiction data down to the district level and return multiple jurisdiction parts where applicable. We handle this data for our own internal reporting and filing software, but we'd have to invest more time in our API to make this data accessible. I'll share your feedback with our team and use it for reference later when we decide to prioritize improvements.
I'm sure this is a problem with the API, but I use the Ruby client, so I'm reporting it here. I've been working on generating tax reports for the company that I work for and have had to manually calculate the tax rates for places that have more complicated local/use tax requirements. I noticed that the Ruby client recently added support for accessing the jurisdictions. However, it assumes that there is only one jurisdiction part per county/city. In my experience, a given address may have multiple parts which make up its jurisdiction which don't map 1-1 to a county/city (e.g. transit taxes, ambulance district taxes, etc) , which result in different tax rates and reporting requirements.
Missouri example:
JACKSON COUNTY
KANSAS CITY ZOOLOGICAL DISTRICT
PINE TREE CID
Texas example:
There may be other states like this.
These states have unique reporting requirements which require access to all of this different information. It would be nice if the Taxjar API could provide this information. I currently have to scrape data from multiple sources in order to properly generate reports for these states since Taxjar does not provide this information.