Doppelte Kreditoren vermeiden: die Nummern gehören der Buchhaltung

Ein Buchungsstapel braucht ein Gegenkonto, also ein Kreditorenkonto je Lieferant. Wenn das Vorsystem diese Nummer selbst vergibt, hat es zwei Möglichkeiten. Entweder sie stimmt zufällig mit der Buchhaltung überein, oder es entsteht ein zweiter Kreditor.

Der zweite Fall ist der Normalfall, und er ist unangenehm leise.

Was genau passiert

Beim Import lehnt die Buchhaltung eine unbekannte Kontonummer nicht ab. Sie legt ein neues Personenkonto an oder verlangt eines. Danach existiert derselbe Lieferant zweimal, unter der alten Nummer aus der Vergangenheit und unter der neuen aus dem Vorsystem.

Sichtbar wird das erst später, an drei Stellen:

• Die offenen Posten verteilen sich auf zwei Konten. Was auf dem einen bezahlt wurde, steht auf dem anderen weiter offen.
• Die Saldenliste führt den Lieferanten doppelt, mit zwei Teilsummen, die einzeln plausibel aussehen.
• Die Auswertung nach Lieferant zerfällt. Wer wissen will, was ein Anbieter im Jahr gekostet hat, bekommt zwei Antworten.

Aufgeräumt wird das von Hand, und zwar in der Kanzlei, nicht im Vorsystem.

Warum es so leicht passiert

Das Vorsystem kennt den Kreditorenstamm nicht. Es sieht einen Lieferantennamen auf einer Rechnung und braucht eine Zahl. Eine Zahl zu erfinden ist technisch trivial und fachlich falsch.

Hinzu kommt, dass der Fehler beim ersten Export nicht auffällt. Der Stapel importiert sauber, die Beträge stimmen, die Summe stimmt. Falsch ist nur, auf welchem Konto sie landet.

Der richtige Weg, in drei Schritten

Erstens den Stamm anfordern. Die Kanzlei exportiert den Kreditorenstamm, üblicherweise als Liste mit Kontonummer und Name. Wer selbst bucht, zieht sie aus dem eigenen Rechnungswesen. Wer ein ERP im Einsatz hat, findet die Nummern dort ebenfalls, denn das ERP steht vor demselben Problem.

Zweitens einmalig übernehmen. Die Liste wird ins Vorsystem eingelesen und dem jeweiligen Lieferanten zugeordnet. Das ist eine einmalige Arbeit, danach wächst der Bestand mit jedem neuen Lieferanten um eine Zeile.

Drittens festhalten. Eine einmal zugeordnete Nummer bleibt am Lieferanten. Wird sie später geändert, laufen Vorjahresbuchungen und neue Buchungen auf verschiedene Konten, und das Problem ist zurück, nur eine Ebene tiefer.

Die Namensfalle

Der Abgleich zwischen Rechnung und Kreditorenstamm läuft über den Lieferantennamen, und der schwankt. „Muster Ltd.”, „Muster Limited” und „Muster Ltd” sind für einen Menschen offensichtlich derselbe Lieferant, für einen einfachen Textvergleich sind es drei.

Dazu kommen Marken. Auf dem Briefkopf steht der Shop, im Impressum die GmbH dahinter. Für die Buchhaltung zählt der Rechtsträger, denn er stellt die Rechnung.

Ein brauchbarer Abgleich blendet deshalb Rechtsformzusätze, Satzzeichen und Groß- und Kleinschreibung aus, bevor er vergleicht. Sonst entstehen die Doppelungen genau dort, wo man sie vermeiden wollte.

Wenn es noch keinen Kreditorenstamm gibt

Bei einer Neugründung ist die Lage einfacher. Dann darf das Vorsystem Nummern vergeben, aber der Nummernkreis wird vorher mit der Buchhaltung abgestimmt. Kanzleien haben dafür Gewohnheiten, und wer sie erfragt, spart sich die Umstellung, sobald die erste Auswertung läuft.

Wie Invoice Dock es macht

Die Kreditorennummern lassen sich als CSV aus der bestehenden Buchhaltung übernehmen und einzeln ändern. Jede Nummer trägt ihre Herkunft, also übernommen, von Hand gesetzt oder automatisch vergeben. Vor dem Export weist die Software darauf hin, wenn selbst vergebene Nummern im Stapel stecken, denn genau die sind der Kandidat für einen doppelten Kreditor.

Der Abgleich läuft über eine Namensnormalisierung, die Rechtsformzusätze ausblendet, damit „Ltd.” und „Limited” denselben Kreditor treffen.

Wie der Stapel aufgebaut ist, steht unter DATEV-Buchungsstapel. Die vollständige Funktionsliste gibt es unter Funktionen.