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

I am not sure that I have an answer for this situation other than your workaround.

Although you might try selecting Transfer (last one in the dropdown) to solve your problem?
This creates two entries one in and one out which is what you have with a refund. Just use the same name for the in and the out exchange so in this case Customer 1 and Customer 1 (or any defining name) Just add the notes in the Comments column for future reference.
Check the result in the Balance by Exchange Report and it will be nil balance.
Good luck with it all.
Regards
Wayne

Allenstar
Thank you for taking the time to compile your post to me complete with the ATO link as well.

I do have a Pro account and I have created 4 'sub' accounts all inheriting the original Pro capabilities as you have suggested.
I do use 2 of these for testing and experimenting to try and understand how Cointracking 'thinks'.
The 1 BTC example was one of those which I am waiting to hear Cointacking Support's advice on as to why the different values appear.

I take your point on time as having a potential effect on values per se. The majority of my transactions were done through a couple of Australian exchanges but also do include other international exchanges so there will be some incorrect times I believe.
It would create even more unwanted complexity to this whole reporting scenario to start to convert all the different time zones from around the world to the local Australian zone that the account is nominated in. Until there is a simple fix for this I decided that I would have to live with this shortcoming if I was to continue to use this software as there are many more problems to solve first.
It would be a wonderful addition and improvement to the Cointracking software if in the future it could convert the time zone that the trade was completed in to the equivalent time zone in the locally nominated time zone of the account at the time when these transactions were being imported via .csv or API etc.
Obviously all the exchanges would have to provide that time zone information within their TimeStamp data that they generate but it is an obvious improvement.

The majority of my transactions are completed via fiat to crypto exchanges and the .csv export that is generated from the exchange comes complete with the actual local time zone and the actual total Sale Value in AUSD of both crypto to crypto and crypto to fiat transactions.  The problem is Cointracking does not import this column that contains the Total Sales Value of each of the transactions.  Rather it inserts its own version of Sale Value and a completely differing version of a Purchase Value into the Assets Value boxes and this then creates problems as mentioned in the 1 BTC post. Neither of these 2 Cointracking inserted Values agrees with the actual correct value supplied by the Exchange. Why, who knows? This then requires a whole lot of manual cross checking and ultimately editing of every transaction which is very time consuming and should not be needed.

The transactions that are imported from crypto to crypto exchanges come without any fiat values at all and so Cointracking supplies their version(s) of fiat values upon import. The problem is the Sales Value and the Purchase Value always differ and sometimes by a large percentage so this very fact calls into question that maybe neither of the proffered values are correct (putting aside the effect for the time zones for international exchanges which will just about guarantee that both values are wrong anyhow just on this point alone). Previously I have been deleting both of these Values and then using the coin Price Calculator to provide a single Value for insertion into both the Sales Value and Purchase Value boxes of each and every crypto to crypto trade. This is very time consuming and should not need to have to be done if the software did not generate multiple values in the first place.

I understand the basic tenant of 'Fair Value' as you have kindly outlined. I am currently awaiting advice from my accountant as the correct treatment of Gift/Tip coins such as airdropped bonus coins. Some of these are worth nil value at the time of receipt as there is no ready market quoted for them or they will not even list on an exchange util somewhere in the future, maybe. Others do have a 'Fair Value' at time of receipt. In the interests of keeping things uniform I have approached this by recording all these Gift/Tip coins with a Nil value and will use this Nil value as the cost base to workout the gain at the time of the actual sale of the asset and then pay Capital Gains Tax based on this.
I will be advised by my accountant and if he advises that I have to record a value at time of receipt then I will happily alter this approach. All up we are talking about very small amounts of money involved in these mostly 'rinky dink' airdrops buy I am mindful that I do need to be correct and accurate.
I agree with you that Cointracking is very powerful software working within the very complicated cryptosphere but it does have a number of shortcomings that I hope will be corrected in the very near future.
Regards
Wayne

i have a question,   i was thinking about buying the lifetime pro edition,  but i am confused about how many transactions it will cover.   it says  3500,   but the one and the two also say 3500, it makes no sense that they would all be the same but charge different prices.  so does it mean that i would get 3500 transactions in total say over 3 years or does it mean i get 3500 per year, so that essentially over three years it would be 10500 transactions? 

Now for my own question...

I sell a product or service and I receive cryptocurrency as income for that product or service.

I record the transaction as Income.

Some time later I discover the user has overpaid me, or sent the payment twice, etc.

I refund the user.

