In crypto, there is a concept of 'In-Flight' balances. A balance that is 'In-Flight' is one that has been sent from one entity (such as an exchange or wallet) but has not yet been received by the entity that it is destined for. Here is an example:
You have an Ethereum wallet that contains some tokens you would like to send to another Ethereum wallet which you have. You go ahead and enter the amount to send, the receiver wallet address and confirm the transaction. Today is a pretty busy day on the blockchain but you selected a low priority gas fee, so it takes an hour for the tokens to be received by your other Ethereum wallet. During that hour, there is no balance of tokens in either wallet. The send has been recorded but the receive has not. The tokens are 'In-Flight' and before the other wallet can spend them, there must be a receive recorded in the destination wallet. This is an implication of blockchains and is fundamental in stopping 'double spends'.
How is this relevant to your taxes?
Just like the blockchain needs both the send and receive recorded, so does the CryptoTaxCalculator platform! In the example above, if only the wallet that made the send was uploaded, you would end up with a singular 'send' on the platform and no 'receive' from your other wallet. In this scenario, the platform doesn't know where the ETH went and whether you still have ownership of it or not, causing balance issues. You would see something like this on the platform:
This ETH transaction would be 'In-Flight' and would affect the balance displayed on your reports and dashboard. Similarly, if you only uploaded the receiver wallet, you would see a singular 'receive'. In this scenario, the platform doesn't know where the ETH came from and can't attribute a cost basis or a holding time frame to the asset, which could cause issues such as negative balances or zero cost buy errors. You would see something like this:
With both wallets uploaded, you would see that both the 'send' and 'receive' has merged to form a 'transfer'. A 'transfer' indicates that the asset has been sent from one 'known' (imported) entity and received in another 'known' entity, allowing for the cost base and holding period of the asset to be transferred with it. This allows for correct tax outcomes if this asset is to be disposed after being transferred.
What to do if you have a singular 'send' or 'receive'
If you have gone through your transactions and found you have a singular 'send' or 'receive', there are a number of ways you can address it to make sure your tax reports are correct.
There are three main reasons why you may have a lonely 'send' or 'receive':
You have not imported all of your wallets or exchange accounts. Make sure you upload ALL wallets and exchange accounts so that both sides of transfers can be accounted for.
To correct this scenario, go to the 'Import Data' page and import any exchange or wallets you have missed. If we do support the blockchain or exchange directly, use the manual CSV import to import the transactions to the platform: https://help.cryptotaxcalculator.io/en/articles/5777675-advanced-manual-csv-import
If you have definitely imported all of your accounts and wallets, then the next most common reason for a single send/receive is due to exchange or wallet reporting. This could be due to missing data in reporting from the exchange or wallet OR the way in which the data is reported. Some exchanges will create a 'send' transaction record when doing internal transfers between accounts (such as margin to spot) but not create a 'receive' on the other side.
In a scenario where the exchange/wallet has missed the record for the other side of the 'send' or 'receive', you can use the the '+ add transaction' button (found at the top right of the 'Review Transactions' page) to add the other side of the transaction.
To create a 'send' or 'receive', choose the 'other' option:
Select the chosen category from the drop down:
Next, fill in the details of the send and/or receive. It may help to copy down the details of the opposite side which has been recorded so that you get all of the details correct when creating the manual entry. Alternatively, you can also make a manual CSV to import missing transactions: https://help.cryptotaxcalculator.io/en/articles/5777675-advanced-manual-csv-import
In a scenario where an exchange has recorded one side of the transaction when an internal transfer has taken place, generally, this type of transaction can actually be 'ignored' as our platform takes the balance of the exchange holistically and the wallet location within the account is not generally relevant. To ignore one of these transactions, navigate to the three dots on the right-hand side of the transaction line and hit 'ignore':
These transactions can often be identified as they do not have a destination or source, it will simply have a single entity, as depicted above.
The third most common reason is that the transaction has been categorized incorrectly. For example, if you have a lonely 'send' where you have sent funds to a staking contract, use 'Staking Deposit' not 'send'. Here are a number of possible categories that could be used instead of 'send':
Lost/Stolen: you lost cryptocurrency and want to claim the cost basis as a tax deduction.
Liquidation: you were trading on leverage and got margin called.
Fee: you had a miscellaneous expense.
Loan Fee: you made an interest payment on a loan.
Loan Repayment: you paid the debt back on a loan.
Personal Use: you made a personal use purchase and want to claim this as non-taxable (warning: check with your accountant before using this to make sure you satisfy the criteria).
Realized Loss: you made a loss when trading derivatives e.g. futures/margin.
Fiat Withdrawal: you cashed out from your exchange, hopefully, more than you put in.
Staking Deposit: you deposited these coins into a staking pool. This acts similar to a withdrawal.
Collateral: You have set these tokens aside as collateral for a loan. This acts like a withdrawal.
If you have a lonely 'receive' where you have pulled funds out of a staking contract, use 'Staking Withdrawal'. Here are a number of possible categories that could be used instead of 'receive'.
Airdrop: you received "free" tokens as part of a promotion or similar.
Staking Reward: you earned interest from staking.
Interest: you received interest for lending your cryptocurrency.
Gift: you received a gift from a third party e.g. a family member.
Chain Split: you received crypto as a result of a hard fork.
Mining: you received crypto as a mining reward.
Income: you received income in crypto. You can also categorize commissions etc in this category.
Cashback: you received a cash-back from a credit card payment etc.
Realized Profit: you received profit from trading derivatives e.g. futures/margin.
Fiat Deposit: you wired fiat into an exchange from your bank account.
Borrow: you received crypto or fiat as a result of providing collateral.
Mint: This acts similar to a 'buy' and a common use case is for when a user is 'minting' NFTs.
Staking Withdrawal: you withdrew these coins from a staking pool. This acts similar to a deposit.
Criteria for Send and Receive Transactions to Merge
Below are the criteria for a pair of send and receive transactions to merge to form a transfer. If you have both a send and receive transaction but they will still not merge to form a transfer, make sure they fill the criteria below:
Criteria to merge:
Within 12 hour window
Each shows the direction of the transfer to be from entity 1 to entity 2
Same currency in both
Send and receive on each side
Quantity similar (2% leeway) for both amount and fees
ID is same
Note: not all criteria must be filled, but the more the better. If the IDs are different but all other criteria match, the two transactions will still merge.
If one entity is shown as 'unknown' in one of the transactions, it will still merge if there is the other side of the transfer uploaded to the platform.