Die 10 häufigsten Fehler im Krypto-Steuertool aus 500+ Fällen Erfahrung

Quellen: eigene Erfahrung aus über 500 Krypto-Dokumentations-Fällen. Stand: Juni 2026.

Du generierst deinen Steuerreport und da steht ein Gewinn, den es nie gab. Oder ein Dashboard im tiefen Minus. Oder eine Warnung, die nach jedem Fix an anderer Stelle wieder auftaucht. Der erste Gedanke ist fast immer derselbe: Das Tool macht Fehler.

Tut es meistens nicht. Koinly, CoinTracking, Blockpit, Awaken, Summ und andere importieren Tausende Transaktionen automatisch und rechnen korrekt. Sie können nur nicht rekonstruieren, was nie sauber dokumentiert wurde: geschlossene Börsen, vergessene Wallets, DeFi über Jahre, fehlende Euro-Einzahlungen.

Die Erfahrung aus über 500 aufbereiteten Krypto-Dokumentations-Fällen zeigt ein fast immer gleiches Muster: Es ist kein Tool-Problem, sondern ein Dokumentations-Problem. Dieser Artikel zeigt die zehn häufigsten Fehler: was du siehst, woran es liegt und wie man es löst. Tool-übergreifend, weil sie jedes Tool betreffen.

01 Phantom-Gewinn: Warum zeigt der Report einen Gewinn, den es nie gab?

Was du siehst: Der Report weist bei einer Börse einen enormen Gewinn aus, den es real nie gab.

Woran es liegt: Die Börse ist per API angebunden, liefert aber falsche oder negative Bestände. Über die API fehlen Daten: Trades, Ein- und Auszahlungen oder Rewards aus früheren Jahren. Ein Klassiker sind APIs, die nur begrenzt rückwirkend importieren, teils nur wenige Monate. Wer 2023 dort getradet hat und heute neu anbindet, dem fehlen die alten Jahre komplett. Falsche Bestände bei einem Coin lösen bei jedem Trade mit diesem Coin eine Warnung aus, und die erzeugen den Scheingewinn.

Wie man es löst: Den CSV-Export der Börse gegen die API abgleichen, fehlende Zeiträume ergänzen, Bestände begradigen. Danach verschwindet der Scheingewinn, weil die Kostenbasis wieder stimmt.

Aus der Praxis: In nahezu jedem Doku-Check ist das ein Thema. Je nach Portfolio werden die Warnungen sehr hoch, weil sich die Handelsumsätze kumulieren, teils höher als das Portfolio selbst. Mittlere fünf- bis sechsstellige Scheingewinne im Report sind oft der Grund, warum Kunden zu uns kommen.

02 Weggeklickte Warnungen: Warum taucht der Fehler woanders wieder auf?

Was du siehst: Eine nicht verknüpfte Transaktion wirft einen Hinweis. Er wird mit einem schnellen manuellen Eintrag „gelöst" und taucht woanders wieder auf.

Woran es liegt: Statt zu recherchieren, woher die Transaktion kommt, wird sie mit irgendeiner Buchung verknüpft. Beispiel: Eine alte Bitcoin-Einzahlung, deren Herkunft niemand mehr kennt, wird mit der Auszahlung einer anderen Börse verbunden. Der Hinweis verschwindet. Doch auf der anderen Börse fehlen die Coins jetzt, es entsteht ein negativer Bestand, und der wirft die nächste Warnung. Jeder Edit ohne Datenbeleg verschiebt den Fehler nur.

Wie man es löst: An der Wurzel arbeiten: On-Chain-Recherche, Gespräch mit dem Kunden, CSV-Daten sichten, Screenshots und Börsen-E-Mails auswerten, um die echte Historie zu rekonstruieren.

Aus der Praxis: Wir sehen das regelmäßig in Accounts, an denen vorher schon jemand gearbeitet hat, teils mit Buchungen auf Börsen, die der Kunde zu dem Zeitpunkt gar nicht genutzt hat.

03 Falsche Fiat-Bilanz: Warum steht im Dashboard ein dickes Minus?

Was du siehst: Das Dashboard zeigt einen stark negativen Euro-Betrag, zum Beispiel minus 150.000 €.

Woran es liegt: API und CSV importieren häufig die Fiat-Ein- und -Auszahlungen nicht. Dann fehlen die Euro-Beträge, mit denen du Krypto gekauft hast, und das Dashboard rutscht ins Minus. Auf die Berechnung hat das meist keinen Einfluss, solange eine Fiat-Währung im Minus steht (ein Krypto-Bestand im Minus dagegen erzeugt echte Fehler, siehe Punkt 1).

Warum es trotzdem zählt: Genau diese Euro-Bewegungen sind der Abgleich mit deinem Bankkonto und die Grundlage für den Mittelherkunftsnachweis, den eine Bank sehen will. Fehlt dieser Geldfluss in der Doku, fehlt dir später der Nachweis.