There does not seem to be a proper method for accounting for Refunds, I have tried and tested negative Income values, as well as every other possible idea. It seems that "Lost" is the only way available to account for this and IMO is not an accurate method (or description) for this scenario.

If a user sends me 1 BTC, then an hour later I refund their 1 BTC, then I don't want to report this to the tax authority, I have never actually realized a gain or loss and I no longer have the asset, it is a Refund. I'm not willing to accept or report the gain/loss in value for something that was essentially only "held" temporarily by me and then returned to it's origin.

As a workaround I am presently changing the Income to Deposit and itemizing the Refund as a Withdrawal so that the calculations are not done upon those 2 transactions. It seems ideally there needs to be a way to flag the initial Income transaction and the Refund transaction that a user would like to be ignored in CoinTracking's calculations.

What is your suggested method for handling these types of situations?

Wayne,

First of all I am just a user same as you, offering what is hopefully some constructive help. CoinTracking allows you to have multiple accounts, and they can be linked together, meaning only that you will see them each as tabs at top of parent account for easy access, but they won't interact or interfere with each other. The linked accounts inherit the same capabilities as your parent account. If you had Ultimate for example, then all of the linked accounts will inherit that status as well. So I would start with creating a 2nd user account and linking it to your main account. For convenience you can even use the same email address for additional account(s). I have my paid master account which contains all transactions from all sources, I then have several linked accounts which contain only transactions from each individual source, and finally I have 2 linked test accounts which I use for testing and learning the solution to various questions I encounter in my own use. This will allow you to sort out your issues in an isolated environment, as well as backup and restore different test scenarios to that test account environment. It will also allow you to switch between the various accounts without having to log in and out into each of them separately.

Time is one thing to watch out for. You need to insure that you have your transactions translating across timezones correctly. You may see that a transaction happened at 3am on the exchange but which 3am? Their 3am? Your 3am? UTC 3am? CoinTracking does a great job for the most part of handling all of this automatically for you, but you need to always keep an eye on things to ensure that if you have your account set to your timezone that the transactions you are importing are translating correctly to your timezone. Otherwise your "fair value" would be way off.

There are certain areas in CoinTracking that it relies on an average price across several exchanges to obtain "fair value". This is an accepted (and required) accounting practice in most parts of the world. In the US for example the user is free to choose what source they will use for "fair value" as long as it is within reason and the user does not deviate from that source for that reporting period. In other words, you don't get to pick and choose your "fair value" source as a means to reduce your tax liability. You can't use a "fair value" source that says bitcoin is worth more when you buy it and then switch to a different "fair value" source that says bitcoin is worth less when you sell it. Most countries accept (and/or require) you using this as your "good faith" attempt to accurately report gain and loss.

If you are entering transactions correctly, then your tax calculations should be correct. If you purchase 1 BTC from CoinBase for $5k and later sell it back to fiat on CoinBase for $7k, and you imported those transactions into CoinTracking, it will correctly calculate your gain as $2k. The "fair value" at those times may be different but in those transactions CoinTracking will use the actual fiat values reported from the fiat exchange and will be correct. In other circumstances where you exchanged BTC for LTC is where the "fair value" would be utilized. It must be done this way because the exchanges do not provide the fiat value at that time of those non-fiat coin to coin transactions.

Imagine your friend gave you a share of Apple stock and you later sold it on an exchange for $1k, what was it worth when you received it? It's actual value varies depending on where you look and when you look, but you can't just tell your tax authority "Well I didn't report that because there is no 'real' way to look up what it was worth at that moment I received it". That won't fly with them, they will tell you that you should have looked up the "fair value" and reported it.

I am not a financial advisor and none of this post is financial or tax advice, but your tax authority discusses "fair value" here and in my opinion agrees with what I have stated above:

"Fair value can be measured in reference to the:
quoted market price in an active and liquid market, if available
current or recent market prices for the same asset or similar assets
net present value (if an established cash flow can be identified)
depreciated replacement cost – for specialised assets that are not traded in an active and liquid market."

https://www.ato.gov.au/General/Capital-gains-tax/In-detail/Market-valuations/Market-valuation-for-tax-purposes/?anchor=Meaningofmarketvalue

I have tried multiple accounting solutions for cryptocurrency, most of those solutions cost exponentially higher, and my own experience has been they do not provide all of the key features necessary while CoinTracking does. Hope that helps.

