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
Primary sources for South Africa: browse the official documents
Was this helpful?