Gutschriften, Storni und abweichende USt-Beträge sauber ins RZL bringen

Solange ein Mandant nur normale Ausgangsrechnungen liefert, läuft der CSV-Import meist glatt. Der Ärger beginnt in dem Monat, in dem eine Gutschrift dabei ist. Plötzlich stimmt die Summe nicht, der USt-Betrag passt nicht zur Basis, und jemand in Ihrer Kanzlei sitzt da und sucht die Differenz von Hand aus der PDF-Zusammenfassung heraus.

Dieser Text beschreibt, warum Gutschriften und Storni beim CSV-Import typischerweise kippen, was das jeden Monat an Zeit kostet, und wie sich der Fall sauber lösen lässt, statt ihn still falsch zu buchen.

Warum Gutschriften und Storni beim Import kippen

Eine normale Ausgangsrechnung ist im CSV einfach: positiver Nettobetrag, ein USt-Satz, ein USt-Betrag, eine Summe. Diese Logik trägt, solange alle Zeilen in dieselbe Richtung zeigen.

Eine Gutschrift dreht das Vorzeichen um. Aus dem Quellsystem kommt der Betrag dann je nach Programm sehr unterschiedlich. Drei Varianten sehen wir immer wieder:

• Echtes Minus: -1.200,00 mit -240,00 USt. Sauber, aber nur, wenn das Zielsystem das Minus an der richtigen Stelle erwartet.
• Klammer-Schreibweise: (1.200,00) für einen Negativbetrag. Manche Programme exportieren so, und ein einfacher Import liest das als Text statt als Zahl.
• Positiver Betrag mit Belegart-Kennzeichen: Die Zeile sieht aus wie eine normale Rechnung, nur eine Spalte daneben steht „Gutschrift” oder „GS”. Das Vorzeichen steckt also nicht im Betrag, sondern im Kontext.

Dazu kommt das Dezimal- und Tausender-Problem. Liefert der Mandant 1,234.56 im englischen Format und die nächste Zeile 1.234,56 im deutschen, interpretiert ein naiver Import eine der beiden falsch. Bei einem positiven Wert fällt das oft erst im Abschluss auf. Bei einer Gutschrift fällt sofort die Monatssumme auseinander.

Wenn der USt-Betrag nicht zur Basis passt

Der zweite Klassiker ist eine USt-Zeile, die rechnerisch nicht aufgeht. Beispiele, die regelmäßig in den Dateien auftauchen:

• Auf einer Gutschrift über 1.200 Euro netto stehen 200 Euro USt statt 240. Der Mandant hat in seinem Programm den falschen Steuersatz gewählt, oder die Gutschrift bezieht sich teilweise auf einen ermäßigten Posten.
• Eine Zeile vermischt zwei Steuersätze, der Export weist aber nur einen Summen-USt-Betrag aus. Welcher Anteil auf 20 Prozent und welcher auf 10 Prozent entfällt, steht nirgends.
• Bei einer Storno-Zeile bleibt der USt-Betrag positiv, obwohl der Nettobetrag negativ ist. Damit hebt sich die Buchung nicht sauber gegen das Original auf.

Steuerlich ist die Regel in der Regel einfach: Eine Gutschrift korrigiert das ursprüngliche Geschäft, also kehren sich Entgelt und Umsatzsteuer typischerweise im gleichen Verhältnis um. Genau das prüft heute aber niemand automatisch. Wenn der USt-Betrag in der CSV nicht zur Basis passt, übernimmt ein einfacher Import den falschen Wert kommentarlos. Die Differenz taucht dann erst auf, wenn die UVA nicht stimmt.

Was das jeden Monat kostet

Der teure Teil ist nicht die einzelne Gutschrift. Es ist die Sucharbeit drumherum.

In der Praxis sieht der Ablauf so aus: Die Buchhalterin importiert die CSV, das RZL meldet eine Summendifferenz oder ein einzelner Saldo wirkt unplausibel. Jetzt öffnet sie die PDF-Zusammenfassung des Mandanten daneben und vergleicht Zeile für Zeile, bis sie die Gutschrift findet, die das Vorzeichen oder den USt-Betrag verdreht hat. Bei einem Mandanten mit vielen Ausgangsrechnungen pro Monat ist das schnell eine halbe bis ganze Stunde, jeden Monat aufs Neue, für genau denselben strukturellen Fehler.

Ein anonymisiertes, aber typisches Bild aus unseren Gesprächen: Eine Kanzlei verbucht monatlich die CSV-Ausgangsrechnungen eines Mandanten. Solange keine Gutschriften dabei sind, ist es eine Sache von Minuten. Sobald Storni oder Gutschriften auftauchen, stimmen Summe und USt-Betrag nicht mehr, und die Buchhalterin fischt die Differenz erst manuell aus der PDF-Zusammenfassung. Der Aufwand ist nicht riesig, aber er ist konstant und vermeidbar.

Vorher und nachher: ein konkretes Beispiel

So liefert ein Mandant die Zeilen typischerweise:

Beleg     ; Datum      ; Netto      ; USt-Satz ; USt      ; Brutto
AR-2041   ; 03.05.2026 ; 1.000,00   ; 20       ; 200,00   ; 1.200,00
AR-2042   ; 07.05.2026 ; 1,234.56   ; 20       ; 246,91   ; 1.481,47
GS-2043   ; 12.05.2026 ; (1.200,00) ; 20       ; 200,00   ; (1.440,00)

Drei Stolperstellen in drei Zeilen: gemischtes Zahlenformat (1.000,00 neben 1,234.56), eine Gutschrift in Klammer-Schreibweise, und ein USt-Betrag auf der Gutschrift, der mit 200 statt 240 nicht zur Basis passt.

So sollte es im RZL ankommen, mit korrektem Vorzeichen und sauber getrenntem Belegkreis:

Belegkreis; Datum      ; Netto      ; Steuercode ; USt      ; Brutto
AR        ; 03.05.2026 ; 1000,00    ; 20%        ; 200,00   ; 1200,00
AR        ; 07.05.2026 ; 1234,56    ; 20%        ; 246,91   ; 1481,47
AR        ; 12.05.2026 ; -1200,00   ; 20%        ; -240,00  ; -1440,00

Der Unterschied liegt nicht in der Optik, sondern darin, dass jede Zeile rechnerisch aufgeht und das RZL sie ohne Nacharbeit verbucht.

Wie wir den Fall lösen

Der Konverter setzt an genau diesen Stellen an, und zwar so, dass nichts still passiert:

• Betrags-Parsing für beide Welten. Das deutsche 1.234,56 und das englische 1,234.56 werden korrekt erkannt, ebenso Vorzeichen und Klammer-Schreibweise. Der Wert landet als Zahl in der Buchung, nicht als verrutschter Text.
• Storni und Negativbeträge werden markiert, nicht geraten. Erkennt der Konverter eine Zeile als mehrdeutig, etwa ein Negativbetrag oder eine Gutschrift, deren Vorzeichen nicht eindeutig im Betrag steckt, markiert er sie zur Bestätigung. Die Buchhalterin entscheidet, statt dass die Software blind bucht.
• Steuercode-Zuordnung mit Kontrolle. Der passende RZL-Steuercode wird über Mustererkennung und einen Datenbank-Abgleich vorgeschlagen, lässt sich aber jederzeit überschreiben. So wird nicht jede Gutschrift zum Rätsel, und Sonderfälle bleiben in Ihrer Hand.
• UID-Validierung dort, wo sie zählt. Bei grenzüberschreitenden Belegen wird die UID gegen das EU-Muster geprüft, damit eine fehlerhafte Nummer nicht erst in der UVA auffällt.

Der Punkt ist nicht, dass die Software klüger bucht als Ihre Buchhalterin. Der Punkt ist, dass sie die mehrdeutigen Zeilen sichtbar macht, statt sie kommentarlos durchzuwinken. Die Entscheidung bleibt bei Ihnen, nur das Suchen in der PDF entfällt.

Ehrlich eingeordnet

Den letzten Prozent Sicherheit kann keine Automatik garantieren, wenn der Mandant in seinem Quellsystem von vornherein den falschen USt-Betrag eingibt. Was der Konverter leisten kann, ist die Differenz früh sichtbar zu machen, statt sie in der Monatssumme verschwinden zu lassen. Die fachliche Entscheidung, ob eine Gutschrift korrekt ist, trifft weiterhin die Kanzlei. Das ist Absicht: Wir bauen ein Werkzeug für Buchhalter, keinen Ersatz für deren Urteil.

Wenn Sie es an Ihrem eigenen Fall sehen wollen

Am schnellsten überzeugt der Test mit Ihren echten Zeilen. Schicken Sie uns eine CSV von genau dem Mandanten, bei dem die Gutschriften jeden Monat Ärger machen, anonymisiert, wenn Sie möchten, nur die Struktur zählt. Wir bauen daraus einen Test-Converter und zeigen Ihnen, wie die Zeilen sauber im RZL-Format herauskommen. Kostenlos und unverbindlich.

Genau dieser Gutschriften-Fall in Ihrer Kanzlei? Schicken Sie uns die CSV, wir bauen den Test-Converter gratis: hallo@kanzlei-import.at

---

Dominik Pototschnig, Gründer kanzlei-import.at Kontakt: hallo@kanzlei-import.at Weiterführend: 3 typische BMD-Import-Probleme · BMD vs. RZL vs. DATEV: was wir abdecken