In order to upload your files into CoinTracker.Io you need to modify it to comply with the format expected. This is a generic sort of import and requires a fair bit of time to change the data in your import file. It is also heavily prone to error. To re-format 6 transactions it took me about 30 minutes. This would be impractical if I had hundreds of transactions. Here are the steps I needed to take to reformat the data.
Here are the rules for preparing your CSV file:
The tricky part here is that you need to be careful how you add sell transactions as they need to be put into the reverse of buy transactions. Here are the steps:
This is preferably not done in Microsoft Excel as Excel will automatically apply the computer's regional format to dates. If you're using Excel then change the format to a custom format of mm/dd/yyyy hh:mm:ss or convert the column to text format and then re-enter all the dates.
Various exchanges store currency symbols differently. For example Kraken stores Ethereum as XETC and Bitcoin as XXBT which doesn't conform to most exchanges (ETC and BTC respectively). You will need to convert these to the correct symbol otherwise CoinTracker.Io will not be able to import your record.
Instead of re-formatting the csv file as per the previous section, I just decided to add a new transaction manually.
Below is a list of realisations as calculated by both tax calculators which generally appear aligned in their cost basis and profit or loss. Both calculators are able to account for release currency adjustments and clearly show the gains and losses with the purchase and sale prices in your desired currency (in this case AUD - Australian Dollar)
The following is a list of realisations that differ from each tax calculator. An explanation is given under each comparison.
On the 3rd June, ETH was used to buy LTC so the above realisation accounts for the release of currency ETH. We effectively sold ETH the same time we bought LTC. The ETH source of funds were acquired on the 2nd June (using Bitcoin) at a unit price of 0.077224 BTC:
BUY ETH 10.9889 @ Unit price 0.077224 BTC: 0.8486 BTC or $6356.57 USD (@ $7490.60) or $8402.15 AUD
The release of ETH on the 3rd of June shows the following figures:
SELL ETH 10.9889 @ Unit price 0.080101 BTC: 0.88022 BTC or $6777.62 USD (@ $7699.9) or $8964.01 AUD
The unit price of ETHBTC rose from 0.077224 on the 2nd June to 0.080101 on the 3rd June therefore creating a profit realisation of $421 USDT or $561 AUD.
CoinTracker.Io potentially used LTC to come up with the cost basis for LTC. The price of LTCETH on 2nd June was 0.20695 and on the 3rd June was 0.20495 showing a lowering of it's value against ETH. While you received less total ETH because of the price variance, the price of ETH rose from 2nd June to 3rd June:
2nd June LTC 53.61795559 @ Unit price 0.20695 ETH: 11.096 ETH or $6422.5 USD (@ $578.8) or $8454.14 AUD
3rd June LTC 53.61795559 @ Unit price 0.20495 ETH: 10.988999 ETH or $6783.5 USD (@ $617.3) or $9163.16 AUD
As you can see above the unit price for ETH rose by about $39 making the overall realisation a profit not a loss. The most likely scenario a loss was recorded in CoinTracking.Io is that ETH was valued both times the 2nd June unit price of $578.8 USD
2nd June 11.096 ETH or $6422.5 USD (@ $578.8)
3rd June 10.988999 ETH or $6360.4 USD (@ $578.8)
loss of $62 USD ($80 AUD)
It's possible that CoinTracking.Io used another method for deriving the lower cost base but I can't find it especially since the major coins rose between that period not fell. It seems that a loss here cannot be justified.
The example data intentionally includes some errors to see how the tax calculator handles these errors. One is the purchase of XMR using BTC on the 1st Jan 2017. CoinTracker.Io shows a warning message indicating that there's no purchase history for BTC.
You see there's no balance of BTC to buy XMR, therefore there's no BTC to draw down. In Chainometry these are known as Unfound Balances and can be fixed using the instructions here. The issue with CoinTracking.Io handling of the problem is that it automatically assumes that the cost basis for BTC was 0 and therefore the release of BTC to buy XMR resulted in a profit of $4,014 AUD.
This profit may or may not have been the case. You may have forgotten to add a purchase or deposit record or there may be missing data on the exchange. In any case, automatically classifying as a profit can be dangerous and lead to overpayment of tax. Chainometry prefers not to add these ass a profit and gives you a list so that you can deal with each problem one by one.
The record above indicates that there was an issue buying XMR with details about the quantity and the value of the missing balance. In this case, $3,804 AUD. To fix this problem, simply click on the 'Add balance to your account' link and you will be presented with the following window:
Here you can either accept the cost base of 0 (thereby adding a profit realisation to your account) or add a cost base. The maximum value of the unit price is restricted to the unit price of the currency as of the date of deposit. You can get more information about visiting data issues. In the above example, if you added a cost base of 963.9 USDT you would not incur any profit or loss realisation and the unfound balance would be cleared from your account. The important thing is that you have complete control.
The major stumbling block to using CoinTracker.Io is the way CSV imports are handled. Having to reformat your exchange exports to comply with their expected format is far too time consuming and would not be practical for even a small number of trades. You would be better off using the API import offered by the web site. I have not tested this as alternative method.
This leads to a discussion about what it really means for a crypto tax calculator to support an exchange.
CoinTracker.Io advertises that it supports over 300 exchanges. The fine print is that you must reformat all of you export files to conform to their standard import CSV. You also need to ensure that the currencies are standardised to the list of currencies that are supported. The challenge for all crypto tax calculators is that exchanges often store cryptcurrencies names differently (and combines them differently as well). In order to calculate the data properly there needs to be a standardisation process to ensure that cryptocurrency names are uniform. This is a mammoth task if done properly. For the user to transform their data export files to a standardised set of currencies supported by a crypto tax calculator is a big task and in my opinion not a feasible option. You can read more about how Chainometry supports exchanges here.
Calculation issues also needs to be investigated further to determine the methods used for release currency adjustments. Finally, a better approach can be used when correcting issues such as a missing balance. Automatically adding a profit realisation with a cost base of 0 can lead to tax overpayment.