Haha, thanks for linking to my website! Happy to answer any questions.
Skimmed this thread and I'm quite surprised how few people are aware of the permanent establishment problem.
Quick primer on the permanent establishment problem: You would technically have to pay taxes for your company in the place you're living (not Estonia). For example, if you're living in Germany, your Estonian OÜ would technically have to file for German taxes, too, because it's being run from Germany and it now has a permanent establishment in Germany.
So, roughly speaking, the Estonian OÜ is only useful if:
- You are in a country which doesn't have a permanent establishment problem and maybe even offers tax benefits for foreign companies (e.g. the non-dom rules of Malta, Cyprus, etc.)
- You are in a country which doesn't have a permanent establishment problem because they don't crack down on foreign company ownership (e.g. most developing countries)
In all other countries, the Estonian OÜ is likely going to cause you many tax headaches in the long run. In practice, this means:
a) Your local tax authorities don't notice or don't understand, and you're still fine, even though you'd need to file for taxes;
b) Your local tax authorities crack down on you and you need to go looking for a very expensive international tax advisor versed in Estonian and your local tax law.
- What you're talking about is working as a freelancer (Freiberufler), which is a subset of a sole proprietor (Einzelunternehmen); these are different business types than a GmbH, and the article is about setting up a GmbH.
- Only setting up a GmbH if you want to "invest money" is overly simplistic. People might choose a GmbH due to limited liability, a more solid shareholder structure, etc. Slightly more generalized, you do have a point that of course a sole proprietorship might be a much better and simpler choice for one-person "companies" who mainly offer software freelancing services.
- Not setting up a separate bank account for your business, GmbH or otherwise, is strongly advised against. Not only by literally 100% of tax advisors, but also by the tax office themselves.
Yup. Most of the time, you simply don't need a GmbH.
I wonder why German people often think they need to found one - maybe because people in the US have a low threshold of founding an LLC, but that's because it's easy and cheap; or maybe due to the German Angst of "I will immediately get sued, so I need limited liability".
Sure, there are lots of middlemen who are more than happy to take your money to navigate this broken process, and tax advisors are probably #1 on the list :)
That being said, even throwing money at a tax advisor won't reduce the 16 steps to 1. More like 5-10.
You'll still have to to go the notary yourself, you'll still be opening the bank account yourself, you'll still be subject to Handelsregister spam and fake invoices, etc., etc.
Awesome. I'd be really curious which lawyer you were referring to - if you like, feel free to reach out privately (e.g. Telegram channel link on the website) :)
Ha, that's my website - thanks for posting it (and for linking to it - allaboutberlin is awesome!).
Indeed, the valuation for the purpose of exit tax is 13.75 * (avg. of yearly profits for the past 3 years); and that valuation is taxed at approximately 30%.
So, as an example, if you own 100% of a company which makes 200k€ yearly profits, your back-of-the-envelope exit tax is 200k€ * 13.75 * 0.3 = 825k€.
A few quick notes:
- If your startup is not profitable but has raised VC money (we're on the YC website after all), the tax office likes to take the VC valuation (!) instead of the valuation resulting from the 13.75 multiple. So, if the valuation in your last round was €10M, then that's your valuation for the purpose of exit tax (back of the envelope: You own 50%, €10M valuation: 0.5 * €10M * 0.3 = €1.5M exit tax; huge problem for early-stage founders who usually don't have liquidity).
- You can deduct a CEO salary from that (yearly) number if you haven't been paying yourself a salary yet - realistically, up to 150k€ / year. So if your profit is up to 150k€ / year, you can reduce it to near zero for the purpose of exit tax valuation.
- You can also supply your own company valuation, but it has to be done by a "Wirtschaftsprüfer" - this costs around 10k€ per company; if you have shares >1% in multiple companies, this means costs of n * 10k€. This is often prohibitive.
- There's a whole tax advisor industry around this exit tax topic, and it feels very shady. I've written up all my notes from (paid) tax advisor calls and shared them on my website for free (linked by in parent comment).
- There are various setups to "avoid" it (all outlined on the website). None of those setups is easy, and none of them is free. Still, if you're e.g. faced with a potential exit tax of 825k€ like in the example above, any setup which might cost less than that might be theoretically worthwhile.
- If you leave Germany and return within 11 years, you get the exit tax back - so if that's your plan, you could "just" take out a loan and it mainly becomes a liquidity problem.
- Historically, there has been a strong tendency for Germany to tighten its exit tax laws over time.
- Different people have (vastly) different opinions on how "good" or "fair" this tax is.
- Discussing the exit tax has become quite a common topic among German founders nowadays.
Berlin is a great place to observe policies with good intentions, yet negative second-order effects.
Distributing free potatoes will likely cause waste somewhere else, as e.g. people will buy less potatoes in supermarkets. The waste just becomes less visible as supermarkets dispose of food every day.
Another current exhibit is the prohibition of using salt for removing snow and ice from the pavements because it's "bad for plants and the ground water". While that is true to some degree, the Berlin policy conveniently ignores all second-order effects: Sidewalks are more slippery, more people get hurt. I see people slipping on snow-compacted ice almost every day. How many trees have to be saved to make it worthwhile for more people breaking their bones?
You can apply for an exemption though, e.g. if you plan to use salt on a driveway to a hospital. Processing fees for such an exemption are up to 1.4k€ [1].
The rent cap is another one. But let's go there another day..
- I assume you're referring to founding a UG with 1€ in Germany. If you truly found it with 1€, it'll technically be bankrupt shortly after founding it because the founding costs are around 1k€ (notary etc.), and you haven't made any revenue yet. It's generally recommended to found with at least 2-3k€.
- 10 days is not a reasonable timeframe for founding a German UG. Optimistic timeline: Instant notary appointment, 14 days for corporate registry, instant bank account, 14 days for tax ID. Total of 28 days.
In most developed countries, you should incorporate at your place of residence. That's because incorporating in a foreign country will introduce tax issues regarding the so-called "permanent establishment".
As an example, if you'd be living in Germany and choose to incorporate in Estonia, then it's likely that your Estonian company has a permanent establishment in Germany, because you (as an owner and managing director) are performing work there. This leads to your company having to file for Estonian and (!) German taxes, which quickly becomes a headache.. and potentially expensive, as you'd need to rely on international tax advisors if you run into problems.
But even besides that, the main problem is that you still are hit with German bureaucracy, even if you incorporate in Estonia - you have to file for German taxes, potentially register your Estonian company (= its permanent establishment in Germany) in the German corporate tax registry, etc.
I've looked into this fairly in-depth and also discussed it with people in the Estonian e-Residency team. They largely confirmed my analysis, which I wrote up here [1].
The conclusion, unfortunately, seems to be that incorporating in another country (e.g. Estonia) only is viable if a) you're not living in a developed country which follows up on tax payers and where their businesses are located, b) you're actually living in Estonia or c) you have a sufficient budget for actually setting up a (physical) establishment there so that you don't run into the dual-permanent-establishment problem.
Interesting to see this on HN. I was part of the research group which published this back in 2015 [1], I think we were the second group worldwide to publish this.
So, first off, this is not new. The linked publication here mainly seems to be explaining a potential mechanism of how it might happen.
Some quick notes to aid in a constructive discussion - bear with me, it's been a while and I've left research and since worked as a software developer, chuckle:
- Different gadolinium agents have vastly different "buildup" characteristics - some are better, some are worse. Biochemically, the ones where the gadolinium was trapped in harder "complexes", those were more stable (less accumulation). I suck at biochemistry, so all of those words may be wrong.
- If you'd want to over-engineer this, you could indeed select your MRI hospital / practice based on which gadolinium agent they use.
- Unless you're getting a ton of MRIs (think multiple sclerosis monitoring etc.), you probably won't be affected.
- Most MRIs are without contrast agent anyway, so you probably won't be affected.
- The last I heard was that the clinical implications were still being investigated - like, yeah, you do see a buildup of gadolinium in patients who 1) get certain gadolinium agents and 2) have a ton of MRIs, but what does that mean they'll suffer any clinical consequences from this? Not sure. I heard that there was a paper (.. somewhere) which at least showed a correlation with worse MS outcomes of people who had a high buildup, but then again, cause-effect here is not clear as people with worse MS tend to have more MRIs, too (correlation != causation).
For web projects, the benefits provided by Clojure on the backend side may not be very large; there are already good languages with extensive libraries available (Django, Rails, etc.). It arguably may seem hard to choose Clojure with its minimalistic libraries when these frameworks provide an "easy" [1] way to get running with a full-blown admin interface. Furthermore, backend code by itself tends to be dependency-heavy in the way that you need dependencies which you'll definitely not write yourself: You need a library to interface with your database, you need something for cryptography / passwords, etc.
Looking at the frontend (React) side however, things are different. The JavaScript ecosystem is a mess. From a viewpoint of a React developer, there are lots of libraries which vary widely in quality. react-router is an interesting example here, it had 4 (?) breaking changes so far by replacing the entire api. There's a ton of mental overhead for the normal React developer trying to write a "simple" app.
Ironically, developers start rolling their own stuff. Instead of using a form library which tightly couples your components to your redux state (redux-form), you start writing your own. Instead of coupling your entire views to graphql via apollo, you start doing it differently, your way.
This is where ClojureScript is a game changer. If your app differs just slightly from a (very) vanilla CRUD app and whipping some libraries together doesn't do the trick, you start writing custom stuff. When writing custom stuff, you want a programming language which is a) well thought through (great standard library, immutability, sane concurrency) b) predictable and c) productive. ClojureScript has all three while JS has none.
We (Merantix) are currently developing a medical image viewer in ClojureScript and had prototyped two separate versions: One in JS with React, another one in ClojureScript with reagent and re-frame. Even though it is dependency-heavy (webgl stuff), ClojureScript turned out to be the superior choice: Immutable data structure at its core which ironically perform better than Immutable.js and way higher developer productivity due to less random bugs and a more interactive development (REPL).
Using Clojure on the backend now seemed like an obvious choice: We can reuse and share code from the frontend and more importantly, all our developers are "full-stack" in the sense that everyone can at least understand what's going on "on the other side" (backend / frontend) of the stack as it's literally the same codebase.
The learning curve is significant but the advantages are tremendous. I wholeheartedly recommend learning Clojure even if you're not allowed to use it at your job. It sounds cliché, but it will make you a better programmer for sure.
Personal website: https://eidel.io
OpenRegulatory: https://openregulatory.com