The Streamlined Sales Tax Project (mentioned earlier) provides standardized boundary and summarized rate data, which are updated by member states quarterly. After digging deeper into the project, I realized this is not a currently a solution for the entire US. Since the project has been around since 2000, it doesn’t seem very likely to me that additional states (including some of the most populous) will join the project anytime soon (some reasons offered by New York, most of which could be traced back to the data format not being flexible enough), but it does seem to be a complete solution for those states that are part of the project (all 22 of them). At any rate, the project seems to have awakened the need to have a more streamlined process across all states to make it easier to collect sales tax from out-of-state businesses.
Looking at the SST rate data for all member states, only one state currently has five rate components, all others have less than that.
Looking at the actual types (i.e. Jurisdiction Types or what would likely be Tryton tax groups) of active component rates for all member states (combined):
| Jurisdiction Type | Component Rates |
|---|---|
| State | 22 |
| County | 1093 |
| City | 4229 |
| Town | 19 |
| Special District | 2324 |
| Other Combination Collection | 5 |
| Other Special Applications | 4 |
If we look at tax components per state, we get something like this:
At this point, I’m not sure whether it would be worth developing a module for this when it is not a complete solution for the US. But it may be a complete solution for businesses that operate only in some states. Downsides are that the database would be bigger (due to the boundary and rate data for the states that the company operates in) and the module’s data would need to be updated once a quarter (either with Tryton’s scheduler or by manually running a script).
As far as tax rules go, I believe the basic tax computation could be done dynamically, without Tryton’s tax rule system, due to a boundary record containing all of the relevant jurisdictions (i.e. tax component references) for a given ZIP+4 postal code. The module would be dependent on the USPS address verification module (described above) to obtain the ZIP+4. We would need some way to trigger the SSTP tax calculation when the address is in a supported State (subdivision for US addresses). I wonder whether tax rules could be used for this?
Openlabs created a Tryton (3.2.1) module for Avatax that creates taxes in Tryton just in time. Their reported reason for doing this was not primarily due to Tryton’s rule system performance, but because “the US supposedly has 11,000 tax jurisdictions and keeping the system updated with all the rules could easily end up being a full time job and a pain in the rear!” While a SSTP module would help with the maintenance problem for a select number of states, comparing performance between these two approaches is something that I’ve not yet done.