DATEV Buchungsstapel importieren: Fehler im Importprotokoll

Ein Buchungsstapel aus einem Shop, einem Zahlungsdienstleister oder einem anderen Vorsystem landet über die Stapelverarbeitung in DATEV Rechnungswesen. Was dabei schiefgeht, steht im Importprotokoll. Die Meldungen klingen technisch, lassen sich aber in wenige Gruppen sortieren, und die Gruppe sagt Ihnen, wo Sie suchen müssen.

Wo das Importprotokoll liegt

Importiert wird bei geöffnetem Mandantenbestand über Bestand | Importieren | Stapelverarbeitung. Nach dem Import über die Stapelverarbeitung oder den ASCII-Import zeigt DATEV das Importprotokoll automatisch an. Später rufen Sie es über Bestand | Importieren | Importprotokoll auf.

Das Protokoll listet alle Verarbeitungsläufe des Mandanten im gewählten Jahr. Jeder Lauf hat einen Status: fehlerfrei, mit Hinweisen, mit fachlichen Fehlern oder mit technischen Fehlern. Daneben stehen unter anderem Herkunft, Dateiname, Datenkategorie, Zeitraum, Festschreibestatus sowie Formatname und Formatversion.

Zwei Handgriffe machen lange Protokolle lesbar. Per Rechtsklick auf die Spalte Meldungsnr. gruppieren Sie die Einträge nach Meldung, dann sehen Sie, ob es ein Problem in 300 Zeilen ist oder 300 verschiedene. Und über das Kontextmenü öffnen Sie die Liste mit Excel, um sie an die Kanzlei oder an den Hersteller des Vorsystems weiterzugeben.

Die häufigen Fehlerklassen

Was passiert	Typische Meldung	Wo das Problem liegt
Datei taucht in der Stapelverarbeitung nicht auf	#REW04506, „Keine Daten vorhanden“	Dateiname, Header-Zeile, Pfad oder Ordnungsbegriffe
Stapel gehört nicht zum geöffneten Mandanten	#REW90142	Berater, Mandant oder Wirtschaftsjahr im Header, siehe Beraternummer nicht gefunden
Sachkontenlänge passt nicht	#REW10152 (Header größer), #REW10153 (Header kleiner)	Header und Mandanteneinstellung, siehe Sachkontenlänge stimmt nicht mit dem Mandanten überein
Datumsbereich über den Jahreswechsel	#REW04404	„Datum von“ und „Datum bis“ liegen in verschiedenen Kalenderjahren
Belegdatum vor Beginn des Wirtschaftsjahres	#REW00314	Belegdatum oder Wirtschaftsjahr im Export
Konto im Mandanten nicht angelegt	Konto existiert nicht	Stammdaten oder Kontierung, siehe Konto existiert nicht
Schlüssel widerspricht dem Konto	#REW00305, #REW00310	Kontierungslogik, siehe Ungültiger BU-Schlüssel

Die oberen vier Zeilen betreffen den Stapel als Ganzes und brechen ab, bevor eine einzelne Buchung zählt. Die unteren drei betreffen einzelne Buchungssätze. Bei diesen lohnt der Blick, ob es immer dasselbe Konto oder derselbe Schlüssel ist: Dann steckt eine Regel im Vorsystem dahinter und kein Einzelfall.

Hinweise, die man nicht wegklicken sollte

Manche Einträge sind keine Fehler, sondern dokumentieren, dass DATEV die Daten beim Import verändert hat. DATEV protokolliert das wegen der GoBD. Bei Schnittstellen sind drei davon aufschlussreich:

• #REW92177: Ein leeres Feld Kontonummer wurde aus dem vorherigen Buchungssatz übernommen, weil das Konto in der Buchungszeile als Schleppfeld eingestellt ist. Liefert der Export für eine Zeile kein Konto, bucht DATEV also auf das Konto der Vorzeile.
• #REW92178: Führungsnullen in Belegfeld 1 oder 2 wurden gemäß den Import-Einstellungen abgeschnitten.
• #REW92185: Eine Generalumkehr kam mit Berichtigungsschlüssel und wurde auf das Kennzeichen „G“ im Feld GU umgestellt.

Der erste Hinweis ist der wichtigste. Er zeigt einen Export, der Pflichtfelder leer lässt, und die Buchung landet trotzdem irgendwo.

Formatregeln, an denen eine EXTF-Datei scheitert

Das DATEV-Format ist eine CSV-Datei mit festem Aufbau. Laut Formatbeschreibung im DATEV Developer Portal gilt:

Regel	Was DATEV erwartet
Dateiname	Beginnt mit EXTF_ und endet auf .csv
Zeile 1	Header mit den Metadaten, unter anderem Berater, Mandant, Wirtschaftsjahr, Sachkontenlänge und Zeitraum
Zeile 2	Spaltenüberschriften gemäß Formatbeschreibung
Ab Zeile 3	Ein Datensatz pro Zeile
Trennzeichen	Semikolon, am Zeilenende CR/LF
Textfelder	In Anführungszeichen, enthaltene Anführungszeichen verdoppelt, keine Zeilenumbrüche im Feld
Zahlen	Komma als Dezimaltrenner, in der Regel ohne Tausenderpunkt
Zeichensatz	ISO-8859-1 bzw. Codepage 1252; UTF-8 nur mit Byte Order Mark
Zeitraum	Ein Stapel darf nicht über einen Kalenderjahreswechsel gehen

Steht in der ersten Zelle nicht EXTF oder DTVF, sondern bereits „Umsatz“, fehlt die Header-Zeile. Das passiert typischerweise, wenn eine Datei in Excel geöffnet und wieder gespeichert wurde.

Diese Regeln und die Feldlängen der einzelnen Spalten prüft unser kostenloser EXTF-Validator im Browser, bevor die Datei bei der Kanzlei ankommt. Was er nicht sehen kann, sind die Stammdaten des Mandanten: ob ein Konto angelegt ist und ob Berater und Mandant zum Bestand gehören.

Festschreibung beim Import

Seit Version 5.1 enthält das DATEV-Format ein Festschreibekennzeichen. Steht es auf „Ja“, sind die importierten Buchungen festgeschrieben. Aufheben lässt sich das beim Import nur über ein Ausnahmerecht in der Rechteverwaltung, und jede Aufhebung wird protokolliert und muss bei einer Betriebsprüfung begründet werden. Dateien in älteren Formatversionen ohne Kennzeichen schreibt DATEV automatisch fest.

Für Schnittstellen heißt das: Ein fehlerhafter Stapel mit Festschreibung lässt sich nicht einfach nachträglich korrigieren. Die Prüfung gehört vor den Export.

Was eine betriebene Schnittstelle anders macht

Die meisten Meldungen in dieser Liste entstehen nicht beim ersten Import, sondern Monate später: nach einem Kanzleiwechsel, beim ersten Verkauf in ein neues Land, beim Jahreswechsel. Wir erzeugen den Header aus der Mandantenkonfiguration, prüfen Kontierung und Schlüssel gegen die tatsächlichen Konten und halten einen Datensatz, der nicht aufgeht, zurück, statt den ganzen Stapel scheitern zu lassen. Was dabei auffällt, melden wir an dem Tag, an dem es passiert, und nicht erst, wenn die Kanzlei das Importprotokoll öffnet.