We transitioned to using an external tool (taxjar, IIRC, but might have been something else). Was a pain to feed them data to get back tax data, and.. so many exceptions and exemptions I had to learn about. Weeks later I get "all these numbers are wrong".
I dug in and went through logs.
"no, these are right. taxjar is adding x% on ABC and shipping".
"We don't charge tax on shipping".
"Well, taxjar is doing it, because it's how you're supposed to do it in this state".
"We've never charged tax on shipping"
"Well... you've probably been non-compliant for years then".
I think when they'd started 'computerizing' this back in the early 90s, shipping costs weren't taxed. Or... (IIRC) the amount of shipping cost taxed was proportional to the amount of taxable goods being shipped in the state (vs out of the state) and when they started, what they were shipping wasn't mostly taxable (like... some of the main items were taxable, but the supplies weren't, or something similar). And... if they were shipping to a non-taxable entity (non-profit) then the in-state shipping charge wasn't taxable, but they were supposed to pro-rate it based on the proportional distance in the target state, if that state charged tax on shipping, then track that and remit to that appropriate county/state authority.
These were some of the rules that a variety of people had tried to describe to me both what they thought was supposed to happen and what they thought the original software was doing, but... they could never find 2 examples to line up to confirm or justify those explanations.
Another example: certain items (chemicals) were taxable in some counties and not others, and might be taxed differently based on whether they were being 'used' by technicians vs delivered to a customer (again, different counties had different rules - and some of these rules were indeed confirmed by digging through taxjar and their support and state agency websites).
When this company started, it was one location in two counties in one state, and as they grew, the specifics grew (and also changed yearly) and what they should do became lost to everyone.
Moving things to an external hosted tax-as-a-service system was supposed to 'simplify' things, but it just introduced a lot of turmoil and headache, because routine numbers people were used to for years were suddenly replaced with "new" numbers which no one trusted.
Completely developed in the open, and with full test coverage.
This should be required to collect taxes. No API? No taxes. API down? Tax waived.
The only way to reduce the pain instead of just shifting it around would be to massively simplify the source of truth - tax codes and laws.
I have to imagine government workers are already writing software to identify if we’ve all implemented it correctly, when the could have just given us the code/api up front.
Because of the jurisdiction issue, even if each local (and for each location all relevant governmental tax authorities) had a clear API, interacting with them all, and dealing with the interactions between them recursively, is itself a large problem.
And from what I've seen from smaller jurisdictions, the automation software is all about simplifying a human-in-loop workflow rather than full machine-driven rules.
I could imagine a world where the IRS ran the tax software for every taxing entity in the US. Each jurisdiction would have to configure their specs or potentially even codify the business logic. International would likely be tricky but it's similar to what is being done with ACH and other banking systems that are slowing moving to international. So, it's not impossible there's just not much of a push for it.
Nay. Shifting pain from thousands of projects to a single org obviously reduces overall impact.
If you believe the statistics on literacy and multi-lingualism, it's a tossup as to whether Chinese or legalese is more widely understood.
Some tax regulations were considered illegal by higher authorities, but that won't stop a tax auditor in a local level charging them and potentially closing down your business.
https://www.propublica.org/article/inside-turbotax-20-year-f... has a good overview of how companies that provide software for calculating taxes guarantee a market for their products by keeping the process of calculating taxes more complicated than it needs to be.
I have no words to describe what I just read. That's straight out of the TV show Silicon Valley.
Source used (non-US) government api to do with legislation. The freaking ambiguity and cludges. Luckily they had a team of good people to help.
If a person clocks in at 9:52M. The company only has to pay them from 10am. But in other states they must pay from 9:45am. There’s so much complexity in the us due to all states being different.
It is an interesting challenge though, to create software that is easy to maintain while capturing all these complexities.
Imagine a US LLC setting up their chart of accounts to track IRS deductible expenses. Coding expenses into this 17-account schema in the normal course of book keeping means taxes can be filled by copying the account totals into the corresponding IRS form field.
But later, the business wins an federal contract which reimburses certain "R&D" expenses and possibly some "overhead" expenses. Now not only must every expense must be categorized with one of 17 expense categories for the IRS, but it must also be categorized with one of 3 categories for our federal contract purposes. But wait, a small business loan application may require profit and loss broken down by a different set of categories. New and local tax authorities may impose other categories.
One way to address this complexity explosion is with multiple instances of the same accounting software; each imports the same bank account statement, then justifies it against a chart of accounts. But many businesses will break out Excel and hope there aren't too many expensive errors.
If new regulation is inevitable, why does our software pretend otherwise?
If you think you know them, pay attention to https://twitter.com/aotearoa_ben/status/1526786701750050817.
That's a law that changes the tax rate if
1. The purchase happens in Texas. 2. The payment cleared in a specific 2 day period. 3. The item cost < $100. The cost of shipping has to be included in the item's cost. 4. The item falls into specific categories that almost certainly don't match whatever categorization system you are attempting to use.
Seriously, calling out just one example, https://comptroller.texas.gov/taxes/publications/98-490/scho... points out that a kit containing school supplies qualifies as long as the cost of the qualifying school supply items in it exceeds the cost of the non-qualifying items. I guarantee that you don't have a category for that in your accounting system...