Unmatched transfers, missing wallets, duplicate transactions, and misclassified DeFi activity can turn an accurate crypto tax report into an inflated one. Here’s what is happening—and how manual reconciliation can fix it.
Have you ever imported your crypto transactions into tax software, looked at the capital gains report, and thought:
“There is no way I made that much money.”
You may be right.
Crypto tax software can process thousands—or even millions—of blockchain and exchange transactions. But software does not automatically understand the full context behind every transaction.
A withdrawal might be a transfer between your own wallets. A token swap might be part of a DeFi strategy. A wrapped token might represent the same underlying asset. A missing wallet could contain the original purchase that establishes your cost basis.
If the software cannot connect those dots, your reported crypto gains can become significantly inflated.
We regularly see this during crypto tax reconciliation. In one case, software initially showed approximately $140,000 in gains. After manually reconciling the client’s wallets, transfers, cost basis, wrapped-token transactions, and duplicate data, the corrected gain was approximately $19,000.
That’s a difference of more than $120,000.
So what actually causes crypto tax software to overstate gains?
Let’s look at what is happening under the hood.
One of the most common reasons for inflated crypto gains is missing cost basis.
Suppose you purchased 2 ETH for $4,000 several years ago. You later moved that ETH through multiple wallets and eventually sold it for $8,000.
Your actual gain is approximately:
$8,000 sale proceeds − $4,000 cost basis = $4,000 gain
But what happens if the tax software sees the $8,000 sale and cannot find the original $4,000 purchase?
The software may have no reliable acquisition record to associate with the sale.
Depending on the platform and circumstances, the transaction may end up with a very low or even zero cost basis.
Now the report could show something closer to:
$8,000 proceeds − $0 cost basis = $8,000 gain
The problem isn’t necessarily the sale.
The problem is that the historical acquisition data is missing or disconnected.
Common causes include:
· An old exchange was never imported
· A previous wallet was forgotten
· Historical CSV files are missing
· An API connection only retrieved recent activity
· Crypto was transferred from another platform without the original transaction history
· A hardware wallet was never added to the tax software
· Tokens were migrated between chains or contracts
· The acquisition was recorded under a different wallet or exchange
This is why a large gain with a very small or zero cost basis should always be investigated before assuming the tax liability is correct.
Another major source of inflated crypto gains is unmatched transfers.
Consider a simple example.
You withdraw 5 ETH from Coinbase and deposit the same 5 ETH into Binance.
You haven’t sold anything.
You’ve simply moved your own ETH from one account to another.
But tax software doesn’t automatically know that the Coinbase withdrawal and Binance deposit represent the same movement of assets.
If those transactions aren’t matched, the software may interpret them as two unrelated events.
In some cases, the withdrawal can be treated as a disposal, while the deposit can appear as a new acquisition.
That can distort both your transaction history and your cost basis.
One unmatched transfer may not seem significant.
But imagine doing this across:
· 5 exchanges
· 8 wallets
· 10,000 transactions
· Multiple blockchain networks
· Several years of activity
Suddenly, hundreds of internal transfers can be sitting in your tax software as unresolved transactions.
This is one reason transaction count alone doesn’t tell you how complicated a crypto tax return is.
A portfolio with 10,000 transactions may contain only a few hundred economically meaningful taxable events—but the software needs to correctly understand what the remaining transactions represent.
Another common problem is duplicate transaction data.
This often happens when investors import the same activity through multiple sources.
For example:
1. You connect an exchange through an API.
2. You download the exchange’s CSV history.
3. You import the CSV into the same tax software.
Now the same trades may exist twice.
The problem can become even more complicated when an API connection breaks and is later reconnected.
Instead of retrieving only the missing period, the API may pull the entire transaction history again.
If the software doesn’t correctly identify the duplicates, your transaction count and potentially your gains can become distorted.
Some exchanges record different components of the same underlying activity separately.
A trade might generate:
· Trade record
· Fee record
· Settlement record
· Deposit or withdrawal record
These records need to be interpreted correctly.
You cannot simply assume that every row in an exchange CSV represents a separate taxable event.
The same applies to failed or reverted transactions.
A transaction may appear in the data even though the intended trade never actually executed. The user may have lost a gas fee, but the software could still interpret the transaction as a completed buy or sell.
That is why imported data needs to be reviewed—not simply accepted.
One of the questions we ask clients during reconciliation is surprisingly simple:
“Do you have any other wallets—even ones you forgot about?”
This question can uncover major gaps.
People often remember their current exchanges and wallets but forget about:
· An old MetaMask wallet
· A hardware wallet
· A previous exchange account
· A wallet used for a particular DeFi protocol
· A wallet created years ago and rarely used
· A wallet that still contains historical acquisition records
This matters because the missing wallet may contain the original purchase transaction for crypto that was sold much later.
Without that acquisition history, the eventual sale can appear to have little or no cost basis.
Cold wallets and hardware wallets can be particularly problematic because users sometimes assume they don’t need to be included until they sell something.
But the wallet may contain years of transaction history.
If you bought ETH on an exchange, transferred it to a Ledger, and years later transferred it to another exchange before selling it, the entire chain of transactions can be relevant to determining the correct cost basis.
The tax software needs to see enough of that history to understand where the asset came from.
Cross-chain activity introduces another layer of complexity.
Suppose you move an asset from one blockchain to another using a bridge.
The transaction may technically look like:
Asset leaves Chain A → Wrapped or bridged asset arrives on Chain B
A tax software platform may interpret those as two unrelated transactions.
If it treats the original token as sold and the wrapped token as newly purchased, the report can create a phantom gain that doesn’t reflect what actually happened economically.
The same issue can occur with wrapping and unwrapping assets such as:
ETH → WETH → ETH
The technical transaction records are different.
But that does not automatically mean the taxpayer economically disposed of the underlying asset.
This is a good example of why blockchain data is not automatically tax-ready data.
The blockchain tells you what happened technically.
It doesn’t always tell you what the transaction means from a tax perspective.
DeFi creates some of the most difficult reconciliation problems because a single interaction with a smart contract can generate multiple blockchain transactions.
Common examples include:
· Token swaps
· Liquidity pool deposits
· Liquidity pool withdrawals
· Staking
· Restaking
· Lending
· Borrowing
· Collateral movements
· Wrapped assets
· LP tokens
· Protocol rewards
The software has to interpret what actually happened—not simply identify the tokens moving in and out of a wallet.
Suppose you deposit ETH and USDC into a liquidity pool.
Some software may interpret the movement as if you disposed of both assets.
But economically, you may have simply contributed those assets to a protocol in exchange for a position represented by an LP token.
The transaction requires careful interpretation.
Receiving an LP token can also create confusion.
A tax platform may classify the receipt as income or another taxable event when it may instead represent evidence of your position in the liquidity pool.
Again, the underlying blockchain transaction alone doesn’t necessarily answer the tax question.
Staking is another area where platforms can produce different results.
Depending on the protocol and the tax treatment applicable to the taxpayer, questions can arise around whether rewards are recognized when received, when they become claimable, or at another point.
The important point is that software classifications should not automatically be treated as tax conclusions.
You might deposit crypto as collateral for a DeFi loan.
That doesn’t necessarily mean you sold the crypto.
But if the software sees the asset leaving your wallet and doesn’t understand the lending protocol, it could potentially classify the movement incorrectly.
Crypto projects frequently change contracts, migrate tokens, launch new versions, or distribute airdrops.
These events can be difficult for automated software to interpret.
For example, an old token may be exchanged for a new contract token during a migration.
If the software doesn’t understand the relationship between the two assets, it may treat the migration as a normal disposal and acquisition.
That can create an incorrect gain or loss.
The same principle applies to airdrops and unusual token distributions.
The software sees tokens arriving in a wallet.
It may not know why they arrived.
That distinction matters.
Here’s an anonymized example from a client reconciliation.
The client was a relatively small DeFi user.
Their crypto tax software initially calculated approximately:
$140,000 in gains
That number immediately warranted investigation because it did not appear consistent with the client’s actual trading activity.
We manually reconciled the transaction history across the client’s accounts and wallets.
We found several issues, including:
· Unmatched transfers between the client’s own accounts
· Missing acquisition records
· Wrapped-token transactions being treated incorrectly
· Duplicate CSV data
We went back to the underlying exchange records and blockchain transactions, reconstructed the acquisition history, matched internal transfers, and corrected the transaction classifications.
After reconciliation, the reported gain was approximately:
$19,000
The difference was more than $120,000.
The important takeaway isn’t that tax software is “wrong.”
The software was working with the data and transaction relationships it had available.
The problem was that the data wasn’t fully reconciled.
Manual reconciliation isn’t about reviewing every transaction blindly.
It’s about investigating the areas where automated systems are most likely to misunderstand the underlying activity.
Here are some of the checks we perform.
We ask clients about all accounts and wallets, including old ones.
The goal is to identify missing sources of historical cost basis.
If 2 ETH leaves one exchange and approximately 2 ETH arrives at another wallet around the same time, we investigate whether those transactions represent the same internal transfer.
This helps prevent transfers from being incorrectly treated as sales.
Blockchain activity isn’t always successful.
A failed transaction can still generate a gas fee and appear in transaction data.
We check whether the software has interpreted the transaction correctly.
This is one of the simplest—and most useful—checks.
Suppose the client says they held 10 ETH at year-end, but the tax software shows only 7 ETH.
That 3 ETH difference is a red flag.
It could indicate:
· Missing transactions
· Unmatched transfers
· An unconnected wallet
· Incorrect transaction classifications
· Duplicate or missing records
Balance reconciliation can therefore reveal problems that aren’t obvious from a capital gains report alone.
For complicated transactions, we don’t rely solely on the description generated by the tax software.
We go back to the underlying blockchain transaction and examine:
· Sending address
· Receiving address
· Token movements
· Contract interaction
· Timestamp
· Transaction status
· Fees
· Related transactions
The goal is to understand what actually happened before deciding how it should be classified.
One of the most common misconceptions we encounter is:
“I connected Binance, so all my Binance transactions must be there.”
Not necessarily.
An exchange may maintain separate records for:
· Spot trading
· Futures
· Staking
· Deposits
· Withdrawals
· Rewards
· Fees
· Other products and services
A single API connection or CSV export may not contain everything you need.
The same issue applies across other exchanges and platforms.
That’s why a complete crypto tax reconciliation often requires multiple data sources, followed by duplicate detection and transaction matching.
If a client’s reported gains suddenly look unusually high, the first step isn’t to assume they actually owe more tax.
We investigate where the increase is coming from.
Typically, we start by reviewing the capital gains report and identifying the largest or most unusual transactions.
Then we ask:
· Does each major sale have a valid acquisition history?
· Is the cost basis reasonable?
· Are there missing wallets?
· Are transfers being recognized correctly?
· Are any transactions duplicated?
· Are DeFi transactions classified appropriately?
· Are there failed or reverted transactions?
· Does the reported gain make sense compared with the client’s actual trading activity?
A person who normally has modest trading activity but suddenly has hundreds of thousands of dollars in gains should not simply accept the number because the software generated it.
An unusual tax result is a reason to investigate, not automatically a reason to pay.
This is perhaps the biggest misconception in crypto tax reporting.
The blockchain provides an immutable record of what happened technically.
It can tell you:
Wallet A sent 5 ETH to Wallet B at 14:32 UTC.
But it doesn’t necessarily tell you:
Wallet A and Wallet B are both owned by the same taxpayer, so this was an internal transfer and not a sale.
Likewise, the blockchain can show that:
ETH was exchanged for WETH.
But the raw transaction doesn’t necessarily determine the appropriate tax treatment.
That’s where reconciliation comes in.
The software provides the infrastructure to process enormous amounts of transaction data.
But someone still needs to understand the client’s activity, connect related transactions, investigate anomalies, and determine whether the resulting tax report makes sense.
The two are not the same thing.
Crypto tax software is excellent at processing large amounts of data, importing transactions, calculating gains, and generating reports.
Crypto tax reconciliation is the process of making sure the underlying data is complete, transactions are correctly connected, balances make sense, and unusual activity has been properly investigated.
The best workflow combines both.
Collect all data → Import transactions → Identify missing data → Match transfers → Remove duplicates → Reconstruct cost basis → Review DeFi activity → Reconcile balances → Validate gains/losses → Generate tax reports
Not:
Connect exchange → Import transactions → Click “Calculate” → File
Consider getting your transaction history reviewed if:
· Your gains look significantly higher than expected
· Large transactions show little or no cost basis
· You have transferred crypto between multiple exchanges
· You use several self-custody wallets
· You have interacted with DeFi protocols
· You have used cross-chain bridges
· You imported both APIs and CSV files
· Your transaction count seems much higher than your actual trading activity
· Your closing crypto balances don’t match the software
· You have old wallets or exchanges that aren’t connected
· You see large unexplained gains from assets you barely traded
These are all potential signs that the issue may be data reconciliation rather than actual investment performance.
Crypto tax software has made it dramatically easier to process complex digital asset activity.
But automation has limits.
A blockchain transaction doesn’t always explain its economic purpose. An exchange export doesn’t necessarily contain every transaction. A wallet address doesn’t tell the software who owns it. And a missing cost-basis record can make a legitimate investment look like a massive gain.
That’s why crypto tax reconciliation remains an important step before filing, particularly for investors with multi-wallet, multi-exchange, or DeFi activity.
If your crypto tax software says you owe substantially more than you expected, don’t immediately assume you’ve made a fortune.
First, investigate the data.
Look for:
· Missing cost basis
· Unmatched transfers
· Duplicate transactions
· Missing wallets
· Incorrect DeFi classifications
· Wrapped-token disposals
· Failed transactions
· Incomplete exchange histories
The software does the heavy lifting.
Manual reconciliation makes sure the numbers actually make sense.
And sometimes, that difference can be worth tens—or even hundreds—of thousands of dollars.