Hacker News new | past | comments | ask | show | jobs | submit login
Stripe Tax (stripe.com)
939 points by sirodoht 11 days ago | hide | past | favorite | 367 comments





Note that if you are just interested in US sales taxes, and only need to collect tax in the ~1/2 of the states that are part of the Streamlines Sales Tax (SST) project, you can have your tax rate calculation, registration, reporting, and filing all done for free.

The member states of SST have agreed to pay for those services from several tax SaaS companies. (There is one catch: to avail yourself of this, you must collect tax for all SST states, even though you might be below the threshold in some of them).

The companies participating are Avalara, TaxCloud, Sovos, and Accurate Tax.

For small online businesses I suspect that a lot more can take advantage of this than you might expect. Here's a map showing the SST member states [1]. Although it is missing some big states that you probably do a lot of business in (California for instance), a lot of those big states have quite high thresholds for sales or number of transactions before tax kicks in.

Some of the companies that provide the fee SST service will also add non-SST states for a fee. If you only need one or two non-SST states, it will still probably come out cheaper than using Stripe (and will include reporting and filing).

[1] https://www.streamlinedsalestax.org/


Based on my personal experience I would recommend staying away from TaxCloud. When they make mistakes filing for you (and they have) the states will come to you directly with scary letters, TaxCloud won't answer your calls or messages. The only way I was able to sort things out was by getting another states small business advocate to help.

TaxCloud also has a habit of changing their fees without notice. Currently they charge an API access fee even for their "free" accounts.

Finally, they lock you in by not giving you enough information to cancel all the accounts they started for you in other states but not providing a clear way to cleanly close your account.


Thanks for the insight, I hope SST get more adaption.... https://www.streamlinedsalestax.org/.

How quickly my excitement disappeared when I saw that California was not a member. Thanks for the information; I'm sure there are others, like myself, that have no idea such a thing exists.

I'm somewhat baffled by California not being a member.

California's threshold below which out of state remote sellers do not have to register, collect, report, or remit sales tax is $500 000/year of sales into California.

If I'm a remote seller using the free SST option to handle my taxes in the SST states, and am selling say $300 000/year in California, I will not be collecting any California tax.

If they joined SST, I would have to collect California tax even though I'm below the threshold because the deal to get free full service tax handling under SST is that I collect for all SST states.

I don't see any downside for California. At the stroke of a pen, they would suddenly be getting tax collected from a ton of remote sellers that fall below the $500 000/year threshold.

Same with Texas, which also has a $500 000/year threshold, or New York which is $500 000/year and 100 transactions, or Florida which is $100 000/year, or Illinois which is $100 000/year or 200 transactions.


California is not a member of the SST because it does not currently tax a number of things that are subject to tax under the SST regime. For example, digital goods are taxable in SST states but not in California.

Similarly, there are a number of other product categories where CA's taxability classifications do not match the SST's classifications.

Generally, the total tax they could collect from remote (non-CA) sellers below the $500k nexus threshold is not worth the effort it would take to change things so that CA could join the SST, and moreover, it would require significant changes by CA sellers.

Generally, those same considerations also apply in NY: the cost burden on local sellers to make the change would dwarf any minuscule tax increase from joining the SST.


The US could really use some national action on sales taxes.

I'd like to see Congress make it so a state can only require remote sellers with no physical presence in the state to collect tax for the state if:

1. Tax rates on remote sales are uniform within a zip code. No more having to deal with "123 Fake Street, Hooterville, 65026" having a different tax rate than "124 Fake Street, Hooterville, 65026". (Worse, I recall finding an example where a tax boundary apparently ran through an office building, so different offices on the same floor had different tax rates!).

2. They adopt a standard for tax classification that will be specified by the Federal government. They don't have to change the classifications used for taxing sellers with a presences in the state, but for remote sellers they have to use the Federal classifications.

3. Rates for remote sales can only change once per quarter, and the data for the quarter must be published one month before the start of the quarter. It must be published on the web, at a URL that requires no registration or fees, in a format specified by the Federal government. The Federal government would maintain a web page that contains links to the state data pages.

4. Sellers can report taxes using a uniform format defined by the Federal government. The format supports reports that cover the taxes for more than one state. The seller can file such a multi-state report with any state that requires remote sellers to collect tax that they owe tax to, and that state will forward the report to the other states it contains data for. The seller can also pay all the tax to that state, and it will transfer the appropriate amounts to the other states.

If Congress did this it would make dealing with remote sales tax so much easier.


Does Congress have that power? I suppose you could argue they're interstate commerce regulations, but idk if that'd fly.

Edit: Obvious SD v Wayfair is relevant here, https://www.supremecourt.gov/opinions/17pdf/17-494_j4el.pdf

It's too complex to even take a stab at guessing what they'd say based on that though. Also, I'd forgotten what a wild lineup the votes were.

GINSBURG, ALITO, and GORSUCH, JJ., joined. THOMAS, J., and GORSUCH, J., filed concurring opinions. ROBERTS, C. J., filed a dissenting opinion, in which BREYER, SOTOMAYOR, and KAGAN, JJ., joined.

Edit again: Seems Roberts agrees Congress can do something:

Roberts noted that Congress has been considering whether to alter the physical-presence rule, and “nothing in today’s decision precludes Congress from continuing to seek a legislative solution. But by suddenly changing the ground rules, the Court may have waylaid Congress’s consideration of the issue.”

The majority “proceeds with an inexplicable sense of urgency,” the chief justice said, and it “breezily disregards the costs that its decision will impose on retailers.”

There are complex distinctions made in more than 10,000 taxing jurisdictions, he said.

“New Jersey knitters pay sales tax on yarn purchased for art projects, but not on yarn earmarked for sweaters,” Roberts said, while Texas imposes a sales tax on plain deodorant but not on deodorant with antiperspirant, and Illinois treats Twix and Snickers bars differently for sales-tax purposes.

https://www.scotusblog.com/2018/06/opinion-analysis-court-ex...


It's kind of hinted at somewhere in Wayfair that this is really kind of about the defaults when Congress declines to speak.

Congress has extremely broad powers to regulate interstate commerce which would let them decide if and how states can make sellers in other states collect for them. So far, Congress has declined to weigh in, and so we get the default.

For some things the default is that states cannot do them unless Congress says they can. For others the default is that they can do them unless Congress says they cannot.

With Congress remaining silent, it is up to the courts to figure out what the default is for a given thing. Wayfair is essentially saying the older decisions picked the wrong default.


Although your belief is a common one even at the highest levels, reality is that Art. 1, §8, cl. 2 is not actually as broad a power as is believed and/or imagined. People are reading something into that clause that did not exist when it was written, nor should it exist today. It is a function of the misunderstanding of what "regulate" means as it is and was meant, rather than what today's manipulators or "designing men" as Andrew Jackson called them, intend to imprint on it.

When written, "regulate" did not mean control by authoritarian and dictatorial means, absent of checks and balances and controls on power as it is implied today, i.e., "we {insert unelected bureaucratic authoritarian agency} decree by regulation that you may not do this thing or that you have to do this thing." What "regulate" meant when written was to order and bring into purpose suited structure, to bring into a regular state, opposed to an irregular state. There was no overt or hidden or implied sense of manipulation and control implied, it was a description of state, not action.

It is something that is to a large extend willingly overlooked by those who are authoritarian minded, but this natural entropy of language/meaning and even often deliberate and intentional manipulation of language and words (see today's public dialogue and clear and intentional manipulation of language, i.e., you can say some things and the meaning and use of other things is imposed or assaulted), causes excessive amounts of problems. A good example of this kind of change, is the word matrix; that means a pattern of lines or marks, usually in a uniform layout, which used to mean nothing more than a female breeding animal since time before records and well into the 18th century, including even today in niche agricultural circles. The connection to the breeding female coming from the sense that a mathematical matrix is a component into which quantities can be set, or bred into.

Congress does not technically have the right to control commerce, let alone trade, but it does have the power to set commerce into and orderly, or regular state; opposed to an irregular state, i.e., into a wanton and unpredictable state. That does not include using its powers to change or manipulate it with objectives or outcomes in mind.

But regardless of what I say or even the founders meant, the great powers of human hive-mindedness and whoever can control it will ultimately determine the outcome and impacts. We are rapidly approaching a state where everything and anything in the Constitution is essentially put through an authoritarianism conversion where everything is interpreted as meaning centralized control and power, while always and relentlessly stripping individuals of power and control over their own lives and freedoms … all by changing language, which is precisely why certain groups are so focused on changing the language, because if you change the meaning of freedom to slavery, then you are halfway to 1984.


>Although your belief is a common one even at the highest levels, reality is that Art. 1, §8, cl. 2 is not actually as broad a power as is believed and/or imagined.

Ultimately, reality is whatever people alive now determine it to be. The intentions of the original authors of the Constitution are interesting, sure, but only "real" in the sense that they guide the actual decision makers of today.


Fascinating claims. Can you link to any legal treatises that explain this idea further?

Sorry Ot and won't sound offensive, but i am reading each 'commerce' interpreted with 'ads' -so my two cents... (-;

comic #646 are you in a partisan state ?: > //abload.de/img/646_en_areyouinapartisxjts.png


Probably not to enforce standards, but they certainly have the power to create standards and incentivize their use. Much in the same way they can't control speed limits on national highways or the drinking age in various states, yet these laws are largely uniform across the country.

Those rules have to be on a funding source that's plausibly related and it has to be non-coercive. I'm struggling to think of a relevant funding source here.

> Those rules have to be on a funding source that's plausibly related and it has to be non-coercive.

That seems to not be the case in practice. Highway funding is dependent on states setting a legal drinking age no lower than 21. Those two things are not plausibly related. And it's definitely coercive.


The two are completely plausibly related. Drinking age has a direct affect on the amount of drunk driving on roads and therefore the safety of them. The main group behind the push to 21 was Mothers Against Drunk Driving.

In fact, the Supreme Court case about this was where they came up with the rule!

https://en.wikipedia.org/wiki/South_Dakota_v._Dole

The actual test is:

    The spending must promote "the general welfare."
    The condition must be unambiguous.
    The condition should relate "to the federal interest in particular national projects or programs."
    The condition imposed on the states must not, in itself, be unconstitutional.
    The condition must not be coercive.

TIL states can now force out-of-state companies to collect and remit taxes.

Yeah, it sucks. However, not all goods, not all states even have an existence of a nexus. Virginia specifically exempts sales taxes of digital products delivered electronically, such as software, downloaded music, ringtones, and reading materials.

The basic rule for collecting sales tax from online sales is: If your business has a physical presence, or “nexus”, in a state, you must collect applicable sales taxes from online customers in that state. If you do not have a physical presence, you generally do not have to collect sales tax for online sales. In the court ruling that allowed this, it was determined that Wayfair did have a nexus in those states. Not all businesses operate that way and there are a lot of gray areas.


> If you do not have a physical presence, you generally do not have to collect sales tax for online sales.

That was how it stood before the Wayfair ruling. Under Quill Corp. v. North Dakota (1992) and others, the Court had ruled that states did not have the power to force out of state sellers to collect tax for remote sales unless the seller had a physical presence in the state.

Wayfair overruled Quill. The Court created a new kind of nexus, an "economic" nexus, and ruled that an economic nexus was sufficient to allow states to force out of state sellers to collect.

Merely selling a sufficient volume into a state is sufficient to create an economic nexus. They didn't give any hard and fast rule for deciding what is a sufficient volume, but the state involved in the Wayfair case, South Dakota, was trying to charge tax on any out of state seller that had more than $100 000/year in sales or more than 200 sales per year in South Dakota so we know that is on the "sufficient volume" side of things.

The rule for online sales tax in the US is now this:

1. If you sell online to customers in state X, you need to look up that state's economic nexus law to see what their threshold is. Here's a good place for this [1].

2. If your sales volume is not under the threshold, you need to check to see if that state exempts your particular product or service.

If you hit the threshold and there is no exemption, welcome to hell.

[1] https://www.avalara.com/us/en/learn/guides/state-by-state-gu...


Honestly, I wonder if the level of autonomy we provide to states and lower subdivisions makes sense anymore in an era of one-day delivery and non-in-person sales.

They're buying the same goods, with the same currency, backed with the same warranties, and shipped with the same couriers, but because some of your customers are on the other side of an arbitrary line drawn for a political gambit in the mid-1800s, here's an entire second set of rules and documentation to deal with.

Even if you can somehow convince all the states to play ball, and not tie any sort of standardization process in the courts until six months after the heat death of the Universe, you've got the same problems on different scales with patchworks of local authorities.

If anything, though, what we should be looking for is a uniform national VAT or sales tax, distributed proportionally back to the states/local authorities. It would discourage the "race to the bottom" gaming of special tax regions and exemptions to attract business, and take funding for essential aervices out of the hands of state legislatures. In at least some states, we have real problems because such legislatures will do things like "taxes can only be raised as a ballot initiative with supermajority" as political posturing, then hatch up harebrained schemes like "the courts said we actually have to fund public schools, let's sell off state-owned land as a one-time earner" to kick the can down the road.

Added plus: we could reasonably price goods as tax-inclusive, like in the UK, because the marketing copy can be consistent and accurate everywhere.


1. Congress does not have that power, as it would interfere with the states' control of in-state commerce. They could however make that a requirement for requiring out-of-state sellers to comply with sales tax.

2. Same as #1.

3. Rates for sales tax generally change every few years as it requires an unbelievably large amount of notification to sellers, service providers, etc. Where sales tax rates change faster than that, it is usually part of a pre-planned and pre-published change in rates occurring over several years. A sales tax rate changing annually is actually fairly uncommon; a sales tax rate changing more frequently than annually (absent special circumstances like COVID19 incentive rates) is extremely rare.

4. This is basically the purpose of the Streamlined Sales Tax, which is an initiative of over two dozen states to streamline sales tax compliance: only a single return is required and it covers all of the member states. However, it is voluntary.

Note that your suggestion for payment is unfeasible, since it would require each payment to also include the tax liability data for every other state, and each state would have to set up a separate bureaucracy to handle money transfer. It's faster and more efficient for taxpayers and states to simply have the taxpayer use existing payment mechanisms to pay each state separately. On the taxpayer side, it's literally seconds more work if you're using a unified tax system (like the SST).


1. Oops. I forgot to say that this was only to apply for sales taxes on out-of-state sellers.

2. I did remember to mention that for #2.

3. The rates that apply to a particular location in a state might change infrequently, but there are a lot of locations, so even if each location's rates change infrequently there can still be a lot of rate changes within the state each quarter.

For example, in my state (Washington), there are ~1 million 9 digit zip codes listed in the rate data the state makes available. Here is how many of those areas had rate changes compared to the previous quarter starting from 2020:

  2020q1   14930 changed
  2020q2  121464 changed
  2020q3    9084 changed
  2020q4    1779 changed
  2021q1  185365 changed
  2021q2  115306 changed
(This is only counting cases where the zip exists in the rate tables for two consecutive quarters. There are also zips being added and removed which I'm ignoring).

In those 6 quarters many places actually changed more than once, the most extreme being 98520-6503 which changed every quarter.

  2019q4  8.98%
  2020q1  8.80%
  2020q2  8.90%
  2020q3  9.08%
  2020q4  8.90%
  2021q1  9.08%
  2021q2  8.90%
Among all the places whose rate changed sometime in 2020 or 2021 (so far):

  436523 changed 1 time
    4533 changed 2 times
     654 changed 3 times
      84 changed 4 times
       7 changed 5 times
       1 changed 6 times
4. SST would be great if every state did it, but as you note it is voluntary, and as you noted in other comments I believe several states apparently have no interest in joining. If the Feds did it, they could make it mandatory, and they could make it simpler (such as making it purely zip code base5 (hopefully 5 digit only) instead of address based).

With it zip based and updated at most once per quarter, almost all the complexity of dealing with finding rates go away. Heck, I would probably remove the address entry fields from our shopping cart because we sell downloadable goods and tech support for those goods. The only reason we have to ask for address is for sales tax lookup.

What I'm basically suggesting is something similar to the EU's VAT MOSS system. Here's how we deal with VAT for our EU sales. (1) It is one rate per country. I had a local DB with the rates. (2) Once a quarter I make a CSV file that lists country, our sales in that country, the VAT rate of that country, and how much tax we collected. (3) Once a quarter someone in ops uploads that CSV to the Irish tax authorities and we pay them the total of all EU VAT we owe for that quarter. (4) The Irish tax authorities forward the data to the other EU countries along with the tax owed (logically...I'd assume that physically they do something like net out things first. Just as we pay our Italian and German VAT through Ireland, there are others paying their Irish VAT through Germany or Italy, and there is no need to have say Ireland pay Germany at the same time Germany pays Ireland).

I don't see why the states could not do something similar, so that I just send a CSV of state, zip, sales, rate, amount collected to one state along with the total tax collected and let them distribute it. Maybe have the Feds set up a clearinghouse for the states to use that actually deals with netting things out and settling between the states. Might as well then go one step further hand have the sellers just upload directly to the clearinghouse.


Addendum: I got curious about that place that changed every quarter, zip code 98520-6503.

That zip covers the odd addresses in the 101-199 address range of E Wishkah ST in Aberdeen WA. The even side of that block is zip code 98520-6508 and only suffered one rate changed in that time.

The 200 block odd side changed twice, the 200 block even side changed once. Going the other way from the 100 block of E Wishkah, the odd side of 100 W changed once, and the even side twice.


3. WA DOR publishes all sales tax rate change notices on their website. https://dor.wa.gov/taxes-rates/sales-and-use-tax-rates/local...

In 2020, there were fewer than a 2 dozen rate changes throughout the entire year at the local level, none at the state level, and certainly not any rate changes in a single tax locale occurring multiple times during the year at any level. And this was verified by running tax rate reports for the state of WA in Avalara for each quarter in 2020.

I understand the point you're trying to make, but you're not going to win this argument by making up such blatant falsehoods. (Note that I actually handle the sales tax compliance for my company, including the state of WA, and I am definitely more familiar with sales tax rate changes than you are.)

4. The Feds do not have the power to require states to join the SST as it would violate the states' right to control intrastate commerce.

4a. Zip-coded based taxation is not sufficiently granular. For example, a single zip code in LA can contain multiple municipalities. A number of zip codes cross county and state lines. (9-digit zip codes are more granular, but only areas with sufficient mail volume are assigned the extra 4 digits.)

4b. I don't know what is behind your fascination with updating sales tax rates every quarter. Sales tax rates are generally updated every few years for any given tax location. It only seems like they update more frequently than that because you are conflating local tax jurisdictions with state-level jurisdictions.

4c. I know how VATMOSS works; as I have stated elsewhere I am a tax professional and handle indirect compliance functions for my company.

There is not a single VAT rate per country; there are 3 or more rates, corresponding to the different VAT classifications of goods. Most EU countries have 3 rates; during COVID several of them had as many as 7 rates (as a result of short-term discounted rates on certain types of goods and services).

Furthermore, only a limited number of VAT-subject digital goods and services are handled by the VAT MOSS system; physical goods are not VAT MOSS eligible, and classification/taxation of physical goods is 99% of the complexity of indirect tax regimes.

Additionally, the EU is legally and structurally fundamentally different from the U.S. VAT MOSS is possible in the EU because the member nations are bound to participate in EU economic initiatives as a condition of being a member of the EU (see, for example, the issues leading to Brexit). No similar legal arrangement exists between the American states; moreover, the U.S. Constitution does not grant the central/federal government the power to control commerce within a state.

It is simply not possible to have something like the VATMOSS in the U.S. It would require significant changes to the basic structure of American government. The best we'll get is the SST, and it's very unlikely that states like CA and NY will ever agree to give up control of their own tax systems to a system run by the Midwestern and Southeastern states.

Indeed, the SST exists primarily because most out-of-state sellers to these states would not sell enough to reach the nexus thresholds and so those sales would not be subject to sales tax; the SST is the carrot to get sellers to agree to handle sales tax compliance, and that is why it is mandatory to agree to sales tax for all SST member states as a condition of using the SST. (For example, without getting into specifics, my company's sales to all SST member states combined is less than the sales to CA, or NY, or FL, or CO, or TX, or IL.)


Washington publishes downloadable CSV files with rates here: https://dor.wa.gov/taxes-rates/sales-and-use-tax-rates/downl...

Here are commands to download the rates for the 7 most recent quarters and lookup the entries for 98520-6503:

  curl https://dor.wa.gov/sites/default/files/legacy/downloads/Add_Data/Zip4Q221E.zip > 21q2.zip
  curl https://dor.wa.gov/sites/default/files/legacy/downloads/Add_Data/Zip4Q121E.zip > 21q1.zip
  curl https://dor.wa.gov/sites/default/files/legacy/downloads/Add_Data/Zip4Q420E.zip > 20q4.zip
  curl https://dor.wa.gov/sites/default/files/legacy/downloads/Add_Data/Zip4Q320E.zip > 20q3.zip
  curl https://dor.wa.gov/sites/default/files/legacy/downloads/Add_Data/ZIP4Q220E.zip > 20q2.zip
  curl https://dor.wa.gov/sites/default/files/legacy/downloads/Add_Data/ZIP4Q120E.zip > 20q1.zip
  curl https://dor.wa.gov/sites/default/files/legacy/downloads/Add_Data/ZIP4Q419E.zip > 19q4.zip
  for i in *zip; do unzip $i; done
  grep 98520,6503 Zip4RatesQ42019-Long.txt
  grep 98520,6503 Zip4RatesQ12020-Long.txt
  grep 98520,6503 Zip4RatesQ22020-Long.txt
  grep 98520,6503 Zip4RatesQ32020-Long.txt
  grep 98520,6503 Zip4RatesQ42020-Long.txt
  grep 98520,6503 Zip4RatesQ12021-Long.txt
  grep 98520,6503 Zip4RatesQ22021-Long.txt
Here is the output:

  98520,6503,1401,0.06500,0.02480,0.08980,20191001,20191231
  98520,6503,1400,0.06500,0.02300,0.08800,20200101,20200331
  98520,6503,1400,0.06500,0.02400,0.08900,20200401,20200630
  98520,6503,1401,0.06500,0.02580,0.09080,20200701,20200930
  98520,6503,1400,0.06500,0.02400,0.08900,20201001,20201231
  98520,6503,1401,0.06500,0.02580,0.09080,20210101,20210331
  98520,6503,1400,0.06500,0.02400,0.08900,20210401,20210630
Washington also has a lookup page here: https://webgis.dor.wa.gov/taxratelookup/salestax.aspx

That also shows it changing, but not as frequently (and always has it in location code 1401, whereas the ZipRates files have that zip sometimes in 1400 and sometimes 1401).

There is also the short format files (just change the "E" in the name to "C" to get them), which give yet another story. They put 98520-6503 in location 1400 or omit it completely. When they include it, they match the rate from the long files.


Addendum: I took a look at the boundary file that Washington provides to SST (WAB2021Q3MAY27.zip available here [1]). Here's what that file says about O addresses in the 101-199 range of E. Wishkah ST.

  A,20160701,20170331,101,199,O,E,WISHKAH,ST,,,,,,GRAYS HARBOR COUNTY,98520,6503,,,,,01400,53,53,027
  A,20170401,20170630,101,199,O,E,WISHKAH,ST,,,,,,ABERDEEN,98520,6503,,,,,01401,53,53,,00100
  A,20180401,20180930,101,199,O,E,WISHKAH,ST,,,,,,GRAYS HARBOR COUNTY,98520,6503,,,,,01400,53,53,027
  A,20181001,20191231,101,199,O,E,WISHKAH,ST,,,,,,ABERDEEN,98520,6503,,,,,01401,53,53,,00100
  A,20200101,20200331,101,199,O,E,WISHKAH,ST,,,,,,GRAYS HARBOR COUNTY,98520,6503,,,,,01400,53,53,027
  A,20200401,20200630,101,199,O,E,WISHKAH,ST,,,,,,GRAYS HARBOR COUNTY,98520,6503,,,,,01400,53,53,027
  A,20200701,20200930,101,199,O,E,WISHKAH,ST,,,,,,ABERDEEN,98520,6503,,,,,01401,53,53,,00100
  A,20201001,20201231,101,199,O,E,WISHKAH,ST,,,,,,GRAYS HARBOR COUNTY,98520,6503,,,,,01400,53,53,027
  A,20210101,20210331,101,199,O,E,WISHKAH,ST,,,,,,ABERDEEN,98520,6503,,,,,01401,53,53,,00100
  A,20210401,20210630,101,199,O,E,WISHKAH,ST,,,,,,ABERDEEN,98520,6503,,,,,01400,53,53,027
  A,20210701,99991231,101,199,O,E,WISHKAH,ST,,,,,,ABERDEEN,98520,6503,,,,,01401,53,53,,00100
It has the same bouncing around between SER codes 1400 and 1401 that it does in the earlier files. At first it looks like that depends on whether or not it is listed as being in the county or the city, but notice the last 3 entries all have it in the city but it still bounces around.

When it is listed as in 1400 it has state 53 tax and county 027 tax. When it is listed as being in 1401, it has state 53 tax, no county tax, and place 00100 tax.

The statewide component of sales tax in Washington is 6.5%.

Here are the county 027 tax rates, according to the rates file WAR2021Q3MAY27.zip that Washington provides to SST, found here [2].

  53,00,027,0.02000,0.02000,0.02000,0.02000,20140401,20161231
  53,00,027,0.02300,0.02300,0.02300,0.02300,20170101,20200331
  53,00,027,0.02400,0.02400,0.02400,0.02400,20200401,99991231
Here are the place 00100 tax rates:

  53,01,00100,0.02130,0.02130,0.02130,0.02130,20140401,20161231
  53,01,00100,0.02430,0.02430,0.02430,0.02430,20170101,20190630
  53,01,00100,0.02480,0.02480,0.02480,0.02480,20190701,20200331
  53,01,00100,0.02580,0.02580,0.02580,0.02580,20200401,20290630
Matching the rates and the boundaries files by validity ranges, I get for 101-199 E. Wishkah ST odd addresses for 2019q4 through 2021q2 8.98, 8.8, 8.9, 9.08, 8.9, 9.08, and 8.9, which are exactly the same as what I got earlier from the zip+4 long files.

I have no idea why these are not the same as the results using the Washington interactive lookup gives for those address, nor why Avalara apparently gives different results, now why the results using the zip+4 short files differ from the long files.

You might suggest that it was because I was going by zip+4 rather than address, and tax boundaries do not necessarily follow zip boundaries (even when you use zip+4). But with the files Washington gives SST, I'm going strictly by street address so that cannot be it.

Washington also has street address based files in its own format available to download. I've not looked at those. I probably should, to see if perhaps that is where their own interactive page and Avalara are getting data.

I have previously found inconsistencies in Washington's various tax files and interfaces (and reported them). Perhaps this is another case of that. Perhaps I'll report this one, after doing a little more checking around.

[1] https://www.streamlinedsalestax.org/ratesandboundry/Boundary...

[2] https://www.streamlinedsalestax.org/ratesandboundry/Rates/

Edit: I grabbed the street-based rates from Washington's site. Same result as I got from the zip+4 long and from the boundaries and rates files that Washington provides to SST.


As someone opposed to sales taxes, I'd rather the federal government stay out of it.

Interesting. People bemoan that the market in Europe is too splintered and that the whole of the us can be seen as one market. But all these state differences seem to at least indicate that it isn’t that simple.

Interestingly, VAT law is mostly harmonized in the EU and remittance will get even easier starting July where you can declare and pay VAT on cross-border sales to just one entity ("One-Stop-Shop").

The $500,000 threshold is, IIRC, for companies that don't have a 'nexus' in California. As of a few years ago, having a single remote employee in California was enough to create a nexus, causing you to be treated as a California-local company.

This is spot on. It's an interesting program perhaps, but unfortunately a lot of states are missing including California, Texas, Colorado, Florida, Illinois, New York, Massachusetts, South Carolina, and we're not seen any uptake from other states toward adoption either.

I had no idea this was a thing! You should submit it to HN as its own item.

Disappointing that I live in the only non-participating state. Wonder what motivated Colorado to reject this.

Interesting. Why is CO not participating? Looks like every other state is involved to some extent.

CO has a very unique sales tax system: every county, city, and special district can set its own rates, and define taxable (or nontaxable) product categories, and determine the taxability of of those product categories, and even apply special (formulaic) discounts for complying with the tax regime. Plus, a number of tax jurisdictions overlap. And this is the simplified system that the state implemented in 2019 to make things easier for remote sellers in a post-Wayfair world.

And that doesn't even include the roughly 70 home-rule cities which administer their sales tax separately from the state's "simplified" tax system.

For filing purposes, each CO "tax location" is treated as a separate return by Avalara and other sales tax services providers, so the costs can add up very quickly for remote sellers using these services for sales tax reporting compliance: Denver alone has more than two dozen separate "tax locations." Consequently, at my company we use Avalara to compute sales tax for remote sales to CO but file the CO returns ourselves and save several thousand $$$ each month.

Luckily, due to Wayfair nexus requirements, CO sales tax compliance only kicks in at 100k or more in gross sales to CO (not including sales to home-rule cities). Because each home-rule city has its own sale tax system, the nexus threshold is independent for each home rule city; the state has advised these cities to set a threshold of $100k to avoid nexus-related litigation that could result in a bright-line rule setting an undesirably high threshold for nexus.


Because Colorado has the most garbage sales tax regime in probably the world.

I was lucky to be part of the beta for my SaaS (https://turnshift.app) and I must say this new feature simplifies things A LOT.

Especially as a EU business owner, I previously had to sync every VAT tax rate possible, use a complex workflow to know if a customer needed to pay taxes or not, link tax rates to customers, and create taxes reports for my accountant. Stripe tax does all of that automatically, based on the customer full address and VAT numbers.

Here's a twitter thread of everything you had to do previously: https://twitter.com/vvoyer/status/1347488977738149888

PS: Yes there were other services (Paddle) providing this (and much more to be honest), but the Stripe API and customization options makes it my go-to solution for integrating payments.


    report taxes. Stripe tax does all of that
It doesn't say they file the taxes for you. "Speed up filing and remittance with comprehensive reports" means they will help you with it, but not do it for you. Later on the website : "Stripe reports surface all the information you need for each filing location, so you can easily file and remit taxes on your own, with your accountant, or with a preferred partner.

US filing partner TaxJar EU filing partners Taxually Marosa"


Thanks, I updated my comment.

> It doesn't say they file the taxes for you

Yay for automation, but is using third parties to file taxes not open to fraud and potential error (if you don't do it yourself?)


Literally all companies pay other people (accountants, lawyers) to do their taxes and in many cases they are third parties so no, that is not the case.

https://www.irs.gov/businesses/small-businesses-self-employe...


Not literally all. I can name several small businesses which do their own taxes.

-—> small <—-

Yes. The comment I responded to said "literally all companies", not "literally all large companies".

They're just using the word "literally" in its ever more popular sense in which it does not mean that it really does apply to all companies.

For example, according to Oxford dictionary https://www.oxfordlearnersdictionaries.com/definition/englis... "used to emphasize a word or phrase, even if it is not actually true in a literal sense" or Merriam Webster https://www.merriam-webster.com/dictionary/literally "used in an exaggerated way to emphasize a statement or description that is not literally true or possible" ; in modern usage, "literally" can be it's own antonym and mean "not literally". Language is fun! :)


The redefinition of "literally" to mean "not literally" is an abomination and should not be tacitly accepted.

fwiw I upvoted you because I should have wrote "a vanishingly small amount of businesses, many who are probably screwing things up pretty badly"

I suspect that the majority of businesses are small enough that their taxes are trivial and pretty harmless -- at least if you weight by count. If you weight by size -- sure, most business is big business and has complex taxes.

I pay TaxJar to prepare and file my sales tax returns for me.

Stripe just acquired them in April.


Gusto files your taxes for you.

Yeah, but they would lose their license and customers and be sued for damages. The world is not a libertarian / individualistic wild west.

I was part of the beta too for my education site (https://learnetto.com) and I couldn't agree more - Stripe has done a stellar job.

The downside is of course that Stripe takes over more and more of your important infrastructure. A question should always be how to include several suppliers and/or how to change supplier in order not to put all in your eggs in a single basket.

This sounds a little like the big sites I've worked on that spent immense amounts of money on being database-agnostic, "so we can switch from Mysql/Postgres/Oracle to $other if we want".

Nobody ever wanted to switch; the expertise in using one provider created immense inertia. And even when a few folks (fans of $other working side-of-desk) tried to make a proof-of-concept swap, it turned out that the code was anything but agnostic and dependent on the first provider it was built for in pervasive and fundamental ways.

So, too, with service providers and partner businesses. Spending time/money on being able to switch suppliers and keeping all your eggs from being in one basket is a waste of time: you won't switch voluntarily, and if you ever have to switch involuntarily it'll still be about as difficult as it would have been if you hadn't prioritized redundancy/diversity.


At a minimum, implementing an abstraction layer around all external services really is software development 101.

For some services it's also not just being able to switch, it's having more than one used in production. If you manage that then switching is no longer a problem since it's already implemented! That's important for key services.


The cost of letting Stripe do all the work than moving over to another provider is extremely costly and can damage sales.

Unless your provider really sucks, it's always important to evaluate carefully and ideally stick with them unless it is really that bad.


> The cost of letting Stripe do all the work than moving over to another provider is extremely costly and can damage sales.

Yes, that's exactly my point: At some point you are completely locked in with a single supplier that holds your entire income stream and perhaps even more than that.

Ideally (easier said that done, I know) you want to have at least 2 suppliers for any key piece of infrastructure as early as possible and to avoid letting a supplier 'expand' the number of tasks they do for you too much.

The latter seems to be Stripe's strategy: They start with payments then expand step by step in everything related et even in things like company incorporation.


I imagine that most businesses have bigger risks to deal with than this, especially in early to mid stages (where Stripe seems to target).

Perhaps. You should always keep that in mind, though, and avoid building your system tightly-coupled to any single supplier.

Do you feel like the value is worth with the fee Stripe is charging?

YES, considering the only best competitor in this space Paddle takes 5%.

Taxes is the reason why in the past most EU/UK businesses go to Paddle. Stripe's Tax feature now saves people who were considering Paddle a lot of time now.


Here's some current Stripe UK pricing, confirmed on their site today.

Baseline of 2.9% + £0.20 for international card payments. (It's reduced to 1.4% + 20p for European cards.)

Add 2% for currency conversion. The exchange rate used is stated as "the daily mid-market rate provided by our service providers".

Add 0.5% for Billing if you're using subscriptions.

Add 0.5% more if you're using this new Stripe Tax functionality.

That is significantly over 5% for a typical SaaS or merchant selling digital content online, making international sales in multiple currencies.

Given that merchant of record services like Paddle are providing functionality far more comprehensive than Stripe Tax appears to be, they're still going to be attractive for smaller merchants compared to the more traditional PSPs like Stripe.

It's probably worth pointing out that while the EU has a long track record of making VAT difficult for everyone, plenty of other countries around the world and even some smaller regions seem to be jumping on the bandwagon lately. If all of these governments start attempting to enforce their local laws extra-territorially (leaving aside any questions about the legality and/or morality of doing so for this discussion) without also introducing reasonable de minimis thresholds to avoid grossly disproportionate compliance costs for negligible extra tax revenues in low volume situations, the situation could get very messy.

If that does happen and businesses are forced to comply with all rules globally regardless of actual sales volumes, I don't see how the model uses by traditional PSPs like Stripe has any chance of surviving. Every small business will have to sell via intermediaries like Paddle to shift the tax responsibilities to a larger business with the resources to deal with it, and pay whatever premium the market decides that justifies on all affected international sales.


The tipping point is the 2% for currency conversion, but keep in mind that this is happening either way on Paddle as well, just not going to Paddle. Paddle takes 5%, then the entity that converts from USD to your currency (Payoneer / wire transfer bank) takes the 2% or more. Stripe calls it out clearly and gives you your money in your own currency.

If you're selling a B2C service (so the really horrible tax rules apply) for say £10/month, that extra £0.20 is another 2%. Stripe's total cut for an international sale with currency conversion is then nearly 8%, even if you don't use any of their other services with their own extra costs and you never have any refund or chargeback costs to amortize.

Stripe is crazy expensive these days.

(There are other parts in the fees charged by other services as well, but those also aren't like for like comparisons. I'm just saying that 5% as a baseline wouldn't necessarily be that high compared to services like Stripe.)


Paddle uses Currency Cloud for that, which charges a true mid-market rate and a very low transaction fee. It's what Transferwise uses behind the scenes.

They use whatever to convert all the currencies of the world into your base currency, usually USD/EUR. Then they transfer that to you, and you pay more conversion fees if that’s not your actual base.

I sell in USD, and then once a month they transfer my sales to me using Currency Cloud. At that point it gets converted at the mid-market rate + 0.25% IIRC. Since they don't actually make international transfers using banks, that amount is what actually arrives in my bank.

I believe the currency conversion charge can be avoided by only charging your customers in your own currency or another currency you have a bank account for. I rarely see a small merchant that takes more than one or at best two currencies.

That'd leave you with 20p + 3.9% (international) / 2.4% (European). Compared to Paddle's 5% + $0.50 that could be a good deal depending on how much of your volume happens in Europe.


I believe the currency conversion charge can be avoided by only charging your customers in your own currency or another currency you have a bank account for.

It can, but then your customers get hit with varying exchange rates and potentially high conversion fees on their side. This will not make you popular with your international customers, at least the ones who didn't already back out when they saw a foreign currency anyway. Depending on which research you read, the rate of lost conversions due to lack of local pricing could be as high as 50%.

Within the overall landscape of payment processing options, Stripe looks trapped in an awkward middle ground now.

Above them are the merchants of record. Including currency conversion, international sales using Paddle seem to cost 7% + 35p at current USD/GBP exchange rate and their standard published pricing. But for that, you get real tax compliance.

Then we have Stripe, coming in at 5.9% + 20p (4.4% + 20p for European cards). Even with Stripe Tax, you're missing much of the essential functionality for global tax compliance and the reassuring liability shift, so that extra 1.1% + 15p or even 2.6% + 15p would be the easiest sale since bottled water in a desert to a lot of merchants.

Further down the price spectrum, we have services like GoCardless that are offering direct payment schemes rather than cards (duh) but for a fee of only 2% + 20p including currency conversion. You don't get any built-in tax support here, so it would be fairest to compare with Stripe at 5.4% + 20p or possibly 3.9% + 20p, but that's still quite a difference. And while you have to do your own tax compliance as with all payment processors using this model, you do get other benefits, notably in much improved reliability of collecting payments via direct payment schemes compared to card payments.

I wonder whether Stripe's medium-term goal might be to establish its own merchant of record service, and Stripe Tax in its current form is just the opening move. Otherwise, it doesn't really make sense to me as a strategy. But I have no inside knowledge on this and there are several Stripe people around who probably do, so no doubt if they want to elaborate at this time they will.


I agree that the convinces of Paddle is hard to beat, especially for sole developer and small companies. Liability shift being indeed very powerful. But I also think the percentages thrown around are too sinistic. If you make ~5 figures a month in revenue it becomes very doable to hold a Euro and USD bank account in addition to your local currency, likely covering a fair amount of your customer base. Suddenly your cost are significantly lower (at the expense of now having to manage multiple accounts)

Sure, you can hold accounts in multiple currencies. However, if you're a sole developer or small business bringing in low-six-figure revenues, you're probably going to want to take much of that revenue out of the company to pay its people on a regular basis. That in turn probably means transferring it to your primary bank account and converting the currency to your primary currency in the process, which will incur a conversion cost again. So holding accounts in several different currencies mostly helps if you expect to both bring in and pay out significant amounts in those same currencies, avoiding a round trip of conversion to and back from your native currency.

True, but wise accounts make it easier and also cheaper than 2% that Stripe charges.

Indeed. That seems to be what GoCardless are using now, and as mentioned above, they work out much cheaper than Stripe for international payments with currency conversion.

Except for the vast majority of countries supported by Stripe, you can only be paid in your local currency.

Australian companies can only get paid in AUD. I've been getting killed on this for years, Stripe keeps saying "soon" :(


Stripe also offers interchange plus pricing, but you’ll have to badger them for it… if you’re selling in Europe it can work out much cheaper, but it depends (eg amex would cost you much more).

Also the exchange rates can be avoided by setting up bank accounts with different currencies (eg transferwise —- now wise). This alone saved us a bundle.



We are. If I understand correctly also the UK, where I believe GP is based.

With this new Stripe solution, do you still have to register for licenses to collect tax everywhere and remit the sales tax to various US states and foreign governments? Unless I misunderstand, that still sounds prohibitively onerous for anyone working as a solo dev or very small team..

Good question! Today you would still need to register yourself, however we tried to make this as easy as possible in two ways:

1) We monitor your transaction and compare them to local thresholds so you know where/when you may need to register: https://stripe.com/docs/tax/set-up#monitoring-your-obligatio...

2) We provide documentation/links to the exact sites to register: https://stripe.com/docs/tax/registering#list-of-state-and-co...

In the future though we'd love to also offer registrations on your behalf, this is just the beginning!


This is a really useful toolkit. Going much further might make you into the actual legal entity, which could have consequences I don't fully understand (but is perhaps Stripe's plan?)

Not sure how it works in the US but in the EU you don't have to register anything. Just keep tabs of what VAT you collected for what country, and then pay accordingly afterwards. No licenses needed.

Last time I looked into this, it seemed to me like in the US you would need a separate license for each state you collect sales tax in (before collecting any tax)... and naturally, each state has a different licensing process, and some charge fees to register. For small independent projects, it seemed like kind of a nightmare.

You don't have to collect tax for states you don't have a presence in. They have no jurisdiction outside their borders.

That used to be the law, but is no longer as of 2018:

https://en.wikipedia.org/wiki/South_Dakota_v._Wayfair,_Inc.


A bad ruling. To let it stand, the more reasonable interpretation is that the purchaser has to remit sales tax to their own state. But it may not stand on further challenge. For example, why should the state the items are leaving not be entitled to sales tax?

The law already was that the purchaser should remit use tax to the state for purchasers from out-of-state vendors.

But compliance was basically non-existent; most people didn't even know that they owed use tax on such sales, much less what rate would apply. Sales tax is basically use tax, but with the burden of compliance placed on the seller.

As for why the sellers' state is not entitled to sales tax: in the old-time days, pre-Amazon, this was how many (but not all) tax jurisdictions determined sales tax. (For example, CO's sales tax regime pre-Wayfair used to use the seller's address to determine tax rates.) But the rise of Amazon and online sales meant that sales tax would go to a few jurisdictions where the sellers were located, rather than be spread out where the buyers were located. As sales tax pays for things like roads, etc., that these remote sellers used, many jurisdictions thought this was unfair, and moved to change sales tax sourcing to destination-based sourcing (i.e., to taxing based on the customer's location). And in the Wayfair decision, SCOTUS said this was acceptable. (At the national and international level, destination-based sourcing has been the law for decades, and has been part of America's tax treaties dating back to at least the 1970s.)


I was just wondering about this. I recently purchased something online, and when I got the email receipt it had all the state and county and city level tax breakdown. I thought to myself, was this tax being charged due to the billing or shipping address? Apparently it was the shipping address when I asked.

> But compliance was basically non-existent; most people didn't even know that they owed use tax on such sales

As a business owner, I would ask myself “how is this my problem?” If a stare has a problem with residents not complying with a tax, I am not sure why a business in another state should care. If I buy a product from China, are they required to collect sales taxes for Montana? Of course not. So not sure why a business located in a sovereign US state has any obligation to follow laws of some other state in which they don’t operate. It’s the purchaser that has the relationship with their local state, not the seller.

The Wayfair decision was ridiculous. The Quill decision it overturned was the correct answer in terms of interpreting the Interstate Commerce Clause. Interestingly, Amazon and other large e-commerce companies don’t have a problem with collecting sales taxes everywhere because their compliance costs are trivial as a proportion of revenue.


This is my point.

It happens with brick and mortar stores, too. The MO/KS border has a large population buildup. It's totally normal to shop in the state that has the best tax rate for your goods. If you apply the ecommerce logic to this, you need to have people show ID at stores so the store can apply the right tax rate.

It seems to me the seller's state has just as much claim to sales tax as the buyer's. The seller is potentially making use of business development credits etc, etc, originating in their state.

This is an issue that falls under the federal government.


No, you guys are both misunderstanding how the sales sourcing works: it's the address where the sale is deemed to have taken place.

For brick-and-mortar sales, that is the physical location of the store: you will be taxed the appropriate rate for the address of the store. Note that this includes includes online orders picked up from a store location, and in-person orders even if the goods are not actually physically located at the store, such as if they are shipped from a separate warehouse to the store. However, delivery orders might be subject to different rules, depending on the state; some states use the address provided by the customer as the location of the sale, so that in-person sales delivered to out-of-state addresses might not be subject to sales tax.

For online sales, the sale is (now) treated to have occurred at the address provided by the buyer for delivery, because that is the most expedient way to determine address. The EU has made waves about using IP addresses or geolocation to determine the actual location of the buyer at the time the order is submitted, but AFAIK both proposals are DOA due to infeasibility.

It seems to me the seller's state has just as much claim to sales tax as the buyer's. The seller is potentially making use of business development credits etc, etc, originating in their state.

No, the seller's state doesn't have a claim to the sales tax, because sales tax is a tax on the customer not the seller. It is simply collected by the seller because the compliance is easier to enforce. (Caveat: in Hawaii, the GET is a tax on the seller that can be passed on to the customer.)


I understand the current rulings. I am saying they are erroneous. We (who I replied to and myself) understand what is going on. It is not consistent.

You are fundamentally misunderstanding that a sales tax is a tax on the customer not on the seller. This is because sales taxes are fundamentally use taxes with the compliance burden shifted from the customer to the seller.

You can argue against reality all you want, but it won't change decades of history, nor will it change how the world actually works.


> If I buy a product from China, are they required to collect sales taxes for Montana? Of course not. So not sure why a business located in a sovereign US state has any obligation to follow laws of some other state in which they don’t operate.

Actually the same rules apply to both. See https://blog.taxjar.com/international-sellers-deal-sales-tax...


My purchases on AliExpress have been being charged my state sales tax for quite some time.

Luckily, my home state of Virginia has exclusions. From what I understand, until congress acts, more lawsuits need to happen from companies challenging states to pay these bullshit taxes. VAT is also a terrible burden.

The trend in courts and legislatures, both in the US and in Europe and the ROW, is toward customer-based tax sourcing and away from seller-based sourcing.

You can thank Amazon for abusing seller-based sourcing for this shift, though it has actually been a decades-long process that began before most people on this forum were born. Amazon simply accelerated the transition.


I think due to South Dakota v. Wayfair, states now have more power to define what constitutes "nexus"... so there are all these special rules and thresholds now to keep track of (different for every state) that define whether you have economic nexus and need to collect sales tax there. If you hit the threshold and/or other rules apply, you're obligated to collect sales tax... but of course you can't do this until you have secured a license in that state. This was my read on the situation, but if I'm missing something definitely let me know.

How do they keep track of who you are? I presume you need a VAT ID of some form? (From https://en.wikipedia.org/wiki/VAT_identification_number#VAT_..., it looks like they’ve crafted it so that many countries’ business numbers can be turned into VAT IDs painlessly, e.g. Canada’s work direct, Australia’s you prefix with a two-digit checksum. I note the conspicuous absence of the USA from the list. I have no idea about US tax.)

Also wondering about this. Having a one man band b2b only saas, in EU. Have few customers in US to whom I just send an invoice with no tax added. This is what I heard from long ago was how you do.

Have never registered any taxes abroad in any country. For EU customers I collect VAT no and do the quarterly report but for all other countries I’ve done nothing. I have basically been doing this wrong then?


As long as you are small enough, that's what everyone does. Pay taxes in your own jurisdiction, ignore foreign taxes.

At some point you may reach a limit where you need to file taxes in other places as well.

But as a one man operation that sounds unlikely.


That's the reason I use 2Checkout (formerly Avangate). I can issue one invoice a month, in my own currency. That saves a lot of work and aggravation.

Do you know if Paddle files taxes for you? And just send you 1099? Or it is similar to Stripe Tax, they just collect and you have to file taxes?

I use Paddle, they do file 99% of your taxes for you.

In effect, they sell the product to customers, and handle all the tax on that side, for every tax regime in the world.

Meanwhile you act as a company with a single B2B client and one invoice a month (covering Paddle's net sales minus 5%) instead of N invoices. They send you an email every month with your 'reverse invoice'. As accountancy goes it's extremely easy, but you do need to do the basic tax filing in your local jurisdiction.

That 5% includes all the processing fees, they also have a bunch of useful subscription infrastructure, and they handle customer support for billing issues, which tends to be a substantial percentage of issues as you get larger.

So far they've been great, and doing nearly zero accountancy is worth a lot of money to me as an indie dev with a digital product (where you need to know a lot about local digital taxes nowadays). That said, would I do the same at the beginning if this existed a few years ago? Hard to know, but this doesn't look so compelling that I'm likely to switch now.


> Meanwhile you act as a company with a single B2B client and one invoice a month

There were some changes in this area recently. Paddle is now providing you two reverse invoices each month, one for sales in the USA done by Paddle.com Inc. and one for sales in the rest of the world done by Paddle.com Market Ltd.

For the accounting purposes you have two B2B clients (belonging to the same group). You still receive a single wire transfer though.


How do you find working with Paddle? They've been on our shortlist for a new project and we've heard only positive things from people who actually use them. However, their terms could make any lawyer or company officer who actually read them visibly wince, and so far that has prevented us from engaging with them despite their clear advantages over the traditional payment services.

I've been using Paddle (and thus not worrying about VAT) for years now. They're mostly pretty good, although I use a very limited subset of their functionality, I basically just use them as a payment gateway. Their support is responsive and helpful, especially in the last year or so, and I haven't had any downtime to speak of. They don't accept all the payment methods that Stripe does, but enough for me.

There are a couple of pain points. Their invoicing is just a hot mess, if invoicing is a requirement for you I'd evaluate that very carefully. And they don't really have any sort of proper test system, which is pretty unbelievable. I do most of my testing in production using discount coupons, but 100% discount coupons can only be used with orders for a single item, so I can't test orders for 10 licences in any very useful way.

I dealt with their contract conditions by just ignoring them and crossing my fingers :-)

Still, all that said, there's nothing in this offering from Stripe that would tempt me to change. I'm also lucky in that I managed to negotiate a good rate from them when their model was switching to B2B (from Mac app sales, which the App Store killed). If you have any further questions, feel free to email me.

Edit: one other thing I like is that they use Currency Cloud to transfer funds to me, which give a much better exchange rate than a simple bank transfer and means that my local banks don't stiff me to receive a foreign transaction.


> they don't really have any sort of proper test system, which is pretty unbelievable

They fixed this a little while back. There's now a fully independent sandbox environment: https://developer.paddle.com/getting-started/sandbox


Wow, how did I not know that? Thank you!

Thanks, there's lots of useful info there.

Are there some specific terms in their legal bits that you're concerned about?

Personally, they've mostly been very good. The product works, it was very easy to set up and it does everything out of the box, and it's made sales tax & accountancy almost completely disappear.

I have occasionally run into issues or bugs, and their API is a bit of a mess, but nothing show stopping and their team has been reasonably responsive and sorted everything out very reliably. That's noticeably got better & faster recently, I think they're beefed out their support team a lot in the last year or so.

If you're selling a new product as a substantial business, I think they're good but there are other options to look at too and there are tradeoffs (5% is high, you could probably do your own customer accountancy etc in house).

If you're a solo dev/small indie, or just getting started though I think it's a no-brainer. It's just so much quicker & easier than doing everything yourself.


Are there some specific terms in their legal bits that you're concerned about?

Quite a few, but to give an example from high on the list, it appears that a SaaS company would warrant that software sold through Paddle is always bug-free, accept unlimited liability via the related indemnification requirements if it isn't, and yet have no right participate in or even know about any relevant process if something goes wrong. That's a toxic combination and hardly looks like a healthy basis for a mutually beneficial business relationship.

Other concerns related to the considerable flexibility Paddle appear to give themselves in terms of how they represent, price and provide access to whatever is being sold, again apparently without necessarily requiring the consent or possibly even the knowledge of the underlying provider. We're unclear about how much this might be necessary because of merchant of record legal model, but it has little to do with what we'd actually want to use Paddle for or why we'd choose them over other services for collecting payments.

For context, this is a new business but run by a team who have collectively founded multiple others before. Several of us are very much over wasting time and effort on the mechanics of taking money from our customers and complying with whatever rules accompany that. Obviously fees charged by a payment service do matter, but a moderate difference there is still insignificant to us if the service we use can offer enough flexibility for our needs and easy integration, and otherwise takes on as much of the mechanical implementation and regulatory burden as we can shift.


Paddle is fundamentally different to Stripe. As you said they a merchant of record. Your customers purchase via Paddle, manage the subscription etc via them. Disputes would be via them too. Something to bear in mind.

Sure, the model is different, but that still doesn't make signing up to an impossible promise with unbounded liability when you inevitably break it a good idea.

What happens if Paddle are faced with a customer who is getting snotty about a bug and threatening litigation in an expensive jurisdiction? Paddle apparently have the right under their terms to settle that dispute on whatever terms they wish and then pass the entire cost on to the developers. There doesn't appear to be anything requiring those terms to be reasonable nor anything close to what the developer themselves would have had to offer in their own home jurisdiction or if they'd been selling directly to the customer on reasonable terms. As far as we could see, Paddle don't even have to notify the developer that any of this is happening, they can just send the bill at the end.

If anyone from Paddle is reading this and would like to explain publicly why that isn't an existential threat to every SaaS business using their service and what their terms actually mean, that would be very interesting to read. Maybe something like the above scenario would never actually happen. As I mentioned before, I've heard nothing but positive comments about Paddle from various people I know who actually use it. But in that case, there's no need for such one-sided terms, and it's better for everyone if the legal documents say what you really mean instead.


I've been happy with them so far, although I only have a few customers. The backend dashboard feels a little MVP but everything works well. The checkout flow is also hosted so you just embed that into your app which is nice.

Thanks for the first-hand insights.

Interesting insights into the TOS of Paddle. Have you compared the TOS of Paddle to FastSpring?

Yes we have, though the terms for vendors that are linked from the main terms page on the FastSpring website don't seem to be the correct ones for vendors in the UK so our current assessment is only provisional.

The FastSpring terms don't appear to create the same risks for us that we identified in connection with Paddle's terms as I mentioned above.


Paddle and FastSpring (I found their support to be more helpful than Paddle's but they charge even higher fees), the two solutions commonly used in that space, act as Merchants of Record. Since you are not selling directly to your users you don't have to file the corresponding taxes, just the ones that correspond to the transactions between Paddle/FastSpring and you. But I'm not an accountant and they may change their operations in the future so don't rely on this comment alone.

I thought Avalara was the leader in this space. What is their pricing, I can't find it on the site.

Personal experience from using Avalara for six months: - Returns were processed via a queued batch job. It could take between 1-3 hours after submitting to process a return. Avalara had a countdown clock on their website showing the estimated hours/minutes remaining until the return would get processed. I have seen the countdown clock show 1-3 hours plenty of times (quite frustrating). This was the case 6-12 months ago. Perhaps Avalara has fixed this issue since.

- The 1-3 hour wait made filing quite difficult when the original return had an error. Submitting a second return to cancel the first required another 1-3 hour wait. Then submitting the final (third) return required another 1-3 hour wait. Filing one state easily turned into a whole day ordeal if there was an error.

- Support from level one/two staff for difficult tax questions did not help. Level one/two staff gave a vocal repeat from the online help guide. Level three support was acceptable however.

- Tax returns filed with Avalara are done via a rather cumbersome spreadsheet. Don't expect someone to hold your hand. Rather, it requires many trial and error submissions to figure out how to make the Avalara engine work.

Note: A basic "shipping product" business like Amazon/Walmart would do fairly well with Avalara. However, a company that does complex construction projects will have challenges. We ended up reverting to filing taxes manually.


What is their pricing, I can't find it on the site.

Whatever it is, reading reviews of Avalara suggests it's beyond the level smaller businesses can afford and has also been increasing dramatically from one year to the next for some time.

Avalara have a strong web presence because they've always been good at presenting key information like current tax rates and forthcoming changes. Their content marketing is excellent. But as soon as you look for more details about anything they offer, you seem to be straight into "enterprise contact-us sales process" mode.


Avalara is expensive. It works out to being cheaper if you have sufficient scale, but it's generally pricier for small businesses.

However, that is because you're paying for their customer support, and Avalara customer support is very good. Every issue we've had has been dealt with promptly, including issues where Avalara misfiled a return. (Long story short: they owned up to the mistake and corrected it with the state without any additional cost or penalties to us.)


What about invoicing to the customer?

AFAIK Paddle solves that too but Stripe doesn't.


Paddle does have a solution to this but it is what I would consider to be in eternal alpha - it's functional (barely) but it drives me insane every time I have to use it.

I think you still need to collect VAT ID on your website and associate it to a stripe customer

Nope, no need! Tax ID is validated when you accept the payment: https://stripe.com/docs/tax/checkout#create-session.

Wao! Does it works for metered-usage plans too?

Precision: if you're using Stripe checkout only. On a custom integration you do need to get the customer VAT ID and add it to your Stripe customer

So what are the advantages of Paddle?

Most importantly, they become the merchant of record. In other words, they're a separate legal entity reselling your product to your end customer, and therefore they are the ones who deal with almost all of the corresponding tax and legal responsibilities. You then deal with them through a B2B relationship, in which they give you you the collected revenues minus their fees every now and then, and you provide your product to the customers they've sold it to in return. Your own accounts and tax responsibilities are dramatically simplified as a result, though typically with a merchant of record arrangement (with Paddle or any other) you trade that off against some loss of control and higher fees.

They support PayPal

Honest question: can somebody enlighten me about Stripe's appeal? I am not an user (until recently they weren't even available in my country) but I used ShareIt (now Digital River) 20 years ago and Avangate (now 2checkout soon Verifone) in the past 15 years and they both:

- had a much larger international presence, with localizations and everything

- had sales taxes, VATs etc computed from day one

- had cart (not sure about ShareIt though) & API

- integrated countless payment gateways: from credit cards to purchase orders, wire transfers and even PayPal

How comes Stripe won even if they arrived much later on the market? I believe their pricing structure was not very far from the competition. What did they offer to attract users even though they lacked such important features?

I want to learn.


The developer experience and ease and speed of integration are second to none. They managed to take a commodity service performed by many incumbents and make it so effortless that it blows away the competition.

Yes, I heard that (couldn't test it myself). The integration for Avangate for example was a proof-of-concept PHP file and a couple of docs explaining the CGI parameters. Not great but not that horrible either.

But were those so incredible that it made up for the missing features? I mean if it was me I wouldn't implement the sales tax myself in a million years, no matter how nice the experience and integration was...


Stripe came up in an era when nobody in the US worried about taxes, generally speaking. That's changing now.

Any good references on this? Curious

Specifically on the SaaS front, taxability has been murky and there's not a single standard across the US: https://blog.taxjar.com/saas-sales-tax/

A couple of years ago, internet sales tax across state lines started being enforced. I think there was also a temporary moratorium to build up ecommerce while in its early stages. This case was related:

https://www.thetaxadviser.com/issues/2018/sep/supreme-court-...


It's pretty weird hearing anyone talk about CGI parameters these days, so perhaps that should also tell you something?

That was 15-20 years ago, integration today has evolved, of course...

Disclaimer: I now work at Stripe but the following was purely when I used them as a user:

Stripe targeted developers from day one and made it extremely simple to get up and running (literally seven lines of code for a working payments system) and they documented their api very well.

Then they added on a lot of stuff that made me (as a user) happy, like paying out to my bank account a lot more quickly than the competition, adding recurring subscriptions with a few more lines of code etc.

Basically, their systems just worked out of the box and were more polished than others that I used.


If I want to know how much Stripe will cost, I can visit Stripe's webpage and see all the fees laid out. It doesn't tell me "Talk to sales", which is common in the payment/tax calculation business.

Stripe's documentation and API integration was so simple compared to Paypal and others.

I believe that. But on the other hand you had to implement sales tax - that seems to me a few orders of magnitude more complicated. Was it worth the tradeoff maybe?

Sales tax is not a "I need this at launch" feature. Many companies start out in a single market where you can just hardcode the tax rates if you want, and worry about that later (and then the engineering hours to add sales tax etc. are probably not a threat to your existence).

Gotcha. My products were addressing the global market from day 1 so the ability to automatically send an invoice with a correctly calculated sales tax to buyers from any country on the planet seemed vital. Let's also not forget about collecting and remitting said tax to correct tax authorities...

There were companies that filled that gap, like Taxjar (now acquired by Stripe)

Banking in the US is at least a decade behind the rest of the developed world. Bank to bank transfers, credit cards, etc. etc. are all like banking in Australia in the late 90s.

So for those in the US, Stripe is amazing. For those of us outside the US, it's just like all the other options we've had for 10+ years (as you said)


Besides for the extreme ease of documentation (which is getting a little harder now that there's so many different services), Stripe gained a lot of traction at the start.

Stripe was one of the first credit card acceptance companies with $0 monthly fees. I was paying a merchant account monthly, then authorize.net gateway fee, then an extra $20 to authorize.net to store tokens. Then the per-card fees were somewhat opaque with every card (qualified vs non-qualified) having different pricing.

With stripe, it became much lower risk: pay a set fee for each transaction. No monthly minimums.

Many of the credit card companies have moved to this model, but it was rather cutting edge and seemed much more "fair" for a commoditized gateway.


I have to say that when I first evaluated Stripe I was comparing it to things like authorize.net. I haven't meaningfully looked at the other available options since. Stripe is easy and known and I haven't gotten org pushback about it. So maybe just ignorance?

Thanks for sharing these options.


This is so on point. About a year ago I was thinking of opening a company and selling digital products with Stripe in Japan (where I live). They offered a quick free call to answer my questions, and I did so. I am not fluent in Japanese so any help I'm offered I take it, and I wanted to know how many other troubles I could face at this endeavor.

All my questions were answered promptly and greatly by them, and I was getting more and more convinced to do it. Until I asked, "Stripe handles sales taxes, right?" and the answer was "no". They gave me a brief overview of how that works though. Let me tell you I know why you don't see an "Amazon of Japan", apparently in here I'd have to calculate the sales taxes for every country where my products are sold through agreements of Japan-{said country}. Some countries don't even have agreements like Brazil so they are in a gray area.

It seems like Stripe Tax might be a game changer for this specific situation! I'm not ready right now personally/professionally to try to do the company, but let's see in 6 months - 1 year. I am so jubilant!

PS, this is from a quick conversation I had ~1 year ago, so some small details might be fuzzy/outdated/incorrect. Ofc this is no legal or accountant or any kind of advice, just my experience.


> Let me tell you I know why you don't see an "Amazon of Japan", apparently in here I'd have to calculate the sales taxes for every country where my products are sold through agreements of Japan-{said country}. Some countries don't even have agreements like Brazil so they are in a gray area.

AFAIK this is true for any other country, not just Japan. If you're in US, and you want to sell and ship products outside of US, you need to take care of the sales taxes and customs for each of the countries you ship.

Or you leave the burden to your customers, but they might not be happy to have to pay expensive custom to the mailman to get their package.


Apparently it's either not a requirement or not so strongly enforced in the US and EU as it is in Japan, or that was my understanding from the conversation.

Update: searching a bit and reading about the EU sales taxes, there are few rules but overall it's pretty clear you either don't pay or pay local sales taxes even for international sales for low-volume B2C sales (sorry it's Spanish): https://www.carrilloasesores.com/post/iva-de-ventas-por-inte...


In Canada, it is a requirement to self-assess GST on purchases you make online. When you buy something online, you're supposed to fill out a form and mail a cheque to the government for the GST you should have paid on it. That being said, this is completely unenforced as well as unenforceable. Also, if you ask basically anyone in Canada they probably would have no idea this was a rule, but the rules are the rules.

https://www.canada.ca/en/revenue-agency/services/forms-publi...


I have a nano sized business to cover some server costs in Finland. Here are the EU rules as I understand them:

* Selling goods

  - If selling to private persons in European Union fiscal territory (EUFT), add 24% (Finnish VAT).

  - If selling to businesses in EUFT, no VAT.

  - If selling to anyone outside EUFT, no VAT, but you may be liable to collect and pay VAT to the customer's country's tax authorities.

  - Note that there are separate customs rules!
* Selling electronic services

  - If selling to private persons in EUFT, you need to register to the customer's country's tax authorities and add the customer's country's VAT, and then pay it later to the customer's country's tax authorities. EXCEPT if you only have an office in one country and you are selling to another EUFT country, and you only sell <= 10,000 € worth of services, then you can use your own country's VAT like normal.

    o Or you can register to so called VAT MOSS (Value Added Tax Mini One Stop Shop) where you use the customer's country's VAT but you don't need to register or pay to their tax authorities, instead you send a quarterly report to your own country's tax authorities about all the sales you have done, then you pay them a calculated sum, and they will divide the paid VAT to all the countries based on the sales. Of course there is now a new VAT OSS that is somehow different from MOSS.

  - If selling to businesses in EUFT, use reverse VAT (buyer is liable for VAT).

  - If selling to anyone outside EUFT, no VAT, but you may be liable to collect and pay VAT to the customer's country's tax authorities.
Now I'm not a tax lawyer, so this is all just my best understanding based on our tax authority's website. I just wanted to get some money back to pay for my ~20 €/mo server costs, and I had to learn all of this. I will be very interested in what this Stripe Tax can do to remove my headaches. :) Of course, since my revenue is so tiny (and thus the money I bring to Stripe), I can't access all of their services AFAIK. And I'm mostly one chargeback away from losing major revenue due to the 15 € penalty. :D

EDIT: Turns out I have no idea how to format lists on HN.


You don't need to charge VAT unless you hit these thresholds:

https://www.avalara.com/vatlive/en/eu-vat-rules/distance-sel...

Which at the lowest end is € 35,000 per country.

Countries like the UK for example have a VAT threshold of £85,000 for businesses located inside that country.

This is one of the problems of online marketplaces - they have VAT added to them, even when the individual (small) business doesn't need to pay it.

VAT is a big compliance burden for small businesses which is why every country has revenue thresholds under which you don't need to charge it.


Unfortunately, almost everything you're talking about there is about selling physical goods. The rules for electronic sales have been completely different for quite a few years now and are a labyrinthine mess that makes even professional accountants frustrated and national tax authorities screw up the most basic processes. In most cases, they also don't have any minimum thresholds at all, and the few concessions that have been made are quite recent.

I just wanted to mention, our invite-only starts today, but we're working on making Stripe Tax available to all very very soon!

Either way, we will be reviewing and onboarding users as quickly as possible after you submit your interest!


How long is soon? I'm asking as I'm in the middle of building a saas. I might get to payments functionality in about 2-3 weeks if all goes well. Should I wait or register interest?

Shoot me an email with your account ID and I'll make sure you're enabled by the weekend! kmoriarty@stripe.com

That's what I call good customer service. :)

I understand that from the 1st of July, the electronic services section will expand to all goods, potentially with some thresholds, so you should charge the VAT rate for that particular item at the customer's home country and submit that to the Finnish tax authority (under the OSS scheme).

These are the thresholds for VAT going into effect on July 1st:

IOSS (EU) <150 EUR

VOEC (Norway) <3000 NOK

HMRC (United Kingdom) <135 GBP


Good summary. It's easy enough for EU VAT/MOSS, but this is the killer right here:

> you may be liable to collect and pay VAT to the customer's country's tax authorities


> - If selling to anyone outside EUFT, no VAT, but you may be liable to collect and pay VAT to the customer's country's tax authorities.

I thought selling to businesses outside EUFT was the same as selling to businesses inside the EUTF.


Well I guess it would depend on the target country's specific tax laws.

There are also a lot of thresholds that might apply to your situation. More rules to look up, but could simplify it to having less administration if your revenue is under a couple K's

Good point! And with Stripe Tax we'll monitor how close you are to those thresholds too, so you'll know when and where you need to register as your business grows or sells into new markets.

Do you also provide advise on how to register?

Co-founder of Billflow here.

We were lucky enough to be able to integrate the Stripe Tax beta with Billflow. In my opinion this is the coolest thing Stripe is launched (For SaaS) since they came out with subscriptions. It just works™.

Implementing Stripe Tax was dead-easy, to get it working we essentially just had to switch a boolean to true on our subscription creation code.

Also, the new functionality of the upcoming invoice API is something we've been wanting for a while - being able to estimate the first invoice for a subscription _without_ the customer existing beforehand makes life so much easier when checkout is concerned.

Huge props to the Stripe team, love this product!


The feature is of course very nice, but the pricing is steep at 0.5% of your transactions. So I'm giving away 0.5% of my revenue (provided all of my revenue comes from sales) for the privilege of having my taxes calculated? That's on top of the 2.9%+30c per transaction that I already pay stripe?

Correct. But that's not what you're paying for of course, you're paying for the fact that you don't need to pay an accountant to double check these numbers: if they are wrong and the tax man comes after you, you get to hold Stripe accountable for any and all repercussions. You are paying Stripe--if you so choose--to take on the legal responsibility of getting it right.

> if they are wrong and the tax man comes after you, you get to hold Stripe accountable for any and all repercussions. You are paying Stripe to take on the legal responsibility of getting it right.

Where exactly is this stated? As far as I can tell, all this does is say what taxes you should be collecting, and then collect them. It doesn't even handle (at this point) remitting payment to the appropriate jurisdications.

I see no evidence that if your taxes are collected wrong, Stripe will do anything other than say "Your accountant should have caught that, sorry." I see no evidence that by using this product, Stripe will indemnify you against tax issues (which yes, would go a long way to justifying the cost)


I don't really think you're paying for accountability. That would involve some serious risk taking on Stripe side. I see no mention of this in the marketing material.

This is specially valuable if you are selling your product across multiple countries, which may have different taxes.

Is that legally binding somewhere? If they completely miss out that we were meant to collect X% for a municipality, will they be covering that out of their pocket?

That’s also on top of Stripe Checkout (0.5%) and on top of Stripe Radar (0.5%). Stripe cuts about 5% of every SaaS in the end. That’s a lot of money.

Hey! Kelly from Stripe here: Just to clarify, there's no additional cost for using Checkout, and Radar is per small per transaction fee (or included free with Stripe if you're just starting out!), not a variable 0.5% fee.

Thanks for clarifying! That’s something I was looking at on the landing page and didn’t find that. So Checkout already includes Stripe Tax at no additional cost. That’s great to hear

> So Checkout already includes Stripe Tax at no additional cost. That’s great to hear

I am no Stripe pricing authority, and have no relation to the company, but I'm pretty sure that is *not* what she said.

She said that Checkout does not have an additional cost on top of transactions fees, not that Tax does not have an additional cost.


It seems like the thing that makes it steep is the percentage rather than a charge per transaction, right? Philosophically it's geared to the total value you generate rather than the value they provide to you.

Ben Evans once described Stripe as tax on Internet SaaS. For a moment I’d thought it was Stripe admitting the same.

The same "tax" existed before Stripe, and it was higher, in both overall costs and development complexity.

"The price of doing business."

Credit card fees in general are like an extra tax. And credit card companies have so much power they have pushed the cost onto all transactions, even those that use cash (by forcing merchants to eat the cost difference, they push all prices with that merchant up).

This is something people say often, but studies put the cost of accepting cash for retailers at 4.7-15.3%, which is higher than the cost to accept credit cards. If anything, it's the high cost of handling cash built into prices that's increasingly burdening credit card users in stores, not the other way around.

I would take that as an argument that we should have better 'cash' that has lower costs to use.

Tbh these are debit cards. The Durbin Amendment limited the interchange that count be charged on debit transactions (I think the average is something like 0.3% now), so everyone was pushed towards "credit" products instead.

Ha I thought exactly the same thing. 2.9% + $0.30 tax to be exact.

i think that is generally a compliment though, not an accusation

That looks great, but that's a ridiculous pricing scheme. If you invoice $100k in a year, you're paying $4000 to Stripe to manage your sales tax.

A lot of the issues with sales tax are not knowing your regulatory requirements and set up. I'd say that's probably worth $4k, but then going forward you still have to pay them that amount. I'd say it would be more worthwhile to pay an accountant to do that for you, and save the ongoing fee. You will have to pay an accountant anyways to do your tax returns. I'm an accountant and my firm often does sales tax returns for our clients. Now, if you're making $1 million a year, that's $40k you need to pay Stripe for the privilege of not worrying about sales tax, compared to a few thousand you'll pay your accounting firm to do it.

The API and integration options are great and I hope Stripe is successful. Really, if they are, it means I can just charge more for my services.

Edit: As others have pointed out, I'm bad at math. I'm going to leave my shame up here but I realize it's $400, not $4000. Just goes to show you that accountants are just like regular people, and that you shouldn't rely on your accountant doing things off the top of their head not using Excel. The order of magnitude difference really shifts my opinion of it.


Nope, if you have $100k transactions in a year, it will be $100,000 * 0.005 = $500 not $4,000 (And 0.4% is when you make more than $50,000 in a month)

I too made the mistake of doing amount*0.05 when they provided me the pricing in beta.

This is why I went with them, if I can't do a simple percentage computation I'd rather not do the taxes myself.

And if you're making $1M a year, it will then be $4,000. And I guess that's still cheaper than having your accountant going through all your Stripe documents, computing taxes while also, on your side, having to make sure you're 100% tax compliant. Maybe at $10,000,000 it will start being a bit pricey, but at that point you'll most probably discuss with Stripe to reduce that fee.


When I saw this announcement, I had fully expected these new features to be included as standard - I was a bit surprised when I saw they were charging for them.

That said, I think the pricing is well worth it if you're selling B2C. EU VAT is complicated, and I presume state-level sales tax in the US is too.

If you're selling B2B in the EU however, then all you really need to do it collect and validate VAT registration numbers. Now, the EU API for this is pretty crappy, and has a ridiculously low rate limit - but still, it's not difficult to do. Indeed, I did it in a few hours when I was setting up Stripe for a B2B micro-ISV one or two years ago. I actually think that VAT ID validation should be included as standard - not chargeable.


Hey there, I believe validating VAT numbers is outside of the Stripe tax pricing and part of the Customer Tax IDs API, without any extra charge. Maybe someone from Stripe can confirm?

https://stripe.com/docs/billing/customer/tax-ids

And yes, if you sell only to B2B Europe and everyone inputs their VAT number you're fine (because you actually don't have to charge VAT, it's a reverse charge). Stripe tax do know this nowadays.

But that's actually not so common, people signing up for products usually have no idea what the VAT number of their company is. But they are capable of getting a credit card and giving you a business address.

In this case, you have to compute VAT rates based on the country of the customer.

(This is not an accounting advice, just personal experience!)


Yep, that's correct! Tax ID validation is included with Checkout (outside of Stripe Tax pricing).

> Hey there, I believe validating VAT numbers is outside of the Stripe tax pricing and part of the Customer Tax IDs API

Ah, good to know! It was mentioned in the same TFA, so I had thought it was chargeable with the rest of it.

> But that's actually not so common, people signing up for products usually have no idea what the VAT number of their company is.

Hmm, that hasn't been my experience, on either side of the table. As a biz owner, I get plenty orders from companies big and small, and always get a VAT ID through. When purchasing (on occasion) in my previous day job, I just had to ask someone in accounts what it was.


> If you invoice $100k in a year, you're paying $4000 to Stripe to manage your sales tax.

The pricing on the page says 0.4% - that's $400/year not $4,000

> Now, if you're making $1 million a year, that's $40k It's $4,000 by the above.

> compared to a few thousand you'll pay your accounting firm to do it.

It's not _just_ the money you pay the accountant to do it once, you need to get all of the data about where the customer is purchasing from to your accountant in a format they can use. Also, depending on your accountant, international sales tax is unlikely to be their forté - they might handle different states, but can they handle the varying rules in EU countries?


Yeah, you're right, my coffee hasn't kicked in yet.

For the amount I thought you would pay for Stripe to do that, you could have hired an accountant to figure all of that out for you on an ongoing basis, but for the actual price that's a pretty good deal to not have to think about it.

My opinion on accounting services has always been that it's nothing that a business owner can't do themselves since it's not really that complicated, but it's never worth the time when you can pay someone who already knows what they're doing. Stripe Tax falls into that category for me too, it's cheap enough that it makes it not worth it to do it yourself.


> you could have hired an accountant to figure all of that out for you on an ongoing basis, but for the actual price that's a pretty good deal to not have to think about it.

Even if you have accountants on tap, they may disagree. I did some work on a project where we were needing to deal with tax calculations (was using taxjar). At least one of the questions was about when we should be charging tax on certain 'extras', like... shipping. Their accounting firm said "no, you don't charge tax on shipping". Taxjar was automatically making that charge, and throwing off the expected numbers. After some digging, I found, at least in their primary state, they should have been collecting tax on shipping, but I don't think it was uniform across all the other states.

So... they had an accounting/books person on staff, and this question went up to their 'tax person'. I think it was either a general attorney or a tax specialist or something - this was their 'oracle/decision maker', and they were just flat out wrong.

This probably wasn't the case 20 years ago, when they were putting all their records in to an electronic system the first time, but... rules change. Keeping up with them is not a trivial thing, and when millions of dollars are on the line... you can make expensive mistakes.


The replit guy needs to study your post so he can learn how to handle mistakes the right way

What happened with the replit guy?


replit guy strutted out his hardscrabble kid from Jordan sob myth while "apologizing"

1. Kudos for handling your mistake gracefully.

2. As of this writing, almost everyone responding to you is using 0.4% as the pricing, when their page shows it's actually 0.5% for the scenario you described ($100k in a year). The lower rate only kicks in if you process over $100k in a _month_.

Unless they've changed their pricing details in the last hour, that's another great reason to let them handle this! Clearly we, collectively, don't have the attention to detail required for this ;)


I'm not sure if I'm missing your comparison, but an accountant doesn't calculate how much/which tax should be paid in real-time based on the business and the user's location and then automatically account for that.

I don't know how much it's worth, but properly supporting tax takes a lot of effort to do correctly in real-time.


> I'm going to leave my shame up here but I realize it's $400, not $4000. Just goes to show you that accountants are just like regular people, and that you shouldn't rely on your accountant doing things off the top of their head not using Excel. The order of magnitude difference really shifts my opinion of it.

Fair play to you!


$4k? Isn't $0.4k as it's 0.4%?

Bad look for an accountant!

So the accountant should be charging less (or stripe more)

I think it would be $400?

Your accountant is not going to build a system for you that verifies VAT IDs and can automatically calculate the tax % on check out I think?


Please double check your math before doing a hot take paragraph.

Wouldn't most online businesses just need to collect the taxes for the customers that their business operates in?

Posting this on the basis that there should be no stupid questions when it comes to tax.

For example; an Australian business needs to collect GST for Australian customers only. Americans accessing the Australian service would not be obligated to pay GST and as the Australian business doesn't have a US entity wouldn't have to collect US state taxes.


You would hope so, but no. A good example is that the UK now requires online business to collect UK VAT on sales to UK customers, even when the seller is abroad - there are many similar rules and this will really help people, especially smaller businesses who really face big barriers in dealing with these rules.

Paddle has a good article about this: "..the taxes apply not only to where your company has a physical presence (an office or employees) but to where your customers are based." https://paddle.com/blog/global-sales-taxes-for-software-comp...

It seems to be a huge mess. Even if you know how much to pay for different countries, registration for paying taxes can be painful.


Even domestically - US interstate sales tax rules are a mess too.

That's not how it works within Europe. You need to collect taxes in the country where your customer is located, you need to register with VAT instances in those countries. There are exceptions, for example up to some total revenue you may be allowed to collect local sales tax instead. This is what I've understood, but it probably gets more complicated in real.

> You need to collect taxes in the country where your customer is located, you need to register with VAT instances in those countries

Correct for the 1st part, on the 2nd part there is a VAT MOSS (One Stop Shop) where you report it in one place your sales/VAT for all the EU countries


No, that’s not correct at all.

Each country has their own laws about how tax works for online sales, and who is expected to pay it.

You can choose to ignore what governments in other countries expect. But that’s your decision.


That kind of used to be the way it worked, but not for the last several years. Now you are generally expected to know about the tax laws and requirements for the customers region and collect and submit tax accordingly.

Avalara (https://www.avalara.com/us/en/products/sales-and-use-tax/ava...) has been one of the go-to software platforms for this purpose. At least according to my wife, who is a CFO, and generally has to manage this stuff.


This is great! ATM I'm banning all EU end users from purchasing my SaaS unless they're a business because the cost of handling VATMOSS is just not worth it.

It also definitely played a role in choosing to do a B2B service over a B2C one.

So now the choice is:

- File VAT yourself, pay 3.5% + some pennies to Stripe - Pay 5% to Paddle and they file VAT for you

Definitely glad to see more competition in this area.


What makes handling VATMOSS costly for an Saas?

I deal with the software end of dealing with VAT for a small company that sells downloadable software and technical support for that software. We've not found it costly at all.

It took one guy a couple days or so to get registered with Ireland for VATMOSS.

To do the quarterly report for filing, I run a fairly simple script I wrote that produces a CSV file with one row per country giving the total sales and the total VAT we collected for that country, and someone uploads that to a form on the Irish tax authority site, which I understand is a simple and straightforward process.

To keep track of VAT rates, we use https://vatlayer.com/

Their API for getting rates is very simple, and their free plan allows 100 API calls per month. It is one call to get the rates for all VATMOSS countries.

The reporting script needs to get exchange rates to calculate the VAT in EUR for those sales where the customer paid in GBP or USD. The EU makes that information available in this handy XML document: https://www.ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d...

That contains the exchange rates between various currencies and EUR for the last 90 days. The rate you want for VATMOSS is the rate on the last business day of the quarter you are reporting for, so there is a little bit of calculation to figure out which day's rate to use.

They also have one that gives the most recent day if that better floats you boat: https:///www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.x...

If you need a specific range of dates for specific currencies, they've got that covered too. Here it is for USD and GBP: https://sdw-wsrest.ecb.europa.eu/service/data/EXR/D.GBP+USD....

Specify the range by adding query parameters startPeriod=YYYY-MM-DD and endPeriod=YYYY-MM-DD.


Mainly implementing different VAT rates. My accountant also would charge extra to do the EU VAT filing.

Right now I'm just charging no VAT worldwide (and we keep track of the totals in US states to see if we approach limits) or VAT for my country.

Also, given we're a B2B service, most of our customers are actual businesses, so we would be adding complexity to our payment flow for not much gained.

Thanks a lot for vatlayer, that looks great and I will definitely keep it in mind!


Actually, Stripe's payment fees are lower for European merchants (because card interchange is lower) so it would be more like 1.9% plus some pennies.

https://stripe.com/en-de/pricing


Stripe makes such complex products appear so simple. Their product pages are art of work. Amazing company.

Like, every single time. Their execution is amazing.

Serious question, have any of their products had a poor rollout?

I’m not asking about a feature you’d prefer that’s missing. I’m asking about something being buggy, poorly documented, or having a confusing marketing page.


> Serious question, have any of their products had a poor rollout?

Yes. Payments with SCA2. Very poorly documented when rolled out, and TBH the docs aren't much easier to navigate now once you get off their "do everything immediately client-side" happy path.

I've never known them to be buggy, but in this space there isn't room for bugs.


Yes, their PSD2/SCA roll out was disastrous. The documentation is marginally better now, and to their credit they've also produced a lot of example code repositories showing end-to-end implementations of various scenarios in various programming languages. But then, the epic scale of a full API integration and the moderate scale of even a Checkout integration today, as shown in those docs and sample repos, only highlight how painful the whole process has become. Then you look at the modern services that are going back to what early Stripe did so well, handling most of the pain of charging customers for you with very straightforward integration requirements, and the differences are stark.

The new additional transaction fee for Stripe Billing is awkward. They charge an extra 0.5%, which is fine, but it always comes out as a separate transaction instead of being added on top of their regular transaction fee. Sometimes it gets withdrawn from your balance after they've already deposited your earnings, leading them to make a withdrawal from the bank.

Not a huge deal, and I still love Stripe!


So. After 10 years in business and THOUSANDS of customer requests (I even made one myself, in-person when I met Patrick Colison at a conference) Stripe has introduced... a calculator. And you still have to do everything yourself - filing the papers and wiring money.

Thanks, but no thanks. I'll stick with my current payment provider that handles _everything_.

I do admire Stripe and wish I could move some day :(


Thanks for the feedback. We’re working toward an end goal of making tax compliance as simple as clicking a button. In talking with users they called out three big pain points: knowing what the obligations are, knowing what rate/rules to apply and how to calculate tax (e.g. SaaS is taxable at 80% of the base rate of the price in Texas), and then how to file and remit the money once collected. Stripe Tax solves the first two out of the box today, and with TaxJar we’ll be able to bring filing and remittance as a native part of our offering.

TaxJar won't handle global. SaaS is inherently global. Your own docs point to other providers for EU. Ultimately you need to have a Stripe MoR option.

All Indie developers or 1-3 person team need is a Merchant of Record, or simply a SaaS app store without index page like Apple Store. I don't even want to have a /billings page. Please also provide full feature customer portal (refund / cancel / pause / coupon / etc.)

And I want that store to have only literally "one" page for API documentation. All I want to check on my app is `authorized?(user.subscription)`


What's the other solution? Stripe to become merchant of record like Paddle.com?

I really hate the Paddle UI but this is the sole reason I'm with them. As a solo entrepreneur the peace of mind is just too good.

If Stripe added a Merchant of Record service, as an optional extra, it would be game over and they would win this space.


Yep, operating as a "reseller" paper-wise. We currently use FastSpring for that

Who's your current payment provider?

So they will charge 0.5% of my business to do my taxes? That makes sense until 350k per year more or less, but after that Quaderno has a 45 to 99 usd per month fixed price to do that.

It sounded outrageous the first time I saw it, but it actually makes a lot of sense for most small businesses.

I'm glad they rolled out this feature, too bad that they never announce what they are working on and it's a big bang overnight.

I was looking into integrating my app with a tax provider, I wouldn't even have started if I knew this was in the pipeline.

But now that it's here, it sounds great and just another reason for choosing Stripe. I haven't integrated with Paypal and I don't think I'm going to.


From the docs (https://stripe.com/docs/tax/checkout) it looks like Apple/Google Pay is disabled when Tax is enabled. I wonder if there is a technical limitation there or if that is something that will be supported soon?

Confirmed this is a technical limitation that we're working on as swiftly as possible. Drop me a note at jackerman@stripe.com and I'll let you know as soon as we've resolved this limitation!

This looks great. Implementing Avalara for tax calculation was a large pain across multiple dimensions.

Stripe Tax integrates with TaxJar for automatic US tax filing [1]. I wish TaxJar had clearer pricing [2], as 12 filings a year is tiny.

[1]: https://www.taxjar.com/pricing/ [2]: https://stripe.com/docs/tax/reports



Stripe acquired TaxJar ~45 days ago – that's awesome

So how does one pay tax with this?

Let's say you and your server are in Singapore.

You are selling a digital product - PDF book on dynamically typed Rust...

You have customers from all 50 US states and all European countries.

You have 100k USD sales total.

At the end of the year are you obliged to send the correct amount of tax to EACH US state and each EU country?


Yes, to the extent they require it (and you want to stay compliant.) There are companies that can handle the remittance for you; Stripe lists several on their page. Reporting requirements would probably be quarterly or monthly.

In practice, almost all US states that have sales tax have a in-state sales threshold amount, usually $100k+ and/or 200 transactions, and at the level of business as per your example, you wouldn't hit it. (Kansas has no threshold, but this is probably illegal per the terrible court decision that allowed this sales-based nexus mess.)

https://www.streamlinedsalestax.org/for-businesses/remote-se...

EU, I dunno. Beyond my ken.


Thank you!

A bit more clear, but still seems really messy.

So if there are limits I assume you collect 150 transactions a year from California, you have to keep the tax collected until you reach 200 and send the tax for all 200?

Presumably you can't spend the money on beer and yet you also can't refund the customers either.


I'd say it's more than messy, it's a disaster. There are reasonable solutions to internet+sales tax, but the current situation is not one of them.

If you collect the tax, you need to remit it. The transaction/amount limits are the limit where you should register, collect, and remit. And usually this is a one-way affair; once you're registered, you'll need to keep filing even if you fall below the threshold.


Check with Singapore authorities, or Singapore "IRS". If you are a tax resident of Singapore, that's the only country you are liable for.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: