Topic: CoinTracking - Profit/Loss Portfolio and Tax Reporting for Digital Currencies - page 100. (Read 121677 times)

Can you explain why it has this offset? What's special about these fees compared to all of the other fees that are not showing up?


Realized Gain / Loss: 1 USD is showing whether I check the box or not. Are you saying this is wrong and needs corrected? I still don't understand why it's showing at all regardless of whether the box is check or not.

@hessenbob:
Your answer can be found in the 2 lines of text at the bottom of your screenshot
Just activate the "Add Deposits & Withdrawals to remaining amount" checkbox to get the same values as shown on your dashboard.


In your balance it must be exactly 0, as it is calculating all deposits and withdrawals as well.
Only the Realized will have a .01 offset if the "Add Deposits & Withdrawals to remaining amount" checkbox is not set.

Realized and Unrealized Gains -> [X] Add Deposits & Withdrawals to remaining amount -> Balance: 0 DASH | Realized Gain / Loss: 1 USD
Yes, this one is correct, but the PnL is still calculated from trades only.
I will try to adjust it soon.

Dario

Dario,

I have attached a modified screenshot to show the problem.  I will start a ticket as well. Hope we can figure out the issue.
http://imgur.com/a/zaf9e


if I understand correctly, the remaining amount should match the amount on the dashboard, as any sales will be "Realized Gains" or "Realized Losses"

@Dario:

Thanks for taking the time to explain this with examples. The wrong balance (nonzero) appears to be showing fees only from manual entries from Wallet A to Wallet B. I now see in your docs for Realized and Unrealized Gains that this can occur:

Let's say:

A> I have bought 1 DASH for 100 USD from Exchange A.
B> I then send this 1 DASH from Exchange A wallet to Exchange B wallet with transfer fee of .01 DASH.
C> I then receive .99 DASH to Exchange B wallet.
D> I then trade .99 DASH for 100 USD on Exchange B (so now I have 0 DASH).

A> Type: Trade   | Buy: 1 DASH   | Sell: 100 USD   | Fee:   | Comment: Bought 1 DASH from Exchange A
B> Type: -OUT-   | Buy:   | Sell: 1 DASH   | Fee: .01 DASH   | Comment: Sent .99 DASH to Exchange B
C> Type:  -IN-   | Buy: .99 DASH   | Sell:   | Fee:   | Comment: Rcvd .99 DASH from Exchange A
D> Type: Trade   | Buy: 100 USD   | Sell: .99 DASH   | Fee:   | Comment: Trade .99 DASH for 100 USD on Exchange B

Realized and Unrealized Gains -> [  ] Add Deposits & Withdrawals to remaining amount -> Balance: .01 DASH | Realized Gain / Loss: 1 USD
Realized and Unrealized Gains -> [X] Add Deposits & Withdrawals to remaining amount -> Balance: 0 DASH | Realized Gain / Loss: 1 USD

I don't understand why the .01 DASH TX Fee is showing in Balance or as Realized. Can you better explain what this means and why this is done this way?

I've illustrated this in a public test portfolio with just these 4 entries above where I'm hoping you can see this... https://cointracking.info/portfolio/allanster_test -or- here is the CSV format if you want to verify behavior...

"","Type","Buy","Cur.","Sell","Cur.","Exchange","Trade Group","Comment","Trade Date"
"","Trade","1.00000000","DASH","100.00000000","USD","Exchange A","","Buy some DASH","23.06.2017 07:06"
"","Withdrawal","-","","1.00000000","DASH","Exchange A","","Sent DASH to Exchange B","23.06.2017 07:10"
"","Deposit","0.99000000","DASH","-","","Exchange B","","Rcvd DASH from Exchange A","23.06.2017 07:10"
"","Trade","100.00000000","USD","0.99000000","DASH","Exchange B","","Sell ALL of DASH!","23.06.2017 07:30"

@allanster:

Yes, fees are already included in the buy or sell amount.
Using an exchange import, CoinTracking will add or subtract the fee from the right value.

Let say you have bought 1 BTC for 2500 USD on Kraken and you have paid an additional fee of 25 USD, CoinTracking will import:
Buy: 1 BTC | Sell: 2525 USD | Fee: 25 USD

Let say you have bought 1 BTC for 2500 USD on Bitfinex and they have taken a fee of 0.01 BTC from your "buy", CoinTracking will import:
Buy: 0.99 BTC | Sell: 2500 USD | Fee: 0.01 BTC