Wie man es löst: Fiat-Ein- und -Auszahlungen ergänzen und mit dem Bankkonto abgleichen.

Aus der Praxis: Diese Euro-Einzahlungen tragen wir beim Mittelherkunftsnachweis nach, damit sie mit den Bank-Statements korrespondieren. Das ist ein doppelter Beweis der Vollständigkeit. In einem aktuellen Fall waren die Daten nicht mehr abrufbar und mussten über die Kontoauszüge rekonstruiert werden.

04 Kreditkarten-Kauf (Moonpay & Co.): Warum warnt das Tool bei der Herkunft?

Was du siehst: Auf deiner Wallet (z. B. Phantom) taucht einfach ETH oder SOL auf. Kaufst du damit weiter, kommt eine Warnung wegen unbekannter Herkunft.

Woran es liegt: Wenn du über einen Dienst wie Moonpay direkt in deine Wallet kaufst, ist das auf der Blockchain nur ein Transfer von A nach B. Das Tool erkennt nicht, dass ein Kreditkartenkauf dahintersteht. Es sieht aus, als hättest du die Coins von einer eigenen Wallet geschickt. Die Herkunft ist nicht nachvollziehbar.

Wie man es löst: Die Tranche manuell als Fiat-Kauf eintragen, mit der zugehörigen Euro-Zahlung davor. Im Kommentar festhalten, über welche Karte gekauft wurde.

Aus der Praxis: Betrifft praktisch jeden, der über Moonpay und ähnliche Dienste direkt über die Wallet (Phantom, Ledger und Co.) mit Fiat kauft.

05 DeFi falsch importiert: Warum erfindet der Report Rewards und Gewinne?

Was du siehst: Erfundene Rewards, aufgeblähte Gewinne und Bridge-Vorgänge, die als Trades auftauchen.

Woran es liegt: DeFi ist komplex, ändert sich ständig und existiert über zig Blockchains mit unterschiedlichen Protokollen. Kein Tool bildet das automatisch korrekt ab. Tools erkennen oft die einzelnen Bewegungen einer DeFi-Transaktion, klassifizieren sie aber nicht, sondern importieren sie nur als Ein- und Auszahlung. Den Rest musst du selbst zuordnen. Typische Fehler:

• Eine Liquidity-Pool-Auszahlung wird komplett als Reward gewertet. Das erzeugt Gewinne, die so nie geflossen sind.
• Ein Bridge-Swap (Token A auf Blockchain X rein, Token B auf Blockchain Y raus) wird nicht als ein Vorgang erkannt.
• Manche Bridges haben Eigenheiten: Bei deBridge buchen Tools statt der Auszahlung oft einen Trade gegen eine kleine USDC-Tranche. Im Hintergrund swappt deBridge in USDC, schickt es auf die andere Chain und kauft dort den Zieltoken.

Wie man es löst: Manuelle Klassifizierung pro Protokoll, nach On-Chain-Abgleich.

Aus der Praxis: deBridge ist uns dieses Jahr mehrfach begegnet, etwa bei Bridges von Solana nach BNB Chain oder nach Ethereum.

06 Convert-, Karten- und P2P-Käufe: Warum werden sie als Einnahme verbucht?

Was du siehst: Ständige USDT-„Einzahlungen", die teils sogar als steuerpflichtige Einnahme verbucht werden.

Woran es liegt: Bei Sparplänen oder regelmäßigen Kreditkartenkäufen auf manchen Börsen liest die API die Vorgänge nicht korrekt aus. Die gekaufte Währung erscheint einfach als Einzahlung, zum Beispiel als laufende USDT-Zuflüsse. Erst durch Rückfragen und CSV-Abgleich erkennt man, dass es sich um Euro-Converts in USDT oder um Kreditkarten- bzw. P2P-Käufe handelt. Schlimmer: Manche Tools verbuchen solche Fiat-Käufe nicht als Einzahlung, sondern als steuerpflichtige Einnahme. Das findest du erst, wenn du genau in den Report schaust.

Wie man es löst: Die Tranche manuell als Fiat-Kauf mit zugehöriger Fiat-Zahlung eintragen und den Hintergrund im Kommentar festhalten.

Aus der Praxis: Häufig bei Sparplan-Käufern. Etwa jeder fünfte Fall.

07 API-Reimport: Warum entstehen plötzlich Dubletten?

Was du siehst: Plötzlich Dubletten, doppelte Bestände und neue Warnungen, obwohl vorher alles sauber war.

