> That's exactly why it's done that way. Because the tax is different in every state, county, city, and sometimes an even smaller region. There is something like 2,500 different tax jurisdictions in the USA.
It's quite ridiculous.
I played around once with the tax rate and boundary files [1] provided by the ~23 states that are in the Streamlined Sales Tax system. I remember finding several cases where a tax boundary ran through an office complex so the tax rate would be different between 123 Fake Street, Suite 100 and 123 Fake Street, Suite 200.
This is very annoying because it means to compute the tax you need a full address. For online sales of downloadable digital goods tax is often the only thing you need a full address for. For the actual sale all you need is a credit card number, the card security code, the billing zip code, and an email address to send a receipt to. And actually you usually don't even need the security code and billing zip but not providing them may lead to higher fees due to increased fraud risk.
Looking up tax by full address is annoying because the address people think they are at often doesn't quite match the official address for that location. They might use the wrong directional prefix or suffix, or put them on the wrong end, or give the local nickname people use for a street instead of the actual name, to give a few examples.
I found a way that worked surprisingly well, despite that. I'd take the address as supplied by the user and find the zip code and the building number. I'd then select from the boundary database all locations that matched the zip and building number.
So say the address is 123 NW Fake ST, Mycity, Mystate, 12345. I'd find all boundary file entries with zip 12345 and an address range that included 123. Note this just looks at number and zip, so would not include Fake ST but also any other street in that zip that includes house number 123.
For each of those I'd make the full address from the boundary file: building number, then any direction prefixes, then street name, then any type suffixes ("St", "Ave", etc), then any direction suffixes, then city, then state, then zip.
I'd then compute the Levenshtein distance between each of those and the address given by the user and take the one with the smallest distance.
Anyone know how the companies that provide tax lookup services handle this? I assume they do something way more sophisticated than my hack described above.
[1] https://www.streamlinedsalestax.org/Shared-Pages/rate-and-bo...