The values "Buy" and "Sell" are always the real amounts you have paid or received.
The "Fee" field is just a note and does not have an influence on the "Buy" or "Sell" value.

Best, Dario

Thanks Steve for this answer. Wow, so now I'm more confused than ever. I thought I had read in the documentation that fees were included in the amount field and could also be additionally and optionally added in the fees field. Your post indicates I am doing this correctly. I assumed that the mapping of the manual imports from each exchange had already been worked out. So that isn't the case? Definitely this needs to be addressed and I agree a table would be the answer. Same for timestamps.

Also, none of this answers why CoinTracking shows zero in Balance (which it should for these I outlined below), yet Realized and Unrealized Gains shows greater than 0. If I did something wrong both should be off I would think, but not just one of them (Balance vs Realized and Unrealized Gains).

wow great explanation there mate, I think its really useful to know how to use the system properly and with this, it would be a big help to those who really in trading most of their investment as it will help them to properly set It up one by one and knows what the profits or loses as we move forward for more bigger investment to follow, thanks Dario.

Hey,

I don't think your tax authorities will only count your crypto->fiat trades
Usually you need to pay tax on each trade.

But at the end, your calculation would have the same result as the current calculation.


Example using our current method:
Buy: 1 BTC for 1000 USD (no gain here)
Buy: 10 ETH (value at transaction = 1500 USD) for 1 BTC (gain of 500 USD [1500 - 1000])
Buy: 2500 USD for 10 ETH (gain of 1000 USD [2500 - 1500])
Total gain = 1500 USD

Example using your method:
Buy: 1 BTC for 1000 USD (no gain here)
Buy: 10 ETH for 1 BTC (no gain there as it's not a fiat sale)
Buy: 2500 USD for 10 ETH (gain of 1500 USD as the initial cost basis was 1000 USD [2500 - 1000])
Total gain = 1500 USD

Assuming all sales have been short-terms.

Best, Dario

Allan,
Here's the deal with Fees: At this point in time CT treat fees as a "memo only" kind of entry. Entries in the Fees column have NO IMPACT on anything. Well, almost no impact. There is a report that can be run that tells what the fees cost in USD or BTC and also will tell you what the cost was at the time and what the cost for the same amount of "coin" would be at present. Anyway, if you have a transaction that costs something to complete, you would show the amount OUT of the sending site the actual amount "spent" to send it, which would include the fee. Then, on the receiving end, you would show the IN amount as the OUT amount minus the fee. That's the straightforward part.    Here's the fun part. Different exchanges/wallets treat fees differently. Some include the fee in the "cost" and others you have to add the "out" amount and the fee together to get the true cost of the OUT. Others still report fees in the fees column in a whole different currency and actually reduce the balance of that currency! (Bitshares does this). I have taken to putting a whole separate "OUT" transaction to reflect the fee in the spend column

I've recommended to Dario that he start a table of wallets & exchanges that would indicate how the fee is handled by each and then use that table to drive the way CT treats/corrects the imports. This same table could be used to keep track of how an exchange reports transaction times and adjust them all to some standard such as GMT or the User's local time. Then there is the issue of who maintains the data in the table. My guess is the best way to maintain that table would be to maintain it for the users and then CT folks would only have to respond to issues. If the users were maintaining such a table, some would no doubt mess it up and then blame CT for it. Setting up the table initially would be a big job, but should be reasonable to maintain after that.

Dario is fully aware of all these issues and is working on it. Cryptocurrencies could reasonably be compared to the "Wild West", and these guys are working to keep accurate tabs on transactions where there is no standard. People who post here that a user could just as easily keep all this on a spreadsheet just doesn't understand what this product can and will do.

Steve

Steve

Keven, thanks for answering that. I've dealt with this matter when bulk analyzing email headers for work (don't ask), and know it can sometimes be a real pain.



Steve,

Thanks for thoughts on wallet address. I'm way to lazy for manual entry. The workaround I've come up with for eliminating possibility of duplicates from imports from post editing is really simple, I open the CSV file I'm getting ready to import first in a simple text editor and delete previous entries by date, save, and import. I'm manually correcting time stamps in CSV files as well because it's easier/faster to do so there.

Where I'm currently stumped now is on fees showing up in Realized & Unrealized Gains and it makes me think I'm doing something wrong with my wallet transfer entries. Or certainly possible I just don't understand, maybe report is showing me "potential" gains for fees? Doesn't seem logical. For example, say...

