7 ms·

Wait until you get into the complexities of taxation. If you think you know them, pay attention to https://twitter.com/aotearoa_ben/status/1526786701750050817

by btilly 4y ago

Wait until you get into the complexities of taxation. If you think you know them, pay attention to https://twitter.com/aotearoa_ben/status/1526786701750050817 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/school-supplies.php 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...

jef_leppard 4y ago
I worked on a tax app. Total nightmare. I remember having to adjust tax rate for a couple parishes in Louisiana and a city in Florida for example. Trying to come up with a readable, testable, way to get that done was something I tell ya.
- lowercased 4y ago
  similar. worked on invoice app having to apply tax, and working with existing foxpro(?) tables that were in postgresql. Trying to reverse engineer without having access to original code, and make things work "like they used to". Someone manually pulled down some free tax thing once per month, but there were so many exceptions that people knew about that were just hardcoded in to the code that I had no access to that I could never make it "just work". 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.
_tom_ 4y ago
I worked on a tax app. I was amazed to find that some tax tables necessary to compute taxes were not released until months after taxes were due. WTF?
philliphaydon 4y ago
I used to work at a company that managed the systems for back of house in fast food chains. We moved customers from excel to an online system. Omg when it came to doing labouring in the US. It’s scary. 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.
- _tom_ 4y ago
  It's so much worse than that. Some payroll tax laws vary by SCHOOL DISTRICT of the employee.
  - sharken 4y ago
    Much like airport taxes around the world are also different and can change at any time. It is an interesting challenge though, to create software that is easy to maintain while capturing all these complexities.
systemvoltage 4y ago
We should demand governments to maintain and provide an API for their tax codes. Let them have skin in the game. If the taxes are incorrect, businesses can point out that it’s the government API’s fault. 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.
- tornato7 4y ago
  This actually sounds like a good use for smart contracts if we switch to a CBDC. Basically you pass your transaction through whatever state’s contract and it will automatically do the tax withholding for you.
- nemothekid 4y ago
  Why would you do that when you could just lobby the government to make the tax code even more complex, then sell a service to handle that complexity for you under the threat of jail time if you get it wrong?
  - systemvoltage 4y ago
    You're being facetious but I don't think this is a radical idea. Government already publishes the tax code in English language. This is just formalization of the tax code in computer code: More precise, testable and provable.
    - btilly 4y ago
      What makes you think that this is being facetious? https://www.propublica.org/article/inside-turbotax-20-year-fight-to-stop-americans-from-filing-their-taxes-for-free 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.
      - systemvoltage 4y ago
mox1 4y ago
Just do what eBay does and just charge sales tax on everything!
ProAm 4y ago
Wait until you deal with Brazil. Billings systems are not hard they take engineers that are thoughtful and long-term thinkers which is not conducive to today's software developer hires. Which is why posts like this are made, Its a market ripe for dominance.
deleted 4y ago
[deleted]
oger 4y ago
Our team was building a telco operator in the U.S. We already did that in several European markets and in Australia - so we assumed that we were mildly proficient in taxation issues. And then came the U.S. - a complete nightmare of overlapping rules that sometimes are not properly published. In essence you cannot do this on your own - you definitely need a tax service provider (like Avalara). Funny thing is though that you still are pretty safe to be noncompliant sometimes somewhere and the provider will not take on the liability if their data / computation was wrong. In short: a mind-blowing disaster. And you had to PRINT your tax forms and SNAIL-MAIL them to every jurisdiction that you were doing business in. I mean: hundreds or even more. Every. Single. Month. And don't get me started on the banking system stuck in Stone Age. I definitely would think twice to set up a business in the U.S.
dormento 4y ago
* Cries in brazilian *
nulluint 4y ago
elevation 4y ago
Even when the laws are comprehensible and you're not running at scale, existing accounting systems make supporting simple new requirements difficult. 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?

by btilly 4y ago

jef_leppard 4y ago

I worked on a tax app. Total nightmare. I remember having to adjust tax rate for a couple parishes in Louisiana and a city in Florida for example. Trying to come up with a readable, testable, way to get that done was something I tell ya.

lowercased 4y ago
similar. worked on invoice app having to apply tax, and working with existing foxpro(?) tables that were in postgresql. Trying to reverse engineer without having access to original code, and make things work "like they used to". Someone manually pulled down some free tax thing once per month, but there were so many exceptions that people knew about that were just hardcoded in to the code that I had no access to that I could never make it "just work". 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.

_tom_ 4y ago

I worked on a tax app. I was amazed to find that some tax tables necessary to compute taxes were not released until months after taxes were due. WTF?

philliphaydon 4y ago

I used to work at a company that managed the systems for back of house in fast food chains. We moved customers from excel to an online system. Omg when it came to doing labouring in the US. It’s scary. 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.

_tom_ 4y ago
It's so much worse than that. Some payroll tax laws vary by SCHOOL DISTRICT of the employee.
- sharken 4y ago
  Much like airport taxes around the world are also different and can change at any time. It is an interesting challenge though, to create software that is easy to maintain while capturing all these complexities.

systemvoltage 4y ago

We should demand governments to maintain and provide an API for their tax codes. Let them have skin in the game. If the taxes are incorrect, businesses can point out that it’s the government API’s fault. 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.

tornato7 4y ago
This actually sounds like a good use for smart contracts if we switch to a CBDC. Basically you pass your transaction through whatever state’s contract and it will automatically do the tax withholding for you.
nemothekid 4y ago
Why would you do that when you could just lobby the government to make the tax code even more complex, then sell a service to handle that complexity for you under the threat of jail time if you get it wrong?
- systemvoltage 4y ago
  You're being facetious but I don't think this is a radical idea. Government already publishes the tax code in English language. This is just formalization of the tax code in computer code: More precise, testable and provable.
  - btilly 4y ago
    What makes you think that this is being facetious? https://www.propublica.org/article/inside-turbotax-20-year-fight-to-stop-americans-from-filing-their-taxes-for-free 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.
    - systemvoltage 4y ago

mox1 4y ago

Just do what eBay does and just charge sales tax on everything!

ProAm 4y ago

Wait until you deal with Brazil. Billings systems are not hard they take engineers that are thoughtful and long-term thinkers which is not conducive to today's software developer hires. Which is why posts like this are made, Its a market ripe for dominance.

deleted 4y ago

[deleted]

oger 4y ago

Our team was building a telco operator in the U.S. We already did that in several European markets and in Australia - so we assumed that we were mildly proficient in taxation issues. And then came the U.S. - a complete nightmare of overlapping rules that sometimes are not properly published. In essence you cannot do this on your own - you definitely need a tax service provider (like Avalara). Funny thing is though that you still are pretty safe to be noncompliant sometimes somewhere and the provider will not take on the liability if their data / computation was wrong. In short: a mind-blowing disaster. And you had to PRINT your tax forms and SNAIL-MAIL them to every jurisdiction that you were doing business in. I mean: hundreds or even more. Every. Single. Month. And don't get me started on the banking system stuck in Stone Age. I definitely would think twice to set up a business in the U.S.

dormento 4y ago

* Cries in brazilian *

nulluint 4y ago

elevation 4y ago

Even when the laws are comprehensible and you're not running at scale, existing accounting systems make supporting simple new requirements difficult. 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?