Why a clean CSV can still be wrong
Exchange CSV exports feel authoritative, but they are built for operations, not tax. Relying on a raw CSV is one of the most common reasons South African crypto tax filings are inaccurate — and inaccurate is exactly what triggers a SARS query under CARF data-matching from 1 March 2026.
The recurring problems
- Missing rand values. Many exports show only crypto amounts (e.g. "−0.1 BTC, +1.5 ETH"). Tax sits on the rand value of each leg, which the CSV often omits or quotes only in USD.
- Crypto-to-crypto swaps under-reported. Swaps are disposals, but a CSV may record them as a single "trade" line with no gain calculated.
- Internal transfers misread as buys/sells. Moving crypto between your own wallets is not a disposal, but CSVs from different venues can double-count or mislabel these.
- Delisted or defunct tokens and exchanges. History from a closed exchange or a delisted token simply disappears from current exports, leaving gaps.
- Fees and dust. Network and trading fees, and tiny dust balances, are inconsistently recorded, distorting base cost.
- Inconsistent timestamps and time zones. Year-end disposals can land in the wrong tax year if timestamps are misread.
What good looks like
A defensible record reconciles every account and wallet, attaches a rand value to every leg on its date, classifies each event correctly, and flags gaps. Coinfig's Data Completeness Score surfaces exactly where the data is incomplete — so you close the gaps before you file, not during an audit.
Not tax advice
Reconcile your data and confirm treatment with a registered tax practitioner.
Frequently asked questions
Why are exchange CSVs unreliable for tax?
What makes a crypto tax record defensible?
How does Coinfig help?
Sources
Was this helpful?