The reasoning might not sound crazy, but the result is that a founder based in Hong Kong, opening a holding in Singapore, and creates a subsidiary in Germany is much much better off than a founder running the same business out of Germany - and that's before considering personal income taxes or similar
is this hypothetical Hong Konger real? Someone who wants to set up a company in Germany and is repelled by a theoretical exit tax should they plan to leave a few years later?
We're a big country and the world's 3rd largest economy. From our perspective it makes no sense to become a financial haven for foreign founders who just want to benefit from government support which can be quite extensive only to leave after a few years for some tax haven.
We need to do do more to encourage people to invest here and build ecosystems and make starting companies easier but an exit tax clearly only matters to the get-rich-quick and relocate to Dubai crowd.
how did you do it? My co-founder is in a similar situation, and his tax-lawyer said the only way was via a trust - they also have a German holding. Do you have to declare that somewhere? or how does this work? Thanks!
I can't give more specific information about my situation, but I would recommend contacting one of the companies that has a public article on the "Wegzugssteuer", for example the one I linked in the first comment. That way you know you get someone that actually knows how to deal with this.
My first tax advisor barely even knew about the Außensteuergesetz and almost got me into larger trouble because of that. I'd guess since this law only affects a tiny portion of the population you really need someone that specializes in it.
If they specialize in it they'll have done this many times before and you can just use their pre-made constructs. Then the main issue is avoiding getting squeezed by them.
This means the person has to move to a country with 0% income tax for this to make any economic sense, so that's either Monaco or the UAE then. Very difficult for me to understand why someone is supposed to pay this tax in the first place, the business paid a whole bunch of other taxes in its lifetime.
I would understand if they'd tax the sale of the business.
That is actually the intention: to tax as if you sold the business. But with a payment in 7 yearly rates. The tax intends to tax the value of the company that is not yet taxed (on a personal tax level). It does account for already paid businesses level taxes.
Its purpose is to avoid business owners to move to a low-tax place 12 months before selling their business and then move back to Germany another 12 months later, thus avoiding any tax on the increase in value of the business.
apart from those weird file attach issues I actually think they've got a much better UI than anthropic as well - much much snappier even with extremely long chats (in addition to much higher limits obviously, totally different league). I love using it
just a question for understanding - if we say 'it learns', does it mean it actually learns this as part of its training data? or does this mean it's stored in a vector DB and it retrieves information based on vector search and then includes it in the context window for query responses?
The latter. “Learning” in the comment clearly refers to adding to the knowledge graph, not about training or fine-tuning a model. “and then you can RAG them.”
yes, agree, I think a 'source' 'destination' model is significantly more straight-forward. Just record the 'source' account and the destination account and you essentially end up with a ledger as a directed graph (Martin Kleppmann wrote a great post on it)
Blockchain actually kinda nails it, that's in essence a source/destination ledger, no 'postings' or similar needed, and from a balance calculation POV has been working pretty well
One reason this model isn't applied in accounting, in my personal view :), is simply historical and the fact that the number 0 didn't exist when accounting principles were created.
It's very straight-forward, you just have to accept that asset accounts have negative balances and present the absolute amount instead of a negative amount in a view.
It isn't always clear which is "source" and which is "destination" and now you need a bunch of new conventions about these things. Accounting already has these (admittedly arbitrary) conventions so we might as well use those.
> you essentially end up with a ledger as a directed graph
The page contains a comment from Matheus Portela who pointed to a blogpost of his about "Double-Entry Bookkeeping as a Directed Graph" [0].
"I've also had the same problems you described here and double-entry bookkeeping is the way to go for financial accuracy. As a programmer, things clicked when I realized this system is an extended directed graph.". It turned out that: "Hi Matheus! Would you believe me if I told you that I read your post in preparation for this article?"
Source/destination seems fail on actual DB implementation. How to sum all entries for a particular account? It could be on either side. It complicates queries and could trigger unoptimal query plans.
An account could be only on one side. The side and chapter is the meaning of this account. Account on the left just negates the increase/decrease direction.
In a bank ledger when a loan appears on a checking account, both increased. Loan on the left, checking on the right. DT Loan → CT Checking. Loan is an asset for a bank, Clients money is a liability.
On a client's balance sheet everything is mirrored. Checking is an asset, Loan is a liability.
Queries are quite simple. Volumes are problematic. In a big institution you would find several ledgers included in the general ledger by totals. You just don't need all the details in one place.
You’re right. Missed it while scrolling. Regarding the parent discussion, a classic statement is also two-sided. So, you need to collect sources (debit) and destinations (credit).
It is definitely possible to make each side of transaction a different record, but you have to link them, so there would be another ID for a transaction to group later. It is always there in any case, but you are either joining while getting a balance or grouping while reconstructing transactions for reports. So, it depends on the primary load: lots of transactions to register or lots of reports to provide. Both are used.
you simple create two records linked by one 'transaction', the source in both cases is the same account, while the destination for one of those postings is the fee account and the other destination is a merchant or similar account. And you can link as many of those postings under a single transaction
okay so now you’ve got double-entry bookkeeping except all of your credits/debits have two dollar values instead of one. let’s call it “quadrupal-entry”
yes, it's a form of double-entry bookkeeping - that's the base. If it weren't double-entry then indeed it would be a pretty poor choice. This design enforces double-entry at a fundamental level, it's never possible to create a record that doesn't affect 2 accounts - and that's actually the whole point of it :)
You have a single USD (or other) value - so in the simplest form it just looks like this:
From: Alice
To: Bob
Amount: 10
Currency: USD
And the balances are simply sum(transactions where account is receiver) - sum(transactions where account is sender)
absolutely not true btw - the largest use-case for stable-coins atm are people evading capital controls in emerging markets, including China, India, Nigeria, and similar, and in many latin American countries.
Where do they need tumblers for personal non industrial scale operations? I know ppl in South America who use crypto to save on dollar conversion fees when sending money abroad to family. No washing needed.
Where on the planet an oppressive gov somehow has the resources to track insignificant personal crypto amounts from ordinary people instead of just banning crypto? Check if crypto fuels this oppression machine in much larger amounts in the first place?
this is the thing with JS and TS - the types and stuff, it's all good until you realise that all integers are basically int 52 (represented as float 64, with 52 bits for the fraction).
Yes, it's nice and flexible - but also introduces some dangerous subtle bugs.
