How to resolve "Unknown sender" and "Unknown receiver" in full data set?

I’ve had to delete and re-add my Ledger X hardware wallet a couple of times, and that seems to have messed up my transaction history with respect to cost basis. Somehow all the balances seem OK, but the trail back to the original purchases are lost I guess. Also, when first getting setup, I was prompted to manually resolve transactions, which I did but then later brought in some historical data from an old Coinbase (regular) account that may be duplicating or conflicting with the manual changes. now I have multiple transactions in the Full Data Set that show as either “Unknown sender” and “Unknown receiver”. What’s the best way to resolve these?

So, questions:

  1. If I delete and re-add a wallet, do all the transactions get duplicated?
  2. I now have every wallet and exchange in Accointing and sync’d up, so how can it not know who the sender or receiver is on a given transaction?
  3. Would it make sense to go back and just set all the manual adjustments (possibly done wrong) to be ignored, now that the full dataset should be present, and see if this resolves it?

Hi @King612! Did you check in the Review page for internal transactions?


Ah, yes, thanks! Was missing the little read dot prompting me to go.

OK, progress for sure. Now my question is - on a transfer from hardware wallet (Ledger) back to Coinbase, it comes in unclassified. None of the classifications seem to fit. It’s just a transfer. Would that be a ‘Swap’?

Thanks so much for the quick response.


Same question in the other direction (Coinbase to ledger). Would these just be add/remove funds?

Hi @King612! Those would be internal transfers.

No, they do not show up there. They only show up on the Classify transfers page with no Classification. The classification is that they were transferred!!

And Transfer is not an option on the Classification menu.

Good grief…

There was no withdrawal from the exchange on 3/19. Nothing was withdrawn from my coinbase PRO account, where they all show up correctly. The transfers IN are real, from a Ledger I’m convinced that’s some sort of Coinbase shuffling that’s going on thru internal wallets that’s really screwing with Accointing when it then sync’s via the API because it is not seeing the whole picture.

Every one of the transfers are non-taxable events, yet the only options in the Classification drop down are taxable events!

Do you see how I’m stuck in some sort of infinite Catch-22 loop here?

This is really unacceptable, and I guess I’ll have to start looking for another accounting package…


1 Like

Something to try…I noticed that the TxID doesn’t always show up the same between sources (e.g. sometimes the prefixed 0x is missing in Wallet but exists in Exchange), so I’ve had luck with updating the transactions to ensure the TxID matches, then it auto-matches as an internal transfer.

1 Like

Here is what actually happened, a transfer of 2 BTC from a Ledger to Coinbase Pro (and the associated fee), as reported by the Ledger:

Here is how it shows up in Accointing. Please explain to me what in the world is causing this to show up this way?

Bitcoin_BTC_X is the Ledger wallet for btc. Note how accointing is showing six different transactions, the last of which shows up 18 hours later. This cannot be reality on the blockchain that I know of. It’s some issue between Coinbase pro and your software.

I’d love to know how to reconcile this. The link you provided was helpful, but it doesn’t begin to deal with this mess.

Thank you,

Hey! I think here’s an explanation to what’s happening: Duplicate Transactions When Both Coinbase and Coinbase Pro are Used - #3 by Alex

Thank you, that was what I thought might be happening. I deleted and reimported both my Coinbase and Coinbase Pro accounts, but I’m still having the same problem.

Before I start messing with the ledger with manual changes, I have a more general question. I have transactions that are clearly internal transfers. Accointing must be recognizing them as transfers because it keep flagging me to categorizing them under Classify Transfers under review. I want to classify them as internal transfers so they will be appropriately non-taxable. Every classification looks taxable to me, and I’m being forced to picked one. None of them apply, so I’m still stuck in the loop.

So how can I force Accointing to see these as Internal transfers? Is the post you provided and manual changes to the ledger the only way to do this?


Hi, I am also interested in a solution to this as I’m stuck with the same problem. There are so many “unknown sender” and “unknown receiver” transactions in my list. While I understand this is because of how Coinbase <> Coinbase Pro handles it (based on other post/message), we should be able to classify this as an “internal” transfer, instead of a taxable classification as currently only available. I tried to set it as a “ignore” but then I get a ton of red exclamation points for corresponding legitimate transactions that are out of sync. Thanks!

I posted this in the thread about duplicate transactions but figured I’d shared here as well.

After spending more time with this, I believe the reason for so many “unknown sender” and “unknown receiver” is because the timestamps between Coinbase and Coinbase Pro APIs are off by a lot, sometimes 30 mins, which causes the ordering of events to be incorrect, which causes auto-internal detection to fail. In other words, for a transfer from CBPro to external, a transaction withdrawing from Coinbase shows up 30 mins before the transaction that moves the money into Coinbase. So when this happens, it can’t correlate where the money originated from or where it went to, which throws off all the accounting.

Hey everybody! We will be addressing this recurrent issue and come up with a solution very soon. We appreciate your patience and hopefully we will have something for you soon.


Yeah, I thought this felt wrong when I was looking at my data, the vast majority of my ‘actions’ should be transfers from an exchange to my wallet, or between wallets. Yet, almost everything is either ‘auto-marked’ as ‘buy/sell-type’ transaction, no easy way to mark as internal-wallet transfer. I’m wondering, how ‘off’ my data is because of this?

Hi, I am having the same issue of transfers appearing under ‘classify transaction’ with know way to mark as a Transfer. Further, this option be available regardless of synch wallet issues, as not all wallets/networks are supported. E.g. I transferred 3 AAVE to Fantom (FTM) - this should be non-taxable.
When is this fix coming?

Having the same issue with lots of Ledger Live ETH 1 address to Ledger Live ETH 2 address. By the way:

Timestamp, Tx, and amount is matching. Withdraw is a minute earlier than deposit.

In my case, the main Transfers seemed to be resolvable correctly from the Confirm Transfers tab, and then the items that kept showing up under Classify were like intermediate transfers internally to the exchange (e.g., Coinbase Pro). I think this is because internally they are shuffling things back and forth between users and/or back and forth to cold storage for security reasons. Each one is a transaction though, even though it’s internal to them, I’m guessing. So, I have just been marking them as Ignored under Classify once I was sure all the (real) transfers were properly resolved under Confirm Transfers. I don’t think you can just delete the intermediate stuff because then the actual transaction chains would be broken.

But yes, clearly some improved robustness in the application would be great here.

Blockquote Apr 5
Hey everybody! We will be addressing this recurrent issue and come up with a solution very soon. We appreciate your patience and hopefully we will have something for you soon.

Very soon? does that mean within a week? :smiley: :see_no_evil: :smiley:

I think, there must be an option to classify transactions as internal manually.

While we work on an upgrade to our Internal classifying system, I suggest making sure the transaction ID is the same and having the transfers within 6 hours of each other. If this causes any duplicate transactions, ignore one of the duplicates, though the duplicate transactions from internals I believe is already fixed.