DATEV Buchung nachträglich korrigieren ohne Doppelimport
Wenn Sie eine frühere Marketplace- oder Zahlungsbuchung korrigieren müssen, ist die entscheidende Frage, ob die Änderung im vorhandenen DATEV-Datensatz bleibt oder als eigene Korrektur erfasst wird. Der Unterschied ist praktisch wichtig: Laut DATEV werden kopierte oder verschobene Buchungen beim erneuten Einfügen wieder exportiert und importiert. Wer die Korrektur wie eine neue Buchung behandelt, riskiert damit einen Doppelimport.
TaxRouter Redaktion

Zuerst prüfen, welcher Datensatz schon vorhanden ist
Bei einer nachträglichen Korrektur sollten Sie zuerst prüfen, ob die ursprüngliche Buchung in DATEV bereits als vollständiger Datensatz vorliegt. Der Buchungsdatenservice überträgt vollständige Buchungssätze, also Buchungsdaten, Stammdaten und zugehörige Belegbilder. Das ist wichtig, weil eine historische Korrektur nicht dasselbe ist wie ein neuer Import aus dem Quellsystem.
Die DATEV-Datenservices übertragen strukturierte Daten und digitale Belege in DATEV-Programme; in einzelnen Fällen kann der Datenfluss auch in die andere Richtung laufen. Für Ihre Entscheidung zählt vor allem, dass Sie mit einem strukturierten Buchungssatz arbeiten und nicht mit einer losen Notiz oder nur einem Belegbild. Wenn die Buchung bereits existiert, geht es darum, ob Sie diesen Datensatz ändern oder daneben einen zweiten anlegen.
- Ein Buchungssatz kann Buchungsdaten, Stammdaten und Belegbilder enthalten.
- Eine historische Korrektur gehört an den bestehenden Datensatz und nicht automatisch als neue Buchung behandelt.
- Je nach Konstellation kann der Datenfluss auch in die Gegenrichtung laufen.
Warum es bei Kopieren und Verschieben zum Doppelimport kommt
Das DATEV-Hilfe-Center beschreibt, dass kopierte oder verschobene Buchungen exportiert und danach erneut importiert werden, wenn sie noch einmal eingefügt werden. Genau daraus entsteht das Risiko eines Doppelimports, wenn die Korrektur nicht als Anpassung des vorhandenen Datensatzes, sondern als neue Buchung behandelt wird. Es geht dabei um das erneute Einspielen des Buchungsobjekts, nicht um eine inhaltliche Änderung der ursprünglichen Erfassung.
Für die Praxis heißt das: Sobald Ihre Korrektur einen zusätzlichen Buchungssatz erzeugt, läuft sie wieder durch den Importprozess. Wenn Sie nur den historischen Datensatz berichtigen wollen, ist ein kopierter oder verschobener Buchungssatz nicht mit einer Korrektur im bestehenden Eintrag gleichzusetzen.
- Kopierte oder verschobene Buchungen werden beim erneuten Einfügen wieder exportiert und importiert.
- Ein Doppelimport-Risiko entsteht, wenn die Korrektur als neue Buchung angelegt wird.
- Der bestehende Datensatz zu ändern ist etwas anderes, als eine zweite Buchung einzufügen.
Quellen: [4]
Kontenplan und Belegzuordnung nicht vermischen
DATEV trennt den Kontenplan von der konkreten Kontenzuordnung einzelner Belege. Diese Unterscheidung hilft bei der Frage, wo die historische Korrektur ansetzen soll. Der Kontenplan ist die Struktur, die Belegzuordnung ist die konkrete Buchung eines einzelnen Vorgangs.
Wenn ein Vorgang auf das falsche Konto gebucht wurde, betrifft die Korrektur die konkrete Zuordnung des Belegs, nicht den Kontenplan als Ganzes. Sie ändern also nicht die Buchhaltungsstruktur, nur weil eine Marketplace- oder Zahlungsbuchung falsch erfasst wurde. Dadurch lässt sich die Korrektur meist am ursprünglichen Buchungssatz festmachen, statt einen zweiten Import auszulösen.
- Kontenplan und konkrete Belegzuordnung sind nicht dasselbe.
- Eine falsche Buchung betrifft meist die einzelne Zuordnung, nicht die gesamte Struktur.
- Die Korrektur auf Buchungsebene hilft, aus einem Vorgang keinen zweiten Import zu machen.
Quellen: [3]
Wann eine historische Änderung eine eigene Korrektur braucht
Nicht jede nachträgliche Änderung gehört in den ursprünglichen Buchungssatz. § 17 UStG verlangt eine Berichtigung, wenn sich die Bemessungsgrundlage ändert; die Berichtigung erfolgt für den Besteuerungszeitraum, in dem die Änderung eingetreten ist. Für die Praxis bedeutet das: Eine spätere Änderung kann einen eigenen Korrekturschritt erfordern und muss nicht bloß im alten Datensatz überschrieben werden. Die steuerliche Aussage betrifft den Zeitraum der Änderung, nicht die konkrete Bedienung der Software.
Eine separate Korrektur ist dann naheliegend, wenn der ursprüngliche Datensatz die geänderte Grundlage nicht mehr abbildet. In diesem Fall geht es nicht darum, die alte Buchung verschwinden zu lassen, sondern die Änderung dem richtigen Zeitraum zuzuordnen. Die Entscheidung lautet also: ursprüngliche Buchung erhalten und späteren Anpassungsfall sauber abgrenzen, statt die Änderung als neue Erstbuchung einzuspielen.
- Ändert sich die Bemessungsgrundlage, ist eine Berichtigung für den Zeitraum der Änderung vorgesehen.
- Eine spätere Anpassung kann einen eigenen Korrekturschritt brauchen.
- Entscheidend ist, welchem Zeitraum die Änderung zuzuordnen ist.
Quellen: [5]
Beleg- und Nachweiskette lückenlos halten
Bei einer Korrektur im Nachhinein muss auch der Nachweis nachvollziehbar bleiben. § 257 HGB verlangt die Aufbewahrung von Buchungsbelegen und setzt den Beginn der Aufbewahrungsfrist auf das Jahresende, in dem der Beleg entstanden ist. Für historische Korrekturen heißt das: Beleg und Buchungshistorie müssen so verbunden bleiben, dass der Vorgang später nachvollziehbar ist.
Genau hier zeigt sich der Unterschied zwischen einer Korrektur im bestehenden Datensatz und einer separaten Korrektur in der Praxis. Das Aufbewahrungsrecht sagt nicht, wie Sie die Änderung technisch buchen sollen, aber es verlangt, dass der ursprüngliche Nachweis nicht verloren geht. Wenn Sie separat korrigieren, sollte der Bezug zum Ausgangsbeleg klar bleiben. Wenn Sie im bestehenden Satz korrigieren, muss der Prüfpfad lesbar bleiben. Dieser Beitrag bietet allgemeine Informationen und ist keine Steuer- oder Rechtsberatung.
- Der ursprüngliche Beleg muss nachvollziehbar erhalten bleiben.
- Die Aufbewahrungsfrist beginnt mit dem Jahresende, in dem der Beleg entstanden ist.
- Unabhängig von der Korrekturmethode sollte die Nachweiskette lesbar bleiben.
Quellen: [6]