- I bought and shot 1 DASH from Poloniex to Bittrex with .01 TX "FEE"
- I have an "OUT" entry for 1 DASH with "FEE" of .01 DASH
- I have an "IN" entry for .99 DASH
- I traded ALL my DASH for BTC on Bittrex

Now, my balance for DASH shows 0, but on Realized & Unrealized Gains it shows .01 DASH. I have only done two of these types of transfers. The other is an "Exchange A to Exchange B transfer" of all of my LTC and then traded all for BTC. My LTC balance shows 0, but the LTC TX Fees appear in Realized & Unrealized Gains (same as DASH). So I know where the entries are coming from, I just don't know why. Please correct me if I'm doing something wrong. Any ideas?

Thanks,
Allan

My workaround for now is to turn off all imports and put in all the trades manually. I know that could seem like a lot of work, but it's really not. I used the import abilities to get started and then turned them off for the very reason you mentioned. If you modify imported transactions, there is a good chance CT won't "see" that it has already imported it and do it again, which makes a complete mess. So, until Dario comes up with a solution that puts all the imports on the same time-base, that's how I'm doing it.

As to whether you should put addresses in the comments is completely up to you. One thing I do recommend is if you are using ShapeShifter that you keep a file (I use PowerPoint) of screenshots of the transactions, because there is no way to reconstruct what happened.

Steve

Hey @allanster,

thank you for your interest.

The description that was submitted by Steve (thanks ) is totally correct.
You need to switch between the Cryptocurrencies and choose the one you´ve created the file for.

We are currently working on a solution for the timestamp problems, this could take some more time to implement and we hope this will solve all current issues.

Sorry for the inconvenience.

Best regards,
Keven

I guess you have a good idea, but what is the point when, with the current set of regs and standards, you have the clients doing to heavy lifting and you are just printing the info in a little nice graph.

Steve, thanks for the tip. That will be a helpful workaround. It only affected 2 entries so I just manually changed them. Any insights on working with the different timestamps. I noticed Coinbase time had a 0700 field I'm guessing means +7 hours for UTC. Poloniex time is also different. When I import entries from these exchanges they are out of order and I am having to manually correct them.

Another paranoia I have is I've been annotating wallet addresses in case I ever need to "prove" something. Is this overkill?

It's not a bug per se. It's a shortcoming in their exports. The exports don't specify inside the file which currency is being exported. I think they name the file correctly, but CoinTracking isn't looking at the file name. After you drop the file onto CoinTracking, CT will give you a preview of the import and then you have to push import again to finish. BUT before than last step, there is a pull-down you may not have noticed that lets you select WHICH currency is being imported and the default is BTC (hence the sudden wealth).

What you need to do is click on the pull-down, click the currency this import represents and then click "SAVE". Then finish the import.

It may be simplest to just delete all the imports you have done from wherever and start over.

Steve

Coinbase has a bug, the two CSV files they sent me for ETH and LTC purchases both indicated Type:BTC, took me a minute to figure this out, I briefly had a WHOLE lot more money in CoinTracking.

I reported bug to them but wouldn't expect this to get addressed any time soon so you may want to add notice on your instructions for Coinbase about this.

Greetings all, been lurking for 6 years so I guess it's time to get involved.

Dario - I'm evaluating your product and am blown away. I'm just getting into trading and am paralyzed with fear, not of trading, but of the tax man.

---
According to this Forbes article, EVERYTHING you do with crypto has tax implications in the US, so these individual transfers need to be reported as well (don't shoot the messenger):

4. Spending: Spending Bitcoin, whether you’re buying a coffee or a Dell computer, is treated just like selling. You record a short- or long-term capital gain or loss, based on your original cost basis and your holding period. (While this may seem onerous, see “Deciding Which Bitcoin Is Being Disposed Of” below for how to record these details.)

@hessenbob, thanks a lot.
Can you please create a ticket here https://cointracking.info/feedback.php and post your ETH address.
It's hard to say without any details.

It could be an internal or an unconfirmed transaction.

Best,
Dario

Hey @hessenbob,

thanks for submitting your problem.

At the moment I can´t say why this happens, but I´m going to speak to my colleague and we will see what could be the cause of this problem.
Please have patience, we´ll send an answer as soon as possible.

Thank you,
Kind regards,
Keven

Hi @DehiDehi,

thank you for getting in touch with us.
You are right, we still have some problems with the timestamps.

We are currently working on a solution for this problem and we hope to get it integrated over the next weeks.
Sorry for inconvenience, we do our best to solve this problem as soon as possible.

Thanks for your patience.

Best regards,
Keven