Dominik thank you at least for responding here at long last, I do appreciate that. And yes I have been trying to get answers from you for a huge array of questions re problems and perceived bugs since as far back as December. The amount of man hours wasted with this process of finding, identifying, deciphering and correcting the inaccurate data which is introduced by Cointracking  is just unbelievable and it is still not right.
I might also add that despite my sending you screenshots and corroborating evidence for each of the particular unique queries a lot of these were never answered or answered unsatisfactorily in my opinion. The answers that were provided in a lot of cases did not address the actual question that I was posing. They were simply stock standard cut and paste answers without regard to the actual unique evidence in front of you. In the end I became so sick tired of trying to point this fact out to you over and over that I just gave up out of total frustration.

A case in point is your current answer to my question which I originally posted 11 days ago in which you have now simply cut and paste that same answer to me yet again. Could I ask you please to never send me that again as I have read it so many times now. To this end I have previously advised you that I only ever select the Transaction Prices method in an effort to reflect the real life transactional values and costs.  I am only interested in absolutes and accurate values not some incorrect value inserted by the software that has nothing at all to do with my transaction values. I have to submit my Tax return to the ATO based on the information in the final reports and it has to be ACCURATE as I do not want to risk going to jail for submitting wrong data to the Tax Department. Is that really too much to expect just to be accurate

My question again below was asking you to advise me what and why there are five different values appearing in Cointracking for one simple theoretical transaction to purchase 1 BTC . Could you please advise about each of these individual points so that I can try and understand how and why Cointracking does things this way so that I can then try and mitigate these introduced errors in each and every transaction entry.



The price referred to above in the dummy transaction was checked and retrieved at the actual time of the trade. If your Coin Calculator has some sort of inbuilt time lag and does not correspond to live dynamic values at any given {day:hour:minute;second} then it would be prudent to advise of this situation on the Coin Calculator page wouldn't you agree. Or if as I think that you may have advised earlier that the Calculator uses a different source for this data then I am not sure why you would want to introduce an alternative source of non dynamic price data other than what is already utilised elsewhere in Cointracking as this provides a greater chance of introducing discrepancies from these multiple data sources as there seems to be now?
There may be some technical reason for doing so that is not obvious to me or others but clarity would assist in customer understanding.
If indeed this Calculator just accesses a price at say one time of each day so say 5pm then there is the real risk that daily price fluctuations could be once again massive in the future and this would make a non dynamic price engine nearly worthless?

As I have previously explained to you that when I import transactions from an exchange that only shows the crypto values of transactions and not fiat equivalent values then  Cointracking inserts it's own two differing values in the 'Sale Value' and 'Purchase Value' boxes. So at this point in the process how do I (or anyone) determine which of these differing values are correct or even nearly correct as sometimes there are wide differences in the fiat values displayed?
So I choose to use the Coin Calculator to provide the one singular value that I then insert into both Sale Value and Purchase Value boxes in the records from these non fiat exchanges.
In cases where the import is from an exchange that does provide fiat values for the transactions I rely on their provided value and copy it from the Sales Value box where it appears automatically into the Purchase Value box.
Is there any reason why I should not do it this way when I am concerned primarily with being accurate ?


I used the Export button offered on the Enter Coins page to 'backup' all my entries to my laptop. It is obviously an .csv file which can only be opened in Excel or Libre Calc or similar and was simply saved to a .csv file in a folder. That same file was subsequently selected via the Cointracking .csv Import page and that is when the Timestamp Errors appeared in 86 of the 134 lines of records contained within that previously saved and UNEDITED.csv file. At this point there had not been any editing or changing of any of the records contained within that file but these errors where consistently appearing in the 20 or so times I tried to re-import this file that had been Exported from Cointracking with no editing at that time of re-importing. Why does this happen to some records and not to the others in the same file? You can go on believing that I have done something wrong here or you can admit to yourself that maybe there is a problem that requires fixing from your end. That's up to you you I guess.

When you say 'no asset values' are exported you are referring to just the 'Purchase Value' information as the 'Sale Value' data seems to be successfully exported and re-imported, is this correct?
Then despite the fact that I had gone through all my records prior to Exporting and made sure that the 'Purchase Value' and 'Sale Value' boxes contained the same identical values (as described above) upon re-importing Cointracking just wipes out all of my manual editing that was done to make sure that all the values were identical. No warning about this on the page that I could see either?

I do thank you for pointing out the Trades Backup facility as I was unaware of it and so will use this in the future instead, providing it works as hoped.
I trust that we can get these queries sorted out so that we can all benefit from what I still believe is fundamentally powerful software, albeit with some flaws that can be fixed hopefully.

