 Show Posts
|
|
Pages: [1] 2 »
|
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.
I have not encountered all of the timezone issues that you have been experiencing. I have most of my CoinTracking accounts set to my local timezone and all of the various exchanges I use throughout the world translate perfectly into my time. A few years back I initially bulk imported the csv files from the exchanges, and have since synced them manually through their respective API's. In both cases I did not find any timestamps wrong for reasons I could attribute to CoinTracking other than Electrum wallet imports. I did have some Coinbase issues but they were mangled by the exchange and not CoinTracking. With Electrum wallets I have had an issue where they would not translate time properly. I solved this by setting my Electrum sub accounts in CoinTracking to UTC timezone, once I did this the CSV imports properly into "my time". From there I bulk export them into my main CoinTracking account that is set to my timezone, and they retain the proper time for my locale. All of the other sub accounts in CoinTracking I have set to my timezone and experience no issues with the timestamps on those. |
|
|
|
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?
Hi allanster, I think in your case it would be better if you reduce the amount received by the amount received too much and set the withdrawal values to 0. So this process is not recorded at all. You can do this via the "Enter Coins" page. Example current situation:Income: 1.5 BTC (0.5 BTC paid too much) Withdrawal: 0.5 BTC Change the values like this:Income: 1 BTC Withdrawal: 0 BTC Thanks I will experiment with that method, what I am doing now seems to allow the tax calculations to be correct. |
|
|
|
|
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=MeaningofmarketvalueI 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. |
|
|
|
Can you somehow add RT and Emotionless to your deluxe tuner package?
Emotionless is undisclosed black box with nothing to tune. RT requires precisely tracking quantities, due to TradingView's lack of native Satoshi currency and it's inability to buy fractional coins this cannot be done correctly. |
|
|
|
I replied to you in TradingView but hopefully can help answer your question here as well. As explained previously, the free scripts of mine that you are using are very basic and each shows only a simulation of one of the core strategies of Gunbot without any extra conditions that are available to be used (ADX, EMASPREAD, MFI, RSI, STOCH, STOCH RSI). I do offer a Deluxe Tuner script version which provides ability to more fully simulate Gunbot's abilities, such as mixing buy and sell strats, extra conditions, etc. Bags can be handled in many various ways... additional confirmation through additional indicators, adjusting settings for various market conditions (buying more conservatively at lower dips), DoubleUp (dollar cost averaging), ReversalTrading (increases quote for sell on later recovery), and STOP_LIMIT (sell at loss and move on). Gunbot is feature rich and gives you many tools to adapt it to your preference and style of trading. There is a TradingView addon option available as well for using with your custom strategies built in TradingView. |
|
|
|
|
I understand if a user was just doing an occasional buy and hold trade it wouldn't be that big a deal to add the "lost" balance BNB adjustment for EACH trade recording the time of the trade, but many of your users are doing automated trades as well which can easily number in the thousands and it is VERY tedious manually recording these adjustments for EACH trade. This is a BIG problem!
|
|
|
|
I don't understand that one, since the Fees are supposed to always be included in the cost of each trade (see: "Please note that the purchase and sale values displayed on CoinTracking already include all fees. ( https://cointracking.freshdesk.com/en/support/solutions/articles/29000007202-entering-fees)") So if the fees are included in the purchase price, the gain or lost would automatically take account of those right? If we do like they say and substract all the fee from the total gain result of the tax report we would be substracting them twice no??? I also would very much like to know the answer to this question! If a user bought and sold 1 LTC for 99 USDT with 1 USDT fee each trade, which of the two formulas below does CoinTracking do?... Sell 1 LTC -> Trade | Buy 98 USDT | Sell 1 LTC | Fee 1 USDT <- Placeholder field not included in calculations other than Fees page. Buy 1 LTC -> Trade | Buy 1 LTC | Sell 100 USDT | Fee 1 USDT <- Placeholder field not included in calculations other than Fees page. Possible formula A -> Gain = ((Sell price - Sell fee) - (Buy price + Buy fee)) / (Buy price + fee) = ((99 - 1) - (99 + 1)) / (99 + 1) = (98 - 100) / 100 = -2% Gain Possible formula B -> Gain = (Sell price - Buy price) / (Buy price) = (99 - 99) / (99) = 0 / 99 = 0% Gain So which is it... formula A or formula B? |
|
|
|
Response to: "Why are BNB fees from trades not being calculated in my BNB balance? It correctly deducts from the BNB balance for sales of the tokens but ignores it from any calculations as a fee."
I am also having this same problem...is there a solution for this?
https://cointracking.freshdesk.com/en/support/solutions/articles/29000021505-bnb-balance-wrong-due-to-fees-not-being-deducted-https://cointracking.freshdesk.com/en/support/solutions/articles/29000007202-entering-feesI too am quite frustrated by this statement... "In order to correct your third coin balance in the portfolio, you need to create an additional transaction as [OUT] Lost for the fee." The above statement should be... "In order to correct your third coin balance in the portfolio, Cointracking will create an additional transaction as [OUT] Lost for the fee." This "solution" is not at all satisfactory. We as customers should NOT be having to do this (manual adjustments). I do not understand why CoinTracking cannot be updated to account for third currency fees. CoinTracking should be updated to handle this and the logic is quite simple... if FEE = BNB and BUY != BNB and SELL != BNB then [OUT] BNB Also, I don't think "Lost" is a good or accurate description for this, these amounts are not "Lost" in the classic sense of the word, "Lost" means "I do not know where they went", but in this case I do know where they went, they went to "Fees". I think CoinTracking is an excellent service that is vastly superior to all of it's competitors, but I do feel greatly disappointed that this is not being handled the way it should be. |
|
|
|
|
Feature Request - in Trade Analysis we need check boxes where we can select/deselect entries like Poloniex has. Otherwise this feature has little use to those who trade frequently (bots), there are many times we are in the middle of a trade but would like to see performance of particular trade(s). These don't fall in date windows either. Something like this below where the Trade Analysis is only done on the checked pair(s)...
[ ] DASH/BTC Buy 0.08976487 0.09766193 DASH 0.00002186 BTC (0.25%) 0.00876661 BTC Bittrex Bender BOTS 27.08.2017 02:32:04
[X] DASH/BTC Sell 0.08678249 0.10166279 DASH 0.00002211 BTC (0.25%) 0.00882255 BTC Bittrex Bender BOTS 26.08.2017 19:56:43
[X] DASH/BTC Buy 0.08621483 0.10166279 DASH 0.00002185 BTC (0.25%) 0.00876484 BTC Bittrex Bender BOTS 26.08.2017 18:10:55
[ ] DASH/BTC Sell 0.08720144 0.10226012 DASH 0.00002234 BTC (0.25%) 0.00891723 BTC Bittrex Bender BOTS 26.08.2017 16:46:06
[ ] DASH/BTC Buy 0.08570878 0.10226012 DASH 0.00002185 BTC (0.25%) 0.00876459 BTC Bittrex Bender BOTS 26.08.2017 16:25:27
Extra cool points if we could see percentage gain/loss!
This feature would be very attractive to a couple thousand people that I know of for sure. Thanks for your consideration.
|
|
|
|
|
Suggestion... have Total actually present cumulative totals with the same views of all the data of your linked accounts.
I originally decided to store everything in one account, then when I saw you had a Total function, I took the time to create separate linked accounts for each exchange and mining thinking I would be able to view them all in Total the same way that I was able to view them in individual accounts. I was a little surprised to discover that wasn't the case. So I ended up moving everything back into one combined account. Total has little value without being able to present ALL of your data in the same was as the individual accounts.
Making this change could have the potential to lower your resource usage. There are those of us who do little trading on several exchanges but may trade numerous times on one. By giving us the ability to separate these out but still see them combined in total, it would mean we would often times just be refreshing the one account and your servers would need to crunch less data by not having to refresh all of it from the other mostly static accounts.
|
|
|
|
@sgjenks01
I just bought my first purchase with crypto (Gunbot). How do you handle these transaction entries? Is it an "Out", should there be an "In", or is it a trade to FIAT
Allan
@Allanster I'm assuming you bought Gunbot with fiat money. You start with an IN transaction to show you deposited cash somewhere (an Exchange like Bittrex). Then you sell the fiat and buy the Gunbot in a "Trade" type transaction. Also, if it's an exchange that has API trade report exports, you can set it up to do the imports automatically (daily). Any Sell (OUT) side entry should include the fee in the amount sold and you can report the fee in the Fees column if you want to track how much you are paying for the privilege. This would include commissions and miner transaction fees. I use the "Balance by Exchange" to be sure the balances by exchange by currency matches the amount the exchange/wallet has in it. Steve Steve, I'm up to speed on the API and balances by exchange. I currently balance to zero by exchange. I haven't enabled API's until I see how UTC time get's handled in update. As far as purchasing Gunbot, I wish I could've paid USD but I couldn't find a way to do so. I purchased on Bitify with BTC that I had mined in 2011. I already have entries for the mined coins. I just am not sure how to properly do entry for "spent" coin on Gunbot. I'm assuming these day to day purchases should be entered here as well, according to Forbes article I posted earlier, even a coffee needs basis tracked. So considering I already have all entries for mined coins and trades, how do you recommend the sole entry for the purchase of Gunbot? Thanks! Allan |
|
|
|
|
@sgjenks01
Thank you so much for taking the time to report your findings on the crypto exchanges. Not the answer I was hoping for, but at least it brings clarity. I was operating under that assumption anyways. Hardly surprising. Good old Uncle Sam... "It's not money but give us more of your money anyways!"
I just bought my first purchase with crypto (Gunbot). How do you handle these transaction entries? Is it an "Out", should there be an "In", or is it a trade to FIAT?
Thanks for any insights!
Allan
|
|
|
|
|
I have entered several mined transactions from 2011 in the form below, but the Tax-free coins and have Short & Long shows nothing long in 2017, why not?
Type: In | Buy: 1 | Cur: BTC | Exchange: Bitcoin-QT | Date: 2011-07-23 21:34:36
|
|
|
|
I will try to add tx fees in the next 2-3 days to the gains report. This will solve tx fee offsets.
Dario Dario, Thank you for reply and addressing issue. I was concerned I misunderstood something so I'm relieved that it is an actual issue. Allan |
|
|
|
Only the Realized will have a .01 offset if the "Add Deposits & Withdrawals to remaining amount" checkbox is not set.
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 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 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. |
|
|
|
@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" |
|
|
|
|
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).
|
|
|
|
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.
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. 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
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 |
|
|
|
|
