DATEV findet eine Kontonummer aus Ihrem Buchungsstapel im Mandantenstamm nicht. Der Stapel selbst ist formal in Ordnung, sonst wären Sie gar nicht bis zu dieser Meldung gekommen. Er verweist auf ein Sach- oder Personenkonto, das es in diesem Mandanten, in diesem Kontenrahmen oder in diesem Wirtschaftsjahr nicht gibt. Entweder legt die Kanzlei das Konto an, oder das Vorsystem kontiert auf ein vorhandenes. Wer beides nebeneinander laufen lässt, sieht die Meldung im nächsten Monat wieder.
Beim Import bricht der Stapel ab. Die Meldung nennt ein Konto, das es angeblich nicht gibt, und Ihre erste Vermutung ist ein Formatfehler in der Datei.
Ist es nicht. DATEV prüft für jeden Buchungssatz, ob die angegebene Kontonummer im Mandantenstamm angelegt ist, und weist den Satz ab, wenn sie fehlt. Je nach Importweg bleibt es bei einer Fehlerzeile im Protokoll oder der ganze Stapel wird zurückgewiesen. Header, Spaltenanzahl und Zeichensatz waren in Ordnung, sonst hätte der Import viel früher aufgehört. Es geht um einen Verweis auf Stammdaten, die auf der DATEV-Seite fehlen.
Ein Shop kennt keinen Kontenrahmen. Ein Zahlungsdienstleister auch nicht. Diese Systeme liefern Geschäftsvorfälle, und irgendwo dazwischen entscheidet jemand, auf welches Konto ein Vorfall gehört. Diese Entscheidung wird einmal getroffen, meist bei der Einrichtung, und veraltet danach still vor sich hin, während das Geschäft weiterläuft.
Die Auslöser wiederholen sich, quer über Kunden und Branchen:
| Auslöser | Was neu ist |
|---|---|
| Erstes Verkaufsland im OSS-Verfahren | Ein Erlöskonto je Land oder Steuersatz |
| Neuer Zahlungsdienstleister | Ein eigenes Geldtransitkonto für Stripe, PayPal, Klarna oder Mollie |
| Erste Gutschrift oder Erstattung | Ein Konto für Erlösschmälerungen |
| Wechsel des Wirtschaftsjahres | Konten, die im neuen Jahr noch nicht angelegt sind |
| Umstellung des Kontenrahmens | Dieselbe Nummer bedeutet in SKR03 und SKR04 etwas anderes |
| Neue Debitorennummer | Personenkonto im Mandanten fehlt |
Immer dasselbe Muster: Die Stammdaten haben sich bewegt, die Kontierungslogik im Export nicht.
Ob eine Nummer zum falschen Kontenrahmen gehört, sehen Sie in unserer SKR03-SKR04-Gegenüberstellung: Geben Sie die Kontonummer aus dem Protokoll ein, und das Tool zeigt, was sie in SKR03 und was sie in SKR04 bedeutet.
Ziehen Sie zuerst die Kontonummer aus dem Protokoll. Nennt es die Zeile, sehen Sie in Spalte 7 und Spalte 8 nach, also Konto und Gegenkonto. Dann prüfen Sie in DATEV, ob es dieses Konto im Mandanten überhaupt gibt, und zwar im richtigen Wirtschaftsjahr und im richtigen Kontenrahmen.
Prüfen Sie dabei auch die Sachkontenlänge. Ein vierstelliges Konto in einem Mandanten mit fünfstelligen Sachkonten wird nicht gefunden, obwohl die Nummer inhaltlich stimmt, und dieser Fall sieht exakt gleich aus wie ein wirklich fehlendes Konto. Personenkonten liegen in einem eigenen Nummernkreis und verhalten sich hier anders als Sachkonten. Ob Kontonummern und Sachkontenlänge zueinander passen, zeigt unser EXTF-Validator für die ganze Datei auf einmal.
Am Ende steht eine Entscheidung, und zwar nur eine: Entweder das Konto wird angelegt, oder der Export kontiert anders. Beides gleichzeitig zu machen ist der schnellste Weg, dieselbe Meldung nächsten Monat auf einem anderen Konto wiederzusehen.
Wir prüfen die Kontierung gegen die vorhandenen Konten, bevor überhaupt eine Datei entsteht. Was sich nicht auflösen lässt, taucht bei uns als benannter Fehler auf und nicht als abgebrochener Import bei Ihrer Kanzlei.
Ein unbekannter Fall hält dabei nicht den ganzen Monat auf. Der betroffene Datensatz wird zurückgehalten und gemeldet, alles andere läuft durch. Ohne diese Trennung wartet ein kompletter Buchungsstapel auf eine einzige neue Bestellung aus Belgien.
Die Kontierungsregeln liegen an einer Stelle, sind nachlesbar und versioniert, statt in einer Excel-Formel oder einem gewachsenen Skript zu stecken. Und ein neuer Fall, also ein erstes Verkaufsland oder ein neuer Zahlungsdienstleister, erzeugt eine Meldung an dem Tag, an dem er auftritt.
Eine deutsche Fachquelle schätzt, dass rund 80 Prozent der wiederkehrenden Probleme mit Buchungsstapeln auf Stammdaten zurückgehen und nicht auf das Stapelformat. Das deckt sich mit dem, was wir sehen. Kontierung und Stammdatenabgleich stehen bei uns deshalb im laufenden Betrieb, mit einem festen Termin je Mandant.
Sie sehen das im Livebetrieb und möchten, dass es nicht mehr Ihr Problem ist? Wir konzipieren, bauen und betreiben die Schnittstelle dauerhaft, inklusive der Validierung und Wiederholungslogik, die diese Art von Fehler gar nicht erst bei Ihnen ankommen lässt. Festpreis-Angebot zur Aufwandsabschätzung innerhalb von 48 Stunden.