[Request] Expose settings for what constitutes a taxable event

[tdbe]

Tax rules change a lot; also there are many countries out there. It's unfeasible to maintain up-to-date taylor-made presets for each country. (I mean it's great if it just works with outputting a complete tax form; but tracking PnL with the user's rules is the core feature.)

So why not just expose a settings file where the user can describe what are the taxable events they want rp2 to consider?

Other tools have for example checkboxes like this:

♥

[eprbell]

Implementation-wise this whould be fairly easy to do: add a custom country class that reads from the settings file.

However I am not too sure if we should go through with this proposal for the following reasons:

• I don't know that these parameters actually change a lot, but when they do they are all collected in country classes and are very easy to change there.
• adding a custom country class that reads from the settings file allows the user to shoot themselves in the foot, if they fill the values incorrectly. As a design principle I would prefer these settings to be part of the RP2 code base, so that the user doesn't have to worry about it.
• keeping the country classes up to date is the job of the RP2 community: if this project is to become the community effort I hope it will become, then country classes will be updated with PRs when tax laws change around the world. That would be a better scenario in my mind.

[tdbe]

I mean, I didn't think about "country classes" at all. I'm a simple man, I want "checkboxes" for setting what constitutes a taxable event. Maybe flash the whole thing red and say "you're no longer in a kosher country template".

Here's more reasons:

• In many countries the legislation changed from one year to another, so for example when I create a report for 2022, there will be different rules than when I do one for 2023.
• In germany if you hold crypto for over a year it's tax free.

Just my initial observations. (I'm very new to rp2, came here after trying just about every GUI tool/website under the sun and they're all either bad, or too expensive, or unreliable, or not private enough, or all of the above 🙂)

[eprbell]

Yes, I understand your proposal: I was pointing out that the place where country-specific semantics is captured in RP2 is the country class hierarchy. You're proposing a veneer on top of it to make it more user-friendly. However I'm still not sure if we should let non-programmer users define the tax rules (for the reasons I gave in the previous reply).

[tdbe]

Ok. I personally think my accountant should define the tax rules on a case-by-case basis😁, not the generic programmers/community. Also I haven't seen any other tax tool which does not let you do this.

[eprbell]

I disagree: tax rules are defined by regulators around the world and tax tools convert the rules into software. If the rules change, so should the software. As I mentioned before, letting RP2 end users define tax rules freely has two drawbacks:

• it makes it easy for users to shoot themselves in the foot,
• it makes it much more difficult for us to support users.

The second point is especially problematic, given that we're a small team of volunteers with day jobs and other commitments.

[macanudo527]

The current tax report sorts transactions by airdrop or mining, etc... and then it is up to the user to declare these as income or basis costs or whatever. The basic functionality is already there.

Are you saying there should be the ability to change accounting methods or something?

[tdbe]

The current tax report sorts transactions by airdrop or mining, etc... and then it is up to the user to declare these as income or basis costs or whatever. The basic functionality is already there.

Are you saying there should be the ability to change accounting methods or something?

In short, yes. Do what I showed in the Koinly options screenshot in my main post. Need to know after each event how much profit/loss there is, or there isn't, depending on the rules I set. Airdrops can be an instant taxable event at receive time, or a zero cost 100% tax event at sale time, or in some countries, no tax at all if you sell within a certain timeframe of the airdrop.

In general, and beyond airdrops / mining:

• there are different cases for different types of users (freelancer, microcompany, company, private user),
• there are different cases for different years (e.g. when you generate a report for 2020 vs one for 2022 vs one for 2023, different regulation or different regulation flexibility)
• there are time based rules like in germany
• there are different gift rules
• there are people who are tax residents of multiple countries and maybe want to make sure they intersect both rulesets
• there is law flexibility of various kinds, e.g. not just FIFO, or to choose to count stablecoins as fiat or as crypto etc etc.

Basically, the more granularity you allow on taxable event definition, even year-to-year, will be desired for a proper tool. Otherwise I'll just build my own VB excel sheets.

Plus, guys, I just showed you in the OP, koinly, probably the most normie-friendly tool out there, allows you to choose all of those tax rules in my screenshot. So I guess you're free to limit your userbase and drive it to competitors 🤷‍♂️ I didn't expect the "we must save our users from themselves" customizability attitude from open source devs.

[macanudo527]

I think the real crux here is that it's just not feasible. What you are asking would require a complete rewrite of the accounting engine. I can see this being useful down the road, so that we can easily add countries just by checking a few options, but that all takes a lot of programming. It would easily take 5-6 months for a full time developer to implement and test all that. It's just not a priority when we still don't even have a GUI up and running. We are a team of 2 core developers that contribute about 5-10 hours a week and contributors that come and go.

The current infastructure actually works pretty well. I file taxes for Japan and US with it with 5000+ transactions on 5 different exchanges. For a group of open-source developers working for free that ain't too shabby.

And Koinly is not our 'competitor' as you say. Koinly is a paid, closed source, cloud-based service, which you entrust your personal data and API keys to. If you trust them to not use your data and protect it from data breaches, they are an excellent service. I encourage you to use them!

We are a free open-source, application that runs on your personal computer, which means you do not have to give up your data to a 3rd party or entrust your API keys to them. The disadvantage of that is that you have to rely on the community to build what you want or build it yourself. That's the 'cost' of free open source software if you will. If that's not for you, then please go to our 'competitors'.

[tdbe]

I hear you, but it's not good architecture/premise to limit to one set of "country rules" (+ force-rely on community country updates). I gave plenty of examples/reasons. Including the crazy ones like "if you got an airdrop and sold it within 1 week, then it's tax free". Or simply the fact that in many countries you have a choice of how to interpret the transactions. Or maybe you're a company. Etc. You can't get away from that by arguing "we have a broken feature premise because we're not centralized".

The simple thought is: I can do this in excel. And I can tweak the formulas. Why not also expose the formulas in rp2? (yes, at this point, it requires some rewriting) But it's common sense to expose the set of constraints; can also be a light per-event scripting layer, that eventually maybe someone makes a GUI for.

Anyway I got all I was trying to find out: bottom line is there is no open source tool that I can use for taxes. (rotki does not even show actual profit and loss) Great. And I gave you some technical product design food for thought. Cool. Cheers.

Yes I constantly heavily don't recommend koinly. But normal people, hu-mans, have no choice.

[eprbell]

As I explained earlier, I disagree with your premise: what you're proposing is a support nightmare. I also think such a feature is questionable design and dangerous, especially considering that adding a new country or tweaking rules (if you really need to) with code is fairly easy in RP2: have you looked at it?

To summarize: if you find that RP2 tax support for a given country has changed or needs improvements, the correct course of action is to submit a PR. This also ensures that all users of that country will benefit from incremental improvements. If RP2 doesn't work for you feel free to use another tool.

[eprbell]

Closing this issue as per discussion above.