Woran es liegt: Zwei Ursachen. Erstens: Man hat per CSV importiert und manuell vervollständigt, verbindet dann die API neu, ohne ein Startdatum zu setzen. Die API importiert alles erneut, es entstehen Dubletten. Zweitens: Börsen ändern ihre internen IDs für Trades und Ein-/Auszahlungen. Beim API-Sync gleicht das Tool diese IDs ab; neue IDs gelten als neue Transaktionen, obwohl sie längst importiert sind. Wieder Dubletten.

Wie man es löst: Vor jedem Reimport einen Snapshot sichern und ein Startdatum für den Import setzen.

Aus der Praxis: Relativ oft, vor allem bei mehrjährigen Historien. Börsen und ihre APIs haben sich über die Jahre verändert.

08 Geschlossene Börse: Was tun, wenn die Historie nicht mehr existiert?

Was du siehst: Ganze Zeiträume fehlen.

Woran es liegt: Plattformen wurden abgeschaltet und die Historie nie oder nur teilweise gesichert. Beispiele sind MtGox, Coinbase Pro, FTX, Bittrex, Bitpanda Pro, Bitvavo (vor Bitvavo by Hyphe), Celsius und andere.

Wie man es löst: Rekonstruktion über mehrere Quellen: Support-Anfragen, On-Chain-Analyse, Abgleich mit korrespondierenden Börsen und Wallets des Kunden, alte Exports, Screenshots und Börsen-E-Mails. Mehr dazu: Krypto-Historie rekonstruieren.

Aus der Praxis: Zuletzt Coinbase Pro, davor zum Beispiel Hotbit. Dort haben wir über Screenshots aus der damaligen Zeit, alte Bestands-Screenshots und On-Chain-Recherche rekonstruiert, was ungefähr wann gekauft wurde.

09 Fehlende Wallet-Adressen: Warum gehen die Bestände nicht auf?

Was du siehst: Aktivität fehlt und Bestände gehen nicht auf, weil ganze Wallets im Tool fehlen.

Woran es liegt: Wer viel ausprobiert (Bridging, Airdrop-Farming auf kleineren Chains, DeFi-Protokolle testen, privacy-bewusstes Verhalten) nutzt oft für jede neue Chain, jedes neue Protokoll oder nach einer gewissen Zeit eine neue Adresse. So entstehen über eine Krypto-Laufzeit schnell 20 bis 40 Adressen oder deutlich mehr. Dazu kommt der Wechsel zwischen Cold-Wallets (Ledger, Trezor, Tangem) und Hot-Wallets (MetaMask, Rabby). Wer diese Adressen über Jahre nicht dokumentiert, vergisst einige, und ihre Aktivität fehlt im Tool.

Wie man es löst: On-Chain-Analyse, um die fehlenden Adressen und ihre Bewegungen zu finden und die Lücken zu schließen.

Aus der Praxis: Ein klassischer Fall: Jemand hat an mehreren ICOs teilgenommen und für jedes eine eigene Adresse verwendet, die über die Jahre in Vergessenheit geriet.

10 IDOs, ICOs und Pre-Sales: Warum sieht das Tool nur zwei Transfers?

Was du siehst: Ein ETH-Abgang an eine unbekannte Adresse, Monate später der Eingang eines bis dahin unbekannten Tokens. Für das Tool zwei zusammenhanglose Transfers.

Woran es liegt: Bei IDOs, Pre-Sales und ICOs sieht das Tool nur die beiden Transfers, nicht den Zusammenhang. Die Verknüpfung gelingt nur über On-Chain-Recherche und den Kontext des Kunden. Aufwendiger wird es bei Vestings, wenn der Token über lange Zeiträume in Tranchen freigeschaltet wird.

Wie man es löst: Rekonstruktion über On-Chain-Analyse und Absprache mit dem Kunden. Die Anschaffung lässt sich über eine eigene Pre-Sale-Struktur plus Vesting sauber abbilden.

Aus der Praxis: Häufig bei Accounts, die schon 2017 und 2021 dabei waren.

Das Muster hinter allen zehn

Schau dir die zehn Punkte an: Fast keiner ist ein Rechenfehler des Tools. Es sind fehlende Daten, nicht erkannte Zusammenhänge und unvollständige Historien. Ein Tool kann nur abbilden, was sauber dokumentiert ist. Genau dort setzt Krypto-Dokumentation an: Daten zusammenführen, abgleichen, rekonstruieren und belegen, damit der Report stimmt und auch der Bank standhält.

Das ist auch der Grund, warum DAC8 die Sache ernster macht. Regulierte Krypto-Dienstleister erfassen die Daten ab 2026, der EU-weite Austausch mit den Finanzämtern startet 2027. Das Finanzamt gleicht die gemeldeten Werte dann mit deiner Erklärung ab, und schon eine Abweichung löst eine Rückfrage aus. Ein Report, der auf lückenhaften Daten steht, fällt dabei eher auf. Die Lösung ist nicht das nächste Tool, sondern eine vollständige Dokumentation darunter.