Deducting sell fees in proceeds

[skasab]

First off, this is an amazing project, and a big bravo to you for creating this as a DIY alternative. After wrangling the tool for a little bit, one thing I believe I noticed is that fees are not being deducted from proceeds. Source for fee deduction logic is this article.

As an example, consider some fake currency XYZ.

I buy 10 XYZ @ $10 with a $1 fee. Total cost of $101, making my cost basis for each XYZ $10.10, as the fee is distributed across all the assets.

I then sell all my XYZ @ $20 with a $2 fee, netting me $198. Each XYZ sold for $19.8, for a total capital gain of $9.7 per coin = $97.

However, when running this example case, rp2 returns that the proceed of the sale was $200, for a capital gain of $99. Apologies if I'm missing something!

As an aside, an option to mark sell fees as fiat instead of crypto would be useful, I think, as some exchanges charge USD off the top.

Again, thanks so much for putting so much time and energy into an open-source and free solution.

[eprbell]

Thanks for the kind comments and the bug report: much appreciated! When I researched cost basis and proceeds I read about adding the buy fees to the cost basis, but didn't find about deducting sell fees from the sale price, so I took the conservative approach and left the sale price unchanged: RP2 does add buy fees to cost basis, but doesn't deduct sale fees from sale price. I read the article you pointed me to and I did more research on the IRS web site to double-check the article: IRS Publication 544 explains this ("Example 1" in the "Gain or Loss From Sales and Exchanges" section shows that selling expenses are deducted from the sale price) and so I think you're correct. I will fix the bug in the next day. Thanks again for finding and reporting the problem!

[eprbell]

Regarding your other comment on using fiat for sale fees: it's already possible to do it via the fiat_fee parameter of OutTransaction (see the input files section of the documentation for more on this). This parameter is optional (meaning that if it's not passed by the user, RP2 calculates it), whereas the crypto_fee parameter is mandatory and must be passed in. My assumption here was that exchanges would always use crypto for sale fees (the ones I use do): could you point me to exchanges that use fiat for sale fees? If the assumption is incorrect I may have to update the OutTransaction constructor slightly to account for this. Thanks for the great feedback!

[skasab]

Regarding your other comment on using fiat for sale fees: it's already possible to do it via the fiat_fee parameter of OutTransaction (see the input files section of the documentation for more on this). This parameter is optional (meaning that if it's not passed by the user, RP2 calculates it), whereas the crypto_fee parameter is mandatory and must be passed in. My assumption here was that exchanges would always use crypto for sale fees (the ones I use do): could you point me to exchanges that use fiat for sale fees? If the assumption is incorrect I may have to update the OutTransaction constructor slightly to account for this. Thanks for the great feedback!

I currently use Coinbase and Coinbase Pro, who report their fees in USD, at least in their exported transaction histories. Screenshot attached of what I mean.

Although I can convert the fiat fee to a crypto fee by multiplying by the reciprocal of the spot price, that may not be intuitive to some people.

In addition, this would solve an additional issue I was having. Originally, I converted the fiat fee to a crypto fee and simply included it in the crypto fee column. However, because CB reports the sell transaction size as exclusive of fees, rp2 thought I was selling more crypto than I had (and correctly throwing an exception), as the original size + the crypto fee size was a greater quantity than what I bought.

To ameliorate this, I changed the sell size qty. to be = (sell size qty. - crypto fee) such that their sum was equal to the original sell size qty. This is because CB charges their fee in USD off the top, but they don't change the size of the order in the transaction report. In the above screenshot, CB would sell 10 XYZ, but only give me the profits of 9.96 XYZ (which ties into the OP about deducting fees from proceeds) but report it as 10 sold. Hopefully that all made sense!

Thanks again for the great project and hard work you put into it.

[eprbell]

I'm working on a fix for the missing deduction you reported, but it's trickier than I thought initially: it has interesting implications on various corner-case scenarios in the code, so it will take a bit longer to resolve.

As for the fiat vs crypto fee issue, I gave it some more thought and I believe the existing API uses the correct model:

• InTransaction (buy) already accepts fiat fees: this is because when you buy crypto you do it with fiat and a part of the fiat will be the fee, so having the fee expressed in fiat is the correct mental framework here.
• OutTransaction (sell) accepts crypto fees (but optionally allows fiat fees): if I want to sell some crypto and I don't have any fiat around I can still go ahead and sell. The fee will come out of the crypto I am selling. So, since fiat is optional in this operation, I think having the fee as crypto here is the correct mental framework. I understand that some exchanges may describe the sale fee as fiat, but that is a peculiarity of their format (there are plenty of peculiarities in reports from exchanges :-) ). I think it's important to capture the correct semantics rather than trying to accomodate every exchange format directly at the API level. If this requires conversion from fiat to crypto, that's ok. The conversion could be performed automatically by importers (like rp2-conv by @h3rb) because they have to know all the format peculiarities of the various exchanges to begin with in order to bring in the data.

[eprbell]

The missing deduction problem has been fixed in the latest version (v0.9.10). I added two new unit tests to make sure this
doesn't regress: see input/test_data3.ods, sheet B1 (your original example) and B2 (a slightly more elaborate one). Let me know if you see any more issues with this. Thanks!

[eprbell]

Closing the issue.