Krypto-Daten importieren: CSV, API und Wallets richtig zusammenführen

Ein vollständiger Steuerreport beginnt nicht mit der Berechnung, sondern mit einem kontrollierten Import. CSV-Dateien, Börsen-APIs und öffentliche Walletadressen liefern unterschiedliche Ausschnitte. Werden sie ungeprüft kombiniert, entstehen Dubletten, fehlende Kostenbasis oder erfundene Verkäufe. Dieser Workflow zeigt, welche Quelle wofür geeignet ist und wie die Vollständigkeit geprüft wird.

Stand: 4. September 2026. Exportnamen und API-Funktionen ändern sich. Verwende die aktuelle Dokumentation des jeweiligen Anbieters und ausschließlich notwendige Leserechte.

Keine Datenquelle zeigt automatisch die ganze Historie

Viele Börsen teilen Spot, Earn, Futures, Kartenumsätze und Ein-/Auszahlungen in getrennte Exporte. Ein „Trade History“-CSV kann deshalb korrekt und trotzdem unvollständig sein. Vor dem Import wird eine Quellenliste je Jahr, Konto, Subaccount, Wallet und Chain erstellt.

CSV-Import: reproduzierbar, aber formatabhängig

CSV-Dateien lassen sich unverändert archivieren und später erneut einlesen. Das ist ein wichtiger Vorteil für den Audit-Trail. Gleichzeitig variieren Spaltennamen, Trennzeichen, Dezimalformat, Zeitzone und Ereignisbegriffe. Eine Datei darf nicht nur deshalb als korrekt gelten, weil sie ohne Fehlermeldung geladen wurde.

Vor dem Hochladen prüfen

• Kontoname, Exporttyp und Zeitraum;
• Zeitzone und Datumsformat;
• Dezimalpunkt oder Dezimalkomma;
• Asset, Quote-Asset und Gebühren-Asset;
• Order-ID, Trade-ID und Transaktionshash;
• ob Stornos, interne Transfers oder Snapshots enthalten sind;
• Zeilenanzahl und Dateiversion.

Die Originaldatei bleibt unverändert. Muss ein Format konvertiert werden, werden Quelldatei, konvertierte Datei und Mapping dokumentiert. Dadurch ist nachvollziehbar, ob ein Wert vom Anbieter oder aus einer späteren Korrektur stammt.

API-Import: nur mit minimalen Rechten

Eine API kann neue Transaktionen regelmäßig abrufen und reduziert manuelle Exporte. Der Schlüssel sollte ausschließlich Lesezugriff besitzen. Handels-, Auszahlungs- oder Transferrechte sind für einen Steuerimport nicht erforderlich. IP-Beschränkung und ein eigener Schlüssel pro Anwendung reduzieren das Risiko.

Auch eine erfolgreiche API-Verbindung beweist keine Vollständigkeit. Manche Endpunkte liefern nur einen begrenzten Zeitraum, andere Produkte benötigen separate Abfragen. Pagination, Rate Limits, Subaccounts und nachträgliche Korrekturen des Anbieters müssen berücksichtigt werden. Der Import speichert deshalb stabile externe IDs und Abrufzeitpunkte.

API-Schlüssel sicher behandeln

1. Neuen Schlüssel speziell für den Steuerimport anlegen.
2. Nur erforderliche Read-only-Berechtigungen aktivieren.
3. Auszahlungen und Handel ausdrücklich deaktivieren.
4. Schlüssel nicht per E-Mail oder Screenshot weitergeben.
5. Nach Nutzung widerrufen oder regelmäßig rotieren.
6. Aktive Schlüssel im Börsenkonto kontrollieren.

Wallet-Import: Adresse und Chain gehören zusammen

Öffentliche Adressen können ohne Seed Phrase importiert werden. Die gleiche hexadezimale Adresse kann auf mehreren EVM-Chains existieren; jede Chain besitzt jedoch einen eigenen Transaktionsverlauf. Ein Ethereum-Import enthält nicht automatisch Base, Arbitrum oder Polygon.

Der Blockchain-Explorer-Leitfaden erklärt Normal Transactions, Internal Calls, Token- und NFT-Logs. Ein DEX-Swap kann mehrere technische Bewegungen erzeugen, die zu einem wirtschaftlichen Vorgang zusammengeführt werden müssen. Eine Walletadresse kennt außerdem keine Fiatkäufe auf einer zentralen Börse.

