Three facts wearing one line
A trade looks like a single event and is not. Something left your account, something else arrived, and a charge was taken for arranging the exchange. Three distinct facts, and most exports present them as one row with a couple of numbers.
Some platforms show all three. Some show the amount you received already net of the fee. Some show a gross figure and put the fee in a different column, occasionally in a different asset. Some do not mention it at all because it was built into the price.
None of these are wrong from the platform's point of view — they are describing their own bookkeeping. The difficulty appears when several such exports are combined into one record, because the same column now means different things depending on which file the row came from.
This feature exists to stop that happening: the fee stays a separate field, the asset it was charged in stays with it, and where a document gives both a gross and a net figure, both survive.
Split it, but never decide what it means
The design rule here is narrow and worth stating, because it is the difference between a record and an opinion.
Whether a fee forms part of what an asset cost you, or is a separate deductible expense, or is neither, depends on the jurisdiction, the kind of fee, and sometimes on the nature of the activity. Reasonable advisers reach different conclusions.
A tool that folds fees into cost has silently taken one of those positions. A tool that excludes them has taken another. Both look like neutral data processing and neither is.
So we do neither. The fee is preserved as its own number with its own asset, sitting beside the trade rather than inside it, and the decision is left to whoever is qualified to make it.
The consequence is a slightly less tidy table and a considerably more useful one. Every treatment remains available, including the one your adviser has not told you about yet.
Five kinds of fee, which behave differently
| Fee | Usually charged in | Visible on the export? |
|---|---|---|
| Trading fee | Either side of the pair | Usually, as a line |
| Network fee on a transfer | The asset being moved | Sometimes, sometimes only in the wallet |
| Withdrawal fee | The asset withdrawn | Usually |
| Conversion or spread | Built into the rate | No line at all |
| Platform or account fee | Money | On a separate statement entirely |
The second row causes more confusion than the rest combined. A network fee is often invisible on the sending platform's export and appears only in the receiving wallet, or the other way round — so a record built from one side alone is missing it entirely.
The fifth is the one that gets forgotten because it arrives separately, monthly, looking like a subscription rather than something attached to any particular trade.
When the fee is charged in a third asset
A trade between two assets, with the fee taken in a third — a platform token, or a base asset held for that purpose. Perfectly ordinary, and the case that breaks most simple record structures.
The problem is that a spreadsheet column called “fee” holding the number 0.4 is meaningless. Four tenths of what? Without the fee asset recorded alongside, the figure cannot be converted, cannot be compared, and cannot be used for anything.
Worse, it invites a silent assumption. Somebody later assumes the fee was in the same currency as the trade, and the resulting number is wrong by whatever the actual exchange rate was — plausibly, and by an amount nobody can spot.
So the fee asset is a field of its own, always, even when it is the obvious one. A record where the answer is redundant nine times out of ten is a record that is right the tenth time.
There is a second-order effect worth noting too: spending an asset to pay a fee may itself be a disposal of that asset in some jurisdictions. Whether it is, is a question for your adviser — but the record has to make it visible before the question can even be asked.
What can be read from a document
The fee amount, where the document states one, exactly as printed rather than rounded.
The asset the fee was charged in, where it is stated or unambiguous from the layout.
Gross and net figures where a document gives both, retained as two fields rather than one.
Which side of a pair the fee was taken from, where the export makes it explicit.
The absence of any fee line — recorded as absent rather than as zero, because they are not the same thing.
The last one carries more weight than it looks. A fee of zero is a claim that there was no charge; a missing fee line is an admission that the document does not say. Treating the second as the first quietly asserts something the evidence does not support.
What cannot be read, and will not be guessed
A spread built into a quoted rate. There is no line, so there is nothing to read — and inferring one would require a market price we do not have.
A network fee that appears only on the other side of a transfer. If you have one file and not the other, it is not in your evidence.
Whether a given fee forms part of cost basis. That is a tax judgement, not a property of the document.
The money value of a fee charged in another asset. Converting would need a rate on a date, which is a lookup we deliberately do not perform.
Whether two fees on different exports are the same fee counted twice.
The fourth is a deliberate refusal rather than a technical limitation. We could apply a historic rate. Doing so would produce a money figure that looks like it came from the document, sitting in the same column as figures that did — and nobody downstream could tell them apart.
How exports actually differ
This is where combining sources goes wrong, and it goes wrong quietly.
| Style | What the amount column means | Risk when combined |
|---|---|---|
| Gross with a fee column | Before the fee | None, if the fee column is kept |
| Net only | After the fee | Understated cost, silently |
| Gross with fee in another asset | Before, in this asset | Fee ignored or mis-converted |
| Two rows per trade | Half the story each | Double counting |
| No fee shown | Unknown | Assumed to be zero |
The second row is the dangerous one because it produces a plausible result. A net amount looks like a perfectly good cost figure. It is simply a slightly smaller one than it should be, on every row from that platform, consistently.
Consistent errors are the hardest kind to notice: nothing looks odd, because everything is wrong in the same direction by the same proportion.
Which is why the record keeps a note of which convention each source used. It is not glamorous, and it is the thing that makes rows from different platforms genuinely comparable.
The fee that has no line
Some platforms do not charge an explicit fee. They quote a rate that is a little worse than the market and take their margin there.
From a record-keeping point of view this is the hardest case, because there is nothing to read. The document is complete and accurate; the fee simply is not a separate fact anywhere in it.
We do not attempt to reconstruct it, and it is worth being explicit about why. Estimating a spread would require knowing the market rate at that instant, which is a lookup we do not do, and the result would be a figure that appears in the record as though it had been read from somewhere.
What the record does instead is show that this source has no fee data. That is honest information: it tells you and your adviser that the cost on these rows is whatever the rate delivered, with no separable charge — which is itself a fact about the trade.
Whether that matters for your situation is, again, not our call. But an empty field with a known reason is worth considerably more than a confident zero.
Not the same as an arithmetic check
Worth distinguishing, because both look like data quality work and they find different problems.
| Arithmetic check | Fee splitting | |
|---|---|---|
| Asks | Do these numbers agree? | Are these numbers still separable? |
| Catches | A total that does not add up | Information about to be lost |
| Fails visibly | Yes, immediately | No, never |
| Recoverable later | Yes, recompute | No, only from the original file |
The bottom row is the argument for doing this at the moment of reading rather than later. An arithmetic error can be found and fixed at any time, because the inputs are still there. A collapsed fee cannot be recovered from the collapsed record at all — only by going back to the original document, which may no longer be available.
One trade, three renderings
The same transaction as three different platforms would export it. Invented figures, real conventions.
| Platform | Amount shown | Fee shown | What it means |
|---|---|---|---|
| A | 1.00000000 | 0.00150000 same asset | Gross, fee separate |
| B | 0.99850000 | not shown | Already net |
| C | 1.00000000 | 2.40 platform token | Gross, fee in a third asset |
Three descriptions of the same economic event, all accurate, none interchangeable. Dropped into one spreadsheet under a column called “amount”, they are silently inconsistent.
Platform B is the problem. Its figure looks like a perfectly ordinary quantity and is quietly smaller than the others by exactly the fee. Every row from B carries the same understatement, in the same direction, forever.
Platform C is the second problem, in a different way. Its fee of 2.40 is meaningless without the asset beside it — and if somebody later assumes it was denominated in the traded asset, the resulting figure is wrong by whatever the actual rate was.
Which is why the record carries the convention per source. Not as documentation for its own sake, but because it is the only thing that makes these three rows comparable at all.
Why small fees are worth this much attention
A fair objection: fees are usually a fraction of a percent. Why does a rounding-scale number deserve a whole feature?
Three reasons, and the first is the least interesting.
They accumulate. An active holder makes hundreds of trades. A fraction of a percent applied hundreds of times is no longer a rounding-scale number.
They are directional. Unlike genuine rounding, which scatters, a netting convention understates every single row from that source. A consistent bias does not average out however many rows you have.
They are unrecoverable. This is the real argument. An arithmetic error can be found and fixed any time, because the inputs remain. A fee folded into an amount is gone from the record entirely — recoverable only from the original file, which may not exist in five years.
The asymmetry is the whole case. Keeping the fee separate costs one column. Not keeping it costs an option you may need and cannot get back.
What you get back
Fee as its own field
Never folded into the amount, whichever convention the source used.
Fee asset alongside it
Always recorded, including when it is the obvious one.
Gross and net where both exist
Two fields rather than a choice between them.
Source convention noted
So rows from different platforms are genuinely comparable.
The same problem outside crypto
Bundling is not a digital asset peculiarity. It is sharpest there because fees are frequent, tiny and often denominated in something else — but the identical failure appears wherever a document folds a cost into an amount.
| Document | What gets folded in |
|---|---|
| A payment processor payout | The processing fee, netted before the transfer |
| A delivery platform settlement | Commission, deducted from gross order value |
| A supplier invoice | Delivery, packaging, surcharges inside a line total |
| A foreign card transaction | The conversion margin, inside the converted amount |
| A brokerage confirmation | Commission and levies, sometimes inside the consideration |
In every one of these the arithmetic is correct and something has been lost. And in every one the loss is asymmetric: separating costs a column, while re-separating later costs a return to the original document — if it still exists.
The processor and platform cases are the ones most likely to affect an ordinary business rather than a holder. A payout that arrives net looks like revenue and is revenue minus a cost, and a record built from the bank alone never sees the cost at all.
Which is the same rule stated generally: read what the document says, keep the components apart, and let whoever is qualified decide how they combine.
What this will not do
It will not value a fee in money
Converting a fee charged in another asset needs a rate on a date. We do not look those up, because the result would be indistinguishable from a figure that was read.
It will not decide the treatment
Cost, expense, or neither is a tax judgement. We keep the number; someone qualified decides what it means.
It will not invent a missing fee
A spread with no line stays absent. An empty field with a known reason beats a confident zero.
It will not deduplicate across sources
Whether a fee on two exports is one event or two depends on what actually happened, which the documents do not say.
The first pass
Take one export from each platform you have used — not your whole history, just one file each — and read them together.
Then look at a single thing: does the fee appear as its own figure on every row, and is the fee asset stated? For most people the answer varies by source, and that variation is the entire finding.
A platform whose export gives net amounts only is one you now know to treat differently, and knowing it before you build a record is worth considerably more than discovering it afterwards.
What to do with the result is on crypto cost basis records, and why exports from different platforms rarely agree at all is the subject of why exchange exports never tie out.