Dear Wayne,

Since December we have received several tickets via our HelpDesk. Each time it was about the same topic that we explained to you over and over again.
But I will gladly explain the situation to you again.

Prices in CoinTracking
You can set the prices and how they are used in CoinTracking yourself. You already know the following FAQ article (I hope so): https://cointracking.freshdesk.com/en/support/solutions/articles/29000018289-gains-prices-setting-dropdown-/
The Coin Price Calculator uses the price at a certain time on that day. Your trade has certainly taken place at a different time that day, so a comparison makes no sense. We had already clarified this in a ticket.
You are welcome to send us another ticket with your test account and I will go into these values again.

CSV Import
The CSV export of the "Enter Coins" page can be imported again via the "CSV Import" without problems and timestamp errors. If you get an error message, you have either changed the format or edited the file with a program like Excel. We explicitly point out on the Importer page not to do this.
In addition, when exporting this CSV file, no trade ID and no asset values are exported.
This means that the asset values will be filled by our historical prices and duplicates are created if you have not cleaned up your portfolio before.
Please use the "Trades Backup" instead: https://cointracking.info/backup_trades.php

But you can edit the CSV file and specify a trade ID and asset values for the import. You can find all information under:  https://cointracking.info/import/import_csv/ ([Custom CSV information])

New problem here now unfortunately?
I have been able to find a workaround by myself and re-import all of  the 135 transactions including the Timestamp error ones back into Cointracking.

BUT when I open the Trade Prices report it shows that a lot of the transactions have had their "Purchase Value"s changed again by Cointracking.
These were the original records that I exported from Cointracking after having made sure that all the individual transactions showed absolutely NIL difference in 'Sale Value' and 'Purchase Value' by manually editing each affected transaction record before exporting them and saving the file to my laptop. It is this .csv file of the saved Enter Coins' transactions that I have re-imported today.

So the question is why does Cointracking do this when the correct information is manually entered in a lot of cases and then the records are saved?? Cointracking is obviously overriding the users data that the user has entered and saved?? WHY???

Then how is this problem then solved for the future as I have other records that I wish to export then later re-import them as and when needed??
I await some informed advice from Cointracking support

Ah Mr Cointracking nice of you to reply to SpringChicken, He is indeed a fortunate person to have received your attention.
It would be extremely nice and very polite if you would also address my outstanding queries that predate this query.
Especially this fundamental one which I reprint here for your easy access. This goes to the very core of the problems that are introduced by Cointracking into every transaction that is imported by .csv and deserves an answer so that we all know how and why this problem is introduced. Is the reason that you have not bothered to respond to my query because you do not have an answer to why there are 5 different values for the one transaction, maybe??

Hello
I have been trying to get Cointracking to function accurately since December with very mixed results unfortunately.
So I thought I would go back to basics and start again in trying to understand the workings of this mysterious software.
To this end I set up a new empty account and have been trying some dummy entries to try and understand how this software works but I am even more confused now.
Does anyone have any valid explanation as to why there are 4 different values that appear when I simply enter a sample buy transaction as shown below?

Interestingly and very confusingly Cointracking provides 4 differing values for a 1 BTC purchase on the nominated date and time which just serves to muddy the waters and potentially produce reports that are wrong. Check it out yourself but in my example below this is what I found for the

1 BTC dummy purchase on 24 /02 /2019, I Entered $5898 as the Cost and $898 as the Fee and Home as the Exchange

$5898    The actual fiat cost value entered into the Enter Coins page (copied from LiveCoinWatch), Populates to the Sales Value box

$5870    Cointracking automatically inserted this figure in the Purchase Value box disagreeing with the above Sales Value box? Why?
$5535    The Cointracking Coin Calculator for 1 BTC on the purchase date value showed this figure when I checked out of interest. Why?
$5875    Showed as the current value of 1 BTC in the Summary box on the Enter Coins page at the exact  time of the purchase entry? Why
               

Next I checked the Total Realised and Unrealised Gains Report and this report uses the incorrect $5870 that Cointracking inserted automatically as a Cost Value to do the calculation which can only ever be wrong!.
This is further complicated and messed up beyond comprehension when I check the Tax Report / Closing Position Report which shows a 5th differing Cost value now inserted for this one simple purchase transaction of $5786. ?

Is there any wonder that confusion reigns supreme within this software when you have now 5 differing values for 1 BTC at the same date and time. Every transaction entered for every coin will be likewise affected so it would be required to be be very careful and triple check everything as there are potentially so many mistakes.   

The only factual amount was the $5898 that I theoretically paid to buy the 1 BTC and believe it or not the Cointracking software totally ignores the one and only cost value that matters. How could this software ever be relied on to produce correct reports when it uses so many differing values for the same coin?
There has got to be a better more realiable way to manage crypto surely.
I have applied extensive manual editing to correct these mistakes this but it is so labour intensive to make it not really worth the time especially when Cointracking could and should correct their introduced problems so that all of this manual editing is not required.

Maybe I am missing something here so I am open to any advice as to why there should be anymore than the one and only correct cost value used for all calculations.

Hopefully someone very knowledgeable from Cointracking will chime in here and explain this for all of us.

Hi SpringChicken,
I recommend you to explore our software, documentation and FAQ section. Many of your questions can already be answered.
However, I am happy to answer your questions here 

1. you can access our official Youtube channel via the following link:
https://www.youtube.com/channel/UCaCaTC7W9JeuFW34T_OC-wQ
On Youtube you can find many more helpful videos from diligent users.

2. can you please specify this question in more detail?

3. we have a BTC, ETH and Altcoin Wallet Importer that supports many (not all) Altcoins.
Go to "Enter Coins" -> "Wallet Import" in the menu.

4. all transactions (also deposits and withdrawals) should always be entered. You do not have to enter the binance transactions manually. You can import them via the Binance CSV or API Importer:
https://cointracking.info/import/binance/
https://cointracking.info/import/binance_api/

5. The easiest way is to check the transactions for completeness and correctness.
If you are stuck, please send us a ticket via our HelpDesk (https://cointracking.freshdesk.com) and we will check it in your account.

6. the same answer as answer 5. probably the sales or withdrawals are not registered.

7. This question is answered in our FAQ:
https://cointracking.freshdesk.com/en/support/solutions/articles/29000018053-entering-editing-renamed-or-re-branded-coins-e-g-ans-and-neo-/

8. -

9. in which you create a single tax report for each year. You can select the year when creating the report.

Further to my import problem as above I just imported the records to see what would happen. It imported 50 records but not the one with the Timestamp error. I also clicked on see the Raw Data and this reveals that all the dates and timestamps are present and correct in the raw data but Cointracking is not importing them all?
Does anyone have any clues as how to solve this bug?
 And or it would be very nice if someone knowledgeable from Cointracking support finally made an appearance with some advice on their software.
As an aside I tried to import these same records a second time and the software reimported the same 50 records and at the same time showed a message that there were 'No Duplicated Records"? I then had 100 records which were the 50 records DUPLICATED to show 100 records? So it seems that one cannot rely on the Cointracking software to even identify duplicate records when importing, amazing but not surprising I guess. 

Hi. I am new to Cointracking and have a few Qs.
1. Are there video tutorials on how to use the software properly?
2. You do not specify in ur documentation, but does ur software require import of wallet addresses/holdings in order to match up buys/sells and short vs long term?
3. If yes to 2, then can u tell me in detail how I import coins addresses held on Ledger Nano S, Jaxx, and altcoin wallets like Aion, Factom, Ontology, Vechain?
4. When entering coins purchased on Abra manually, do I also need to input the transfer out to Binance to purchase altcoins? Is that under the transfer category?
5. I have noticed at first glance that many of my balances r incorrect. For ex, you say I have much more Eth than I actually do. This tells me you have not accurately noted when I sold eth to purchase altcoins. How do I reconcile this?
6. There are several coins that show a balance but I no longer own. How do I reconcile this ?
7. Several years back I purchased Antshares before it became NEO. You software shows I still own it as AnS. What do I do?
8. In general, it seems the only way I can look for errors is on the unrealized gains/realized gains/ loss page. Is there a better way as today, I only know the balances of each coin I own and the average cost from a separate software tracker.
9. How do I generate tax reports for 2017 and 2018 separately? Thank you for your time!!!

I originally downloaded from my account my Enter Coins data via the Export to .csv button to my laptop.
Now a week later I am trying to re load this same .csv report back into my Cointracking account and I am getting this garbage Timestamp Error messages as shown below.

Error: We couldn't find a timestamp. This trade will not be imported

Import Report:

Validation: Datasets in import file: 135, Transactions: 135
Notes: Duplicate transactions found: 0
Errors: Empty timestamps: 86, Empty values: 0


It is the exact same .csv dataset that was exported by Cointracking and now Cointracking will not import all the records back in?
It is saying there are 86 timestamps missing when they are not missing? They are ALL formated in the EXACT same date format as the 49 records that Cointracking seemingly will accept to import. This is just crazy and so time consuming trying to troubleshoot garbage problems like this that should not exist! I have tried reformatting and clearing the formatting then reformatting the Date column but nothing works!
I have tried cutting the Date column and pasting into a new sheet then changing the Date format and pasting the new Date column back in over the old but no!!!!
 
Does anyone have any advice on how I can solve this this whilst I wait for a timely response from someone from Cointracking to chime in here.
I have not lodged a Ticket with CT as extensive previous experience shows me that it is a complete waste of time and effort.

 

Ok so it has now been 7 days and there is still no advice from anyone at Cointracking as to how or why this happens?
I am pretty sure that others apart from myself would be interested to know why CT inserts so many incorrect values for 1 simple purchase?
Disappointing to say the least.

Hello
I have been trying to get Cointracking to function accurately since December with very mixed results unfortunately.
So I thought I would go back to basics and start again in trying to understand the workings of this mysterious software.
To this end I set up a new empty account and have been trying some dummy entries to try and understand how this software works but I am even more confused now.
Does anyone have any valid explanation as to why there are 4 different values that appear when I simply enter a sample buy transaction as shown below?

Interestingly and very confusingly Cointracking provides 4 differing values for a 1 BTC purchase on the nominated date and time which just serves to muddy the waters and potentially produce reports that are wrong. Check it out yourself but in my example below this is what I found for the

1 BTC dummy purchase on 24 /02 /2019, I Entered $5898 as the Cost and $898 as the Fee and Home as the Exchange

$5898    The actual fiat cost value entered into the Enter Coins page (copied from LiveCoinWatch), Populates to the Sales Value box

$5870    Cointracking automatically inserted this figure in the Purchase Value box disagreeing with the above Sales Value box? Why?
$5535    The Cointracking Coin Calculator for 1 BTC on the purchase date value showed this figure when I checked out of interest. Why?
$5875    Showed as the current value of 1 BTC in the Summary box on the Enter Coins page at the exact  time of the purchase entry? Why
              

Next I checked the Total Realised and Unrealised Gains Report and this report uses the incorrect $5870 that Cointracking inserted automatically as a Cost Value to do the calculation which can only ever be wrong!.
This is further complicated and messed up beyond comprehension when I check the Tax Report / Closing Position Report which shows a 5th differing Cost value now inserted for this one simple purchase transaction of $5786. ?

Is there any wonder that confusion reigns supreme within this software when you have now 5 differing values for 1 BTC at the same date and time. Every transaction entered for every coin will be likewise affected so it would be required to be be very careful and triple check everything as there are potentially so many mistakes.  

The only factual amount was the $5898 that I theoretically paid to buy the 1 BTC and believe it or not the Cointracking software totally ignores the one and only cost value that matters. How could this software ever be relied on to produce correct reports when it uses so many differing values for the same coin?
There has got to be a better more realiable way to manage crypto surely.
I have applied extensive manual editing to correct these mistakes this but it is so labour intensive to make it not really worth the time especially when Cointracking could and should correct their introduced problems so that all of this manual editing is not required.

Maybe I am missing something here so I am open to any advice as to why there should be anymore than the one and only correct cost value used for all calculations.

Hopefully someone very knowledgeable from Cointracking will chime in here and explain this for all of us.

 

It's a personal decision based on what you want to track. I do it in the "Group" field. I use Funding for when I am adding new investment funds and Leached for when I remove/withdraw funds. (I do a lot of mining so I'm tracking PoW & PoS too). Then when you click on the Balance by Exchange tab, change the drop down to Grouped by Trade-Group, you get a quick breakdown of each: Mining, Funding and Leached. You can get the same info via the Tax Report, but this is a quick dashboard and I use it every day.
Good Luck

Is there any benefit to keeping track of USD deposits/withdrawls into Coinbase using Cointracking?

Thanks,

Jeff

It seems like this sounds cool, and is useful for those who have many altcoins, this place is suitable for those investors and those who like to collect lots of coins without making many wallets.

Did you enter the "Type" of transaction as Mining?

This is my first year mining and my CPA told me that my tax report is showing everything as trades and not showing my mining as being mining. How do I go about making sure that the tax report annotates the mining as mining under income report. Currently under income report it show $0 for mining.