Empfohlene Importreihenfolge

1. Steuerjahr und benötigte Vorhistorie festlegen.
2. Alle zentralen Konten und Subaccounts importieren.
3. Self-Custody-Adressen je Chain ergänzen.
4. Fiatbewegungen und manuelle Sonderfälle erfassen.
5. Transfers anhand externer IDs, Hashes, Zeit und Menge paaren.
6. DeFi-, Staking- und Derivateereignisse klassifizieren.
7. Preise und Anschaffungskosten prüfen.
8. Endbestände je Speicherort abstimmen.

Vorhistorie ist wichtig, wenn im Steuerjahr Bestände verkauft werden, die früher erworben wurden. Ein Import nur ab 1. Januar kann mengenmäßig vollständig wirken und trotzdem die Kostenbasis verlieren. Der Portfolio-Leitfaden beschreibt die jahresübergreifende Überleitung.

Dubletten systematisch erkennen

Typische Dubletten entstehen durch API plus CSV, mehrere Exporte mit überlappendem Zeitraum oder Walletdaten aus zwei Explorerquellen. Bei Börsentrades dienen Konto, Trade-ID und Order-ID als Schlüssel. On-chain sind Chain, Hash und Log-Index entscheidend. Zeit, Asset und Menge allein reichen nicht immer, weil identische Teilfüllungen möglich sind.

Der Eigenübertrag-Leitfaden zeigt, warum zwei passende Zeilen nicht immer Dubletten sind. Eine Seite belegt den Abgang, die andere den Zugang.

Vier Kontrollen vor der Berechnung

• Vollständigkeit: Stimmen Quellenliste und importierte Konten überein?
• Menge: Passen rechnerische und tatsächliche Endbestände?
• Bewertung: Sind Fiatkurse, illiquide Token und fehlende Preise gekennzeichnet?
• Klassifizierung: Sind Transfers, Trades, Einnahmen und Informationen getrennt?

Fehlt ein Preis, wird der betroffene Vorgang als nicht berechenbar markiert; andere vollständige Positionen laufen weiter. Fehlt die Herkunft einer Einzahlung, wird keine bestätigte Nullkostenbasis erfunden. Die Datenqualitäts-Checkliste priorisiert solche Fehler nach Auswirkung.

Ein finaler Steuerreport enthält neben Ergebnissen auch Quellen, Annahmen, Korrekturen und offene Punkte. Das BMF verlangt eine plausible Prüfung softwaregenerierter Ergebnisse. „Import erfolgreich“ ist deshalb nur ein technischer Status, keine fachliche Freigabe.

Fehlerprotokoll statt stiller Reparatur

Importsoftware sollte problematische Zeilen nicht kommentarlos verwerfen. Sinnvoll ist ein Fehlerprotokoll mit Dateiname, Zeilennummer, Originalwert, erkanntem Problem und vorgeschlagener Korrektur. So bleibt der Import reproduzierbar. Typische Fälle sind ein ungültiges Datum, ein unbekanntes Dezimaltrennzeichen, eine fehlende Quote-Währung oder ein noch nicht zugeordnetes Ereignis.

Bei fehlenden Preisen sollte die Transaktion mengenmäßig weitergeführt und als „nicht berechenbar“ markiert werden. Dadurch blockiert ein einzelner illiquider Token nicht die Auswertung aller anderen Assets. Die offene Bewertung muss jedoch im Prüfblatt erscheinen und darf nicht als null in das Ergebnis einfließen. Dasselbe Prinzip gilt für unklare Events: Rohdaten bewahren, vorläufige Klassifizierung kennzeichnen und fachliche Entscheidung dokumentieren.

Nach einer Korrektur sollte der Import erneut aus denselben Rohdaten laufen können. Direkte Änderungen nur in einer Ergebnistabelle sind riskant, weil sie bei der nächsten Synchronisierung verschwinden. Besser sind stabile Zuordnungsregeln oder ein separates, versioniertes Korrekturprotokoll.

Häufige Fragen

Amtliche und technische Quellen

• BMF: Aufzeichnungs- und Mitwirkungspflichten bei Kryptowerten
• Ethereum.org: On-chain-Transaktionsdaten

Hinweis: Dieser Artikel dient ausschließlich zur allgemeinen Information und stellt keine Steuerberatung dar. Für individuelle Steuerberatung wende dich an einen zugelassenen Steuerberater.