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

Ah okay thank you! I wouldn't see why it wouldn't be allowed in my country (for tax purposes) since it would be the same amount whether its 1 transaction or multiple. Just trying to save money and not upgrading to get more transactions.

Thanks again for the help!

@Andreas
Great, thanks!

@bitdogg
We are working on this topic already. The withdrawal transaction is not needed. You need to delete those withdrawal transactions manually. Only the staking (income) transactions are needed. Thank you for your understanding and patience.

I have been using the Kraken API for ages and just started staking recently. Each time a staking reward posts to my Kraken account I see 2 transactions in CoinTracking. One is a "Staking" type tagged to group "Kraken Staking" and the other is a "Withdrawal" type tagged to group "Kraken Ledger". Both transactions are the same amount so they net to zero. The most recent occurrence was yesterday 2021-01-30. I'm not sure if this issue is related to the fix above, but why is this extraneous "Withdrawal" transaction being imported?  Thanks.

@vampyz
You are welcome.
Yes, this is possible - if it is allowed within your country (tax laws).
You can summarize them manually per day/week/month/year to one entry and set a start data to your API job after you did that to avoid re-import of the deleted transactions.

@Andreas thanks! That's what I figured for the Kraken question, but I appreciate the advice of adding a label to separate it.

For my 1 Kraken account, it gave me thousands of inputs due to it importing rollover fees, margin fee and margin profit. Would it be okay to make 1 input for each of those things instead of having hundreds of them? Meaning, for all the rollover fees I would add them all up, delete them and then make just one input for all of the rollover fees for a given year.

Would this work? I'd imagine it wouldn't affect my calculations.

Thank you

@vampyz

Yes.
1. add API jobs for each - Coinbase and Coinbase PRO. And "Balance by exchange" is the report to check the "imported" balances vs. the Live (real) balances.
2. add API jobs for each account you have at Kraken. You can add a labels to each job to separate both within your reports.

Hello I had 2 quick questions. My first question is, for coinbase and coinbase pro, is there anything special I need to do when using the API to import everything? I read on reddit that they can do duplicate orders, but I also recently found that if you go to "Balance By Exchange" that you can see errors easier. Should I just do the API for both normally and then go to "Balance by exchange" to see if there's any coins that have positive or negative values?

My next question is, I currently use 2 Kraken accounts (since you cannot long and short at the same time, so 2 accounts are needed) so I assume I'd have to input the API for both correct?

Thanks! and sorry for the dumb questions,
Vampy

@asdsvsdf
Yes we are already working on the black theme. It will be available within next 2 weeks latest. Thank you for your patience.

Just noticed the themes changed and the dark theme is now blue! Is there any way we could get the old black theme (I think this is Classic but Dark/Black) as an option again? Much prefer black over blue, thanks!

Thank you for your feedback. We add all this to our improvement list.

No point in separating Gemini imports by date, since all orders will have the same problem.  It's really stupid for them to do it this way.  I will have no choice but to turn off Gemini API imports.

Cointracking should add a feature that will allow the user to consolidate trades by selecting imported transactions and pressing combine, which would automatically calculate total cost and average price.  You can use that as layer 2 data while still keeping the original data on your servers to avoid creating duplicates in future imports.  Another way to make the customer's life easier would be to enable two views for the user: 1:1 import view and consolidated, i.e. "sane" view.  Please pass this on to your product team.

We import them as the API of the exchange provides your data 1:1. So if an order is separated in fills then we import them separately as each of them has a unique tradeID.

You can combine those manually into one transaction if you wish while putting the sum of those into one transaction and then delete the others. To avoid re-imports please set a start date to your API job as described here: Create and delete API Import Job (https://cointracking.freshdesk.com/a/solutions/articles/29000031154?lang=en)

Please create backup of your data beforehand and regularly as described here: Create backup, restore or export your account data (https://cointracking.freshdesk.com/a/solutions/articles/29000031008)

Hello.  My Gemini limit order (via API) is shown on CoinTracking as broken up in a huge number of transactions.  Each fill is considered a separate transaction, which is kind of a bizarre way to do it.  How do I combine these fills into a single transaction, per original order?

You are welcome and thank you for the great feedback.

I did check your case and added this into a test account, but everything is fine as it should.

If you set a custom price then the asset value will be calculated based on this. And this is shown on the gains page of course.
You can edit the asset value manually as outlined before you would see this reflected on the gains page as well.

We suggest to edit the asset value using the counterpart purchase/sell value and use the custom price in addition which reflects the current price of the non-listed asset.

Thank you! I appreciate the prompt responses to my questions (despite there being a lot) and will be in touch again if any further questions come up. Thanks again, you rock!

EDIT: I think I found a bug with custom tokens that don't have prices listed automatically. I added a trade for 7000 tokens of a non-listed currency for a specific amount of LINK but the cost basis is totally wrong for some reason, even when considering the current price of LINK (the cost basis is way overestimating my cost per unit which in reality is almost a third of the calculated cost basis, to the point the system seems to imply that LINK is worth almost triple it's current value).

Completely deleting all trades related to this token and reimporting them via the export tool seemed to fix this... I believe the bug is related to the custom price, and the bug happens regardless if 'best price' is checked or not. If I set a 'custom price' for the token then it completely destroys my cost basis forever going forward, even if I delete and replace the 'custom price' in the future. This seems like a bug since this price should only affect the 'current' price, not previous cost bases which should always be determined from trade value of the sold coin

To repro:

1) On a fresh cointracking.info account, add a trade for buying 7000 SRT by selling 40 LINK (SRT is a fake token, but the point is the bug is with non-listed tokens that have the ability to add a custom price, so feel free to pick any other acronym that doesn't resolve to a real token)
2) Go to dashboard and recalculate trades
3) Go to unrealized gains and losses, observe the cost basis for SRT and note it (will likely be around 10-15 cents (USD) given current LINK prices)
4) Go to 'Enter coins' and under 'others' click the blue $0.00 next to 'SRT' to define a 'custom price'
5) pick a price higher than your cost basis (so if your cost basis is .14 cents (USD), change the best price to 1 USD). It does not matter if best price is checked or not
6) recalculate trades
7) go to unrealized gains and losses, notice the cost basis has also changed to be much larger than it should be

I believe the cost basis shouldn't change if you change the 'best price' and this custom 'best price' setting should only affect how it's currently tracked, while the gains and losses should only take trade values into account (i.e. the trade for 7000 SRT via 40 LINK should have the cost basis defined by the value of LINK at the time of the trade). thoughts?

otherwise i'm not sure what the point of this feature is, since it seems to override the cost basis which should be directly calculated from trades but the wording around it implies this is for tracking the current price of a token when it doesn't have a price automatically fetched by cointracking.info

The workaround is to add the transactions manually using the LP-token as outlined before.
As long as this token is not listed on any price source you need to add a custom price (see "non listed asset" FAQ).

If you add the fee correctly as described in the FAQ they are subtracted from the balance of course.

to clarify, I'm not talking about the Uniswap token, I'm talking about the Liquidity Pool (LP) tokens provided by Uniswap when you provide liquidity (UNIV2). as an example, these two LP tokens are both marked UNIV2 but the note on etherscan says they represent different pairings and they have totally different supplies, holders, and values. as such not sure how cointracking.info will be able to track each individual LP pair:

https://etherscan.io/token/0x9973bb0fe5f8df5de730776df09e946c74254fb3
https://etherscan.io/token/0xb4e16d0168e52d35cacd2c6185b44281ec28c9dc

thanks for the clarification about 'other fees', I didn't see there was a dropdown for other advanced types which includes this

Makes sense fees are included in trade cost basis and that's why they don't show for tax reports. However, I still think it's odd fees don't get subtracted from total values on the dashboard. This seems like a huge bug that would cause deviations over time from the dashboard values and reality

I'll open a ticket, I think this is a critical issue (specifically support for liquidity pools) that needs to be added and may be something that pushes me to a competitor that does support this since otherwise I'm not sure I can be confident in my return going forward if cointracking.info doesn't directly support it and requires workarounds to make it work

@asdsvsdf

Yes UNISWAP has the ticker "UNI2".

We are working on a solution to import those transactions automatically. It depends on the API for the ETH chain.
For now you need to adjust those transactions manually as outlined before.

"Other Fee" is available as own transaction type.

The trade fees can be found here https://cointracking.info/fees.php - filter for "trade" and the year you need it.
And please check this FAQ for adding fees: https://cointracking.freshdesk.com/en/support/solutions/articles/29000007202-entering-fees

We would appreciate if you send us an E-Mail at [email protected] or open a ticket with these information to check your account individually if needed.

Also, I think I just found a bug on the tax report system: when I generate a tax report for any year, the fees section will only include fees from withdrawal and deposits and doesn't include any trading fees. If I go to the trading fees page on cointracking.info I see this is tracked there properly, but why isn't this being included in the tax report fees section? Are fees being automatically included in the cost basis for individual trades?

Regardless, I think this is a case where having the 'Other fees' category be selectable on the UI would be helpful, as for some things (i.e. giving Uniswap permission to trade some currency on my wallet, fees for adding to liquidity pools, fees for delegating/staking) it's unclear how to register fees only, and registering them with the 'trade' type would theoretically leave them out of tax considerations

EDIT: I think I found another bug, right now as I edit fees for existing trades I'm noticing this isn't affecting the totals on the dashboard. Is this a known issue? Seemed to be working fine a minute ago but now is not properly updating fees (for example, I have an entry for 'staking' but as I change the fee from 0 to huge values the token amount on the dashboard does not change at all...) It almost seems like the totals on the dashboard don't actually subtract fees from trades at all and are completely dependent on deposit/withdrawal for generation. Is this correct?