Incorrect Average Buy Price

Accointing Support Bug Report (Fehlermeldung)
,
#1

Hello!

The average buy price seems to be impacted by any type of “transaction”. For example, before transferring SOL (or any crypto) from the exchange where it was purchased to a different wallet to hold the average buy price is correct. But, after the transfer the average buy price is incorrect meaning the price at the time of the withdrawal is being factored into the avg. buy price. Is that normal and is there anyway to fix this issue? This has been happening for months now and I’m a bit tired of having to guess or look at the values with a caveat!

Thanks for your help in advance!

#2

Thank you so much for your report :slight_smile:

May I ask if you marked this SOL transfer from one exchange to the other as an internal transfer?
Also, would you be willing to send some screenshots of your issue?

1 Like
#3

I often see some of my position where the average cost basis is wrong. Often it’s because it’s a coin that I was collecting income on from say Celsius or staking income from Kraken. Somehow it throws the avg cost basis off by way more than it should. I’ve tried deleting the exchange api in question and resetting up. And sometimes that will fix the issue but not every time. It’s kind of annoying and tedious to have to enter “transaction history” and fiddling with the endless line items which often ends up causing another issue.

1 Like
#4

I find similar issues as well. When we connect our wallets/exchanges to accounting via address the average purchase price is still incorrect. It seems to give it the price when the wallet is connected? Does that make sense? And why is it necessary to have to change the transaction to internal? Shouldn’t the accounting software be able to see that it as an internal exchange or transfer if both addresses are connected?

#5

Yes, I have been marking such transactions as internal.

I’m not sure how to share a screenshot of the issue since it appears to be something caused by Accointings’ underlying assumptions/calculations.

#6

Also, I would assume this issue will have significant implications for tax purposes.

#7

Can you guys please send us your full data set and let us take a deeper look into this issue?

image
image1899×1044 92.4 KB

If you are willing, then please fill out this form :slight_smile:

In the form please also leave a link to this post so that we have background context :slight_smile: