How to Merge Transaction Logs from Multiple Wallets

Most active crypto holders aren't operating out of a single account. There's usually a main exchange for buying and selling, maybe a second exchange for a specific pair or lower fees, a software wallet like MetaMask for interacting with apps, and a hardware wallet for anything held long term. Each of those keeps its own record, in its own format, and none of them know what happened on the others. Building one usable transaction history out of that mess is a different problem from exporting a single CSV, and it trips people up in ways that are easy to miss until the numbers don't add up.

Exchanges and Wallets Don't Export the Same Way

Centralized exchanges keep a server-side ledger of everything that happens on their platform, so exporting your history is usually a matter of finding the right menu and downloading a CSV or XLSX file. Non-custodial wallets work differently. MetaMask, for example, doesn't store your transaction history anywhere on its own servers — it's just a piece of software that reads and signs against the blockchain. There's no built-in "export history" button that produces a clean file. The usual workaround is pulling your history from a block explorer like Etherscan, which lets you export the transactions tied to your public address, or using a wallet-tracking tool that indexes the chain for you.

Hardware wallets sit in between. Ledger Live, for instance, does offer a native export: open Operation History for an account (or all accounts) and use the save option to download a CSV. But because a hardware wallet is really just a signing device tracked through its companion app, that export only covers activity Ledger Live has synced — if you've also interacted with that same address through a different interface, the histories won't automatically merge on their own.

Why You Shouldn't Just Paste Everything Into One Spreadsheet

The instinct once you have five or six export files is to copy every row into one master spreadsheet and sort by date. Resist it, at least as a first step. Different sources structure the same information differently enough that a naive merge produces a file that looks complete but isn't reliable. One exchange might record a sale as a single negative-amount row; another might split it into a separate debit and credit line. Timestamps come in different timezones and formats — some in UTC, some in your local time, some as Unix epoch integers — and if you don't normalize them before comparing across files, transactions that happened seconds apart can look like they happened hours apart, or vice versa. Asset symbols aren't consistent either: an exchange might list plain ETH while an on-chain export shows WETH, or a token might appear under a contract address instead of a ticker. None of that is wrong, exactly, it just means a row-by-row concatenation won't behave the way a single unified ledger should.

There's also a real risk of double-counting. If you export a date range from an exchange and then separately export a wallet's on-chain history covering an overlapping period, and both happen to include the same transfer, a careless merge will count it twice — once as a withdrawal on the exchange side and once as a deposit on the wallet side, with nothing telling you they're actually the same event. Multiply that across several sources over several years and your totals stop meaning anything.

Matching Transfers Instead of Just Combining Rows

The fix is to treat merging as a matching problem, not a copy-paste problem. Every time you move an asset from an exchange to a wallet you control, or between two wallets, it shows up as two separate entries in two separate exports: an outbound entry in one and an inbound entry in the other. Those two entries describe a single non-taxable transfer, not two events, and the record only makes sense once they're linked. For on-chain movements, the transaction hash is the most reliable way to confirm a match — it's a unique identifier for that specific transaction, so if the same hash (or the same amount and near-identical timestamp, when a hash isn't available) shows up on both sides, you know you're looking at one transfer, not two.

Leave enough of a trail to do that matching before you throw anything away. Keep each export as its own file, tagged with which platform or wallet it came from, rather than immediately flattening everything into one sheet. Standardize timestamps to a single timezone as an early step. Then work through the transfers first — outbound from one source, inbound to another, same amount, close in time — and mark them as internal movements before you try to calculate anything from the combined data. Whatever is left after transfers are matched and removed from the "taxable event" pile is your actual set of trades, disposals, and income events.

Don't Forget the Inactive Ones

It's easy to build a merged history around the wallets and exchanges you use today and forget about the ones you don't touch anymore — an old exchange account you moved away from, a browser wallet you set up once and abandoned, a hardware wallet that's been in a drawer for two years. If any of those ever held assets that eventually made their way into your current accounts, their history is part of the chain of custody for your cost basis, even if the account itself is dormant. Pull an export from anything you've ever used before you consider the merge complete.

Where Crypto Transaction Log Fits In

This reconciliation work — normalizing formats, matching transfers across sources, and keeping duplicates out — is exactly what Crypto Transaction Log automates. Import your CSV or XLSX exports from every exchange, plus whatever you've pulled from a block explorer or Ledger Live for your self-custody wallets, and it lines them up on a common timeline, identifies the matching sides of internal transfers, and flags anything that looks like a duplicate before it distorts your totals. Instead of maintaining a fragile master spreadsheet by hand, you get one consolidated record that actually reflects what happened, across every wallet you've used.

It's free for unlimited transactions, so there's no reason to keep stitching exports together manually every time tax season or a portfolio review rolls around.

The Bottom Line

A merged transaction history is only useful if it's actually accurate, and getting there takes more than exporting every source and pasting the rows together. Formats differ, timestamps need normalizing, and every transfer between your own accounts needs to be matched on both sides instead of counted as two unrelated events. Do that reconciliation carefully — or let a tool do it for you — and you end up with a record you can trust instead of a spreadsheet that merely looks complete.