Ask an exchange for your year and it can hand you two different files. One prints a profit figure and fits on a page. The other says nothing about profit at all and runs to hundreds of rows. Both are accurate, they answer different questions, and only one of them is the record a tax filing is built from.
What each of the two records is for
A transaction history is a log. Every row is an event that changed a balance: a trade, a fee, a deposit, a withdrawal, an internal transfer, a reward. It records what happened and in what order, and it stops there. No row in it tells you whether you are up or down.
A realized PnL report is a conclusion drawn from that log. Something has read the events, matched sales against purchases, applied a rule for deciding which purchase paid for which sale, and printed the result. It is shorter because it is the answer, not the working.
That makes the relationship one-directional. You can rebuild a realized PnL report from a complete transaction history; you cannot rebuild the transaction history from the report. Whatever the report's rule collapsed is gone from it, which is why the trade history remains the document of record even when a tidier summary is available.
What the transaction history actually holds
The useful thing about a ledger export is how little it decides for you. Kraken's ledger fields are a fair picture of the shape: a time, a type and subtype, an asset, an amount, a fee, and the resulting balance, with entry types that include deposit, withdrawal, transfer, spend, receive and staking alongside trades. Each entry, in that documentation's own words, focuses on a change to a particular asset's balance.
That breadth is the point. A ledger carries rows a profit summary has no reason to print: funds arriving from your own wallet, a withdrawal to a bank, a charge levied on something that was never a disposal. Those rows are noise when you want to know how you did, and they are evidence when someone asks where an amount came from.
What a realized PnL report actually holds
A realized PnL report holds closed results only. An open position contributes nothing to it, because its unrealized PnL is still moving and no result has been fixed yet. That silence is not a gap in the report; it is what the word realized is doing in the title.
The report also carries a decision you did not make. When a sale is smaller than the pile you were holding, something has to say which units left, and no figure can be printed until that question is settled. The rule used may not appear anywhere on the page, and it is one reason two accurate documents disagree.
Why the two do not agree
The first reason is scope. A report is generated for one account, one product line and one date window, and anything outside those edges is simply not in it. Assets you moved in from elsewhere arrive with no purchase row attached, so the venue holds no cost basis for them and has to either estimate one or leave the entry incomplete.
The second reason is the matching rule, and it is worth seeing in numbers. Say you bought one unit at $2,000 and a second unit at $8,000. That puts your average cost across the two at $5,000. You later sell one unit at $12,000. Under a first-in-first-out convention the sale is matched to the earlier purchase and the report shows $10,000. Under an average-cost convention the same sale shows $7,000. Your trading was identical in both cases; only the rule changed.
The third reason is where fees and non-trade flows land. A fee can be folded into the cost of the purchase, deducted from the proceeds of the sale, or listed as its own ledger row and left out of the profit figure entirely. Each of those is defensible, and they do not produce the same total, so a report and a ledger can differ by exactly the fees between them.
| What you are looking at | Transaction history | Realized PnL report |
|---|---|---|
| What one row is | An event that changed a balance | A closed result |
| Open positions | Present, as the trades that opened them | Absent until they close |
| Deposits, withdrawals, transfers | Included | Outside the profit figure |
| Whether a rule was applied to it | No | Yes, a matching rule you did not see |
| What it is good for | Reconstructing anything | Reading the outcome at a glance |
Spot records and futures records are not built the same way
On spot you acquire a thing. A purchase attaches a cost to units you now hold, those units sit there until you dispose of them, and the disposal is the moment a result is fixed. The record therefore has to survive across time: a sale this year can depend on a purchase made years earlier, which is why a single-year export can be insufficient on its own.
On futures you acquire nothing. A contract is opened and later closed, and the result is the difference between those two prices applied to the size, settled in the margin currency. There is no lot of units to carry forward, so a futures result is complete within the period in which the position closed.
What futures add instead is a second stream of cash. Funding payments and trading fees reach your balance while the position is open, and by construction they are separate from the entry-to-exit difference. Whether your venue folds them into the realized figure or lists them as their own ledger rows is a property of that venue's report rather than of the arithmetic, so check it on your own account instead of assuming.
The practical consequence is that a futures PnL report can look complete and still not equal the change in your balance. The ledger is what closes that gap, because every funding transfer and every fee is a row in it.
What a tax record actually needs
Tax rules differ by country and this is education rather than advice, but the shape of the requirement is worth seeing once. The United States Internal Revenue Service treats digital assets as property, and for working out a gain or loss it lists the records to keep as the type of digital asset, the date and time of the transaction, the number of units, the fair market value in U.S. dollars at the time of the transaction, and the basis of the asset sold or disposed of.
Read that list against the two documents. Every field on it is a per-transaction field, which is the ledger's format and not the summary's. A realized PnL report can be an excellent check on your arithmetic and a poor answer to that request, because it has already collapsed the very rows the request is about.
The gap widens once you count events the report never sees. A taxable event can be a swap between two tokens, or spending crypto on something, neither of which looks like a profitable sale on a trading screen. If the report is scoped to trades, those rows live only in the ledger.
How to export both
Expect to pull more than one file. Kraken's export screen offers Trades and Ledgers as separate exports, requires a start and an end date for each of them, and lets you choose PDF or CSV. The separation reflects the fact that the two documents answer different questions, so pull both rather than picking one.
Take CSV rather than PDF whenever the file is going somewhere other than your own eyes, set the date range wider than the tax year so that opening balances and earlier purchases are visible, and run one export per product line, since spot and derivatives can sit in separate ledgers.
Then store the raw file unmodified and do your working in a copy. An export is a snapshot of a venue's records at a moment, and edits made in place destroy the only property that made it evidence. An export also covers only the venue that issued it, so your own transfers between platforms are the seams where a reconstruction breaks.
| What you need to answer | Which export answers it |
|---|---|
| How much did I make on closed positions | The realized PnL report |
| What did I pay for the units I still hold | The trades export, from the purchase onward |
| Where did this balance change come from | The ledger export |
| What fees and funding did I pay | The ledger export |
| What do I hand to a tax preparer | The ledger and trades exports, with the report as a cross-check |
The bottom line
A transaction history is the event log and a realized PnL report is a conclusion drawn from it, so the report can never contain more than the ledger does. The two disagree for three reasons that are all legitimate: the scope of the export, the rule chosen for matching sales to purchases, and where fees and non-trade flows are placed.
Spot records carry cost across years while futures records close inside the period, and futures add funding and fees as separate flows that a profit figure may not include. Export both documents, keep the raw files, and treat the summary as a check on the ledger rather than a replacement for it. To keep learning the fundamentals, follow more from Bitbase Academy.
Related reading
Other Bitbase articles on this topic:
- FIFO vs LIFO for Crypto Cost Basis
- Compounding and Position Growth
- What Is Crypto Day Trading? How It Works and Its Risks
- Diamond Hands, Paper Hands and Jeets
- Measuring Crypto Community Growth: Discord, Telegram and Real Engagement
Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of September 2026; refer to the latest official information.
References
[1] Internal Revenue Service, Digital assets: records to keep for digital asset transactions irs.gov
[2] Kraken Support, How to export your account history on Kraken Pro support.kraken.com
[3] Kraken Support, How to interpret Ledger history fields support.kraken.com
