Stripe never claimed to handle tax however. Merchants have to handle tax on their own. This is no different than accepting cash or using a card terminal in your shop. The payment processor does not handle your tax for you.
There is no credit card terminal in the whole EU which is not tied to a point-of-sale system, which only purpose is to create INVOICES. Somehow the Stripe team forgot that fact.
I find your critique not very sensible. Point-of-sale systems are not necessarily tied to the payment terminal just because they communicate to each other. If companies choose to use Stripe they do have to set up their own invoicing and tax handling. Your comment makes it sound like Stripe hides this fact and thus users end up not handling tax or invoices because they were mislead. But if you run any kind of businesses being on top of taxes is obviously paramount. I don’t quite get your gripe here.
Stripe has built-in features for merchants to create invoices and receipts.
Stripe does KYC for their merchants and exactly know that they are a company of certain type from the US.
Stripe facilitates a sale of digital goods between the US-based merchant and EU-based consumer. At this point the US-based merchant is obligated to pay the VAT and create an INVOICE.
Only Stripe knows from which EU country the customer comes from. The US-based merchant does not know which EU country the customer comes from.
Therefore Stripe is obligated to calculate the applicable VAT (based on country of customer) for the transaction and deduct it fromt he payment amount. STRIPE IS NOT DOING THIS.
And once payment is made Stripe does not enforce the merchant to provide an invoice, even though Stripe knows exactly it just facilitated a sale of digital goods between US-based company and EU-based customer. Stripe even enables the merchant to put fantasy information into the receipts and invoices, they don't have valid company name, addresses, or registration numbers.
Stripe also allows their merchants who just did a transaction to EU customer to only offer a "receipt", with no sign of an invoice. This "receipt" can contain a single website url, it can contain total fantasy name, it does not need to contain an address, or even a country of the Stripe merchant. It does not contain a company registration number or jurisdiction of the Stripe merchant. It does not contain company type or legal company name of the Stripe merchant. EVEN THOUGH STRIPE KNOWS ALL OF THIS BECAUSE THEY KYC THEIR MERCHANTS.
This is in total violation of any EU accounting rules which also applied to Ireland where the Stripe EU HQ is.
Luckily Stripe lawyers know exactly that they are systematically aiding and abetting tax fraud against the European Union and once you press the proper regulatory buttons they will cave, and after months of stonewalling suddenly their merchants are forced to provide their FULL COMPANY NAME AND COMPANY REGISTRATION NUMBER AND COUNTRY OF OPERATION, and actually state VAT in the invoice.
But their default mode of operation is "We are located in Ireland, EU law applies to us, we know EU customer buys digital goods from US merchant, we KYD'd the merchant but still we ignore that EU VAT applies to the transaction".
Any accountants and lawyers working for Stripe Ireland should be disbarred just on the fact they are associated with this systematic tax fraud.
There was no systematic remediation of the situation - even though Stripe knows about tax fraud by a merchant, they will only restate the invoices FOR THE SINGLE CUSTOMER THAT COMPLAINS ABOUT IT instead of forcing the merchant to properly create invoices for every single transaction with EU customers of that merchant.
Show me a tax agency in your country which allows you to get away with this. It is highly criminal, systematic behavior, clearly targeted against the European Union.
The SE has a minimum capital requirement of 120k € so is not within reach for most people. I think this EU-Inc would be a simple structure with a lower threshold.
I am absolutely for it. There are too many different types of company structures in the individual EU countries and they don’t work well when you move and come with all sorts of different risks. Obviously many are also just cumbersome to start and dissolve. You could start five US LLCs within ten minutes of filling out some online forms whereas to start one European entity depending on the country you might have to make a notary appointment, register with the national registry and the tax authority. I think there’s a lot of room for improvement which can take days to weeks.
> Most of the whining I've heard about DB boils down to inconvenience in situations nobody could have predicted nor helped [..]
I agree with you that there’s a lot of complaining and it does get tiresome. The German train system is one of the most complex in the world and works closer to an interconnected spider web than the typical straight line systems in other countries.
However much of this has been predicted in the past. I think that’s why a lot of people are annoyed. Here are some sources if you’re interested to read more:
DB‘s quality decline started when this move to privatization happened. They didn’t put money into maintenance, closed lot of tracks and ignored all warnings by experts who predicted this exact scenario more than a decade ago. Most of the time now DB issues seem to be connected to a lack of available tracks. A super fast ICE has to wait for some slow train to clear the path. There’s an issue on one track and thus the entire traffic is backed up till that’s resolved.
I do think they’re working on improving these conditions. But I wish they did more to communicate that. Where is the big marketing campaign explaining how they got there, apologizing, and explaining how they will do better?
It’s a complicated question nowadays as the first generation of networks that were really all about networking have mostly died out or morphed into algorithmic feeds. So the question is whether there’s a market for this classical networking at all. If so for a network to make sense you do need networking effects of some kind as people would likely not want to pay to be registered to a service that shows them having 0 friends. I do think it’s a difficult bet.
I can however see this for niches and small groups. Something more akin to old school bulletin board forums. In a sense Metafilter works a bit that way already.
If you assume the unit of value is a pre-existing group rather than an individual user, do you think paid access becomes viable earlier, or does it introduce different failure modes?
I’m interested in whether group-first adoption meaningfully changes the cold start problem, or simply moves it?
Was there any concern about giving the LLM access to this return data? Reading your article I wondered if there could be an approach that limits the LLM to running the function calls without ever seeing the output itself fully, e.g., only seeing the start of a JSON string with a status like “success” or “not found”. But I guess it would be complicated to have a continuous conversation that way.
> No model should ever know Jon Snow’s phone number from a SaaS service, but this approach allows this sort of retrieval.
This reads to me like they think that the response from the tool doesn’t go back to the LLM.
I’ve not worked with tools but my understanding is that they’re a way to allow the LLM to request additional data from the client. Once the client executes the requested function, that response data then goes to the LLM to be further processed into a final response.
I was confused by that too. I think I've figured it out.
They're saying that a public LLM won't know the email address of Jon Snow, but they still want to be able to answer questions about their private SaaS data which DOES know that.
Then they describe building a typical tool-based LLM system where the model can run searches against private data and round-trip the results through the model to generate chat responses.
They're relying on the AI labs to keep their promises about not training in data from paying API customers. I think that's a safe bet, personally.
Makes sense. I agree that it’s probably a safe bet too. Not sure how customers would feel about it though.
It’s also funny how these tools push people into patterns by accident. You’d never consider sending a customer’s details to a 3rd party for them just to send them back, right? And there’s nothing stopping someone from just working more directly with the tool call response themselves but the libraries are setup so you lean into the LLM more than is required (I know you more than anyone appreciate that the value they add here is parsing the fuzzy instruction into a tool call - not the call itself).
That would be the normal pattern. But you could certainly stop after the LLM picks the tool and provides the arguments, and not present the result back to the model.
reply