Reverse Charge in der Software-Abrechnung: Logik und Gutschriften

Ob eine Rechnung ohne Umsatzsteuer rausgehen darf, entscheidet in vielen SaaS-Stacks ein Feld reverse_charge=true am Kunden. Jemand im Vertrieb hat es irgendwann gesetzt. Das funktioniert, bis der Kunde eine neue USt-IdNr. meldet, ein Downgrade eine Gutschrift auslöst oder die Betriebsprüfung fragt, warum die Rechnung vom März keine Steuer ausweist. Dann zeigt sich, ob Ihr Billing-System die Entscheidung getroffen und gespeichert hat oder ob sie nur im PDF steht.

Dieser Beitrag behandelt die Logik dahinter: welche Eingaben die Entscheidung braucht, wie der Status einer USt-IdNr. verwaltet wird, was bei Änderungen im laufenden Abo passiert und wie Gutschriften die Entscheidung erben. Welche Angaben auf dem Dokument selbst stehen müssen, mit Musterrechnung und ZM-Abgleich, steht im Beitrag zum Erstellen einer Reverse-Charge-Rechnung.

Die Steuerentscheidung fällt vor der Rechnung, nicht beim Export

In vielen Setups sammelt der Checkout ein Land, das Billing-System erzeugt eine Rechnung, und die Buchhaltung korrigiert beim DATEV-Export, was steuerlich nicht stimmt. Diese Reihenfolge ist falsch herum. Eine Rechnung, die das System verlassen hat, korrigieren Sie nur noch mit einem weiteren Dokument, etwa einem Storno oder einer Gutschrift. Jedes davon muss wieder zur ZM und zur Voranmeldung passen.

Die Entscheidung gehört deshalb an die Stelle, an der die Rechnungsposition entsteht: nach dem Rating, vor dem Rendering. Bei nutzungsbasierter Abrechnung fällt sie bei jeder Rechnung neu, weil sich zwischen zwei Abrechnungsläufen der Status des Kunden ändern kann. Die Rechtsgrundlage, die Steuerschuldnerschaft des Leistungsempfängers bei grenzüberschreitenden B2B-Dienstleistungen, steht in der MwSt-Systemrichtlinie 2006/112/EG. Ihr System muss sie nur korrekt auf Daten abbilden.

Fünf Eingaben, eine Entscheidungstabelle

Für digitale Leistungen eines deutschen Anbieters braucht die Entscheidung fünf Eingaben: Unternehmerstatus des Kunden, Land der Ansässigkeit, Status der USt-IdNr., Art der Leistung und die Gesellschaft, die die Rechnung stellt. Daraus ergeben sich wenige Ergebnisse:

Die dritte Zeile ist die wichtigste. Ein Geschäftskunde ohne bestätigte Nummer ist weder automatisch Reverse Charge noch automatisch B2C. Wer hier einen Default wählt, egal welchen, erzeugt falsche Rechnungen, sobald VIES eine Nummer ablehnt. Die Schwelle aus § 3a Abs. 5 UStG gilt nur für Leistungen an Nichtunternehmer und ist ein Thema für die OSS-Automatisierung.

Der Status der USt-IdNr. ist ein eigener Zustand

Eine USt-IdNr. ist kein Stammdatenfeld, das einmal gepflegt wird. Sie hat einen Zustand mit Zeitpunkt. Ein brauchbares Modell kennt mindestens diese Zustände:

• unchecked: erfasst, noch nicht geprüft. Blockiert jede Rechnung ohne Steuer.
• valid: Prüfung erfolgreich, mit gespeichertem Ergebnis und Zeitstempel.
• invalid: Prüfung abgelehnt. Die nächste Rechnung geht in die Prüfung.
• unavailable: der Prüfdienst des Mitgliedstaats hat nicht geantwortet. Erneut versuchen, nicht raten.

Der Zustand unavailable wird oft vergessen. VIES fragt die Datenbanken der Mitgliedstaaten in Echtzeit ab, und einzelne Länder sind zeitweise nicht erreichbar. Ein System, das diesen Fall als invalid behandelt, stellt plötzlich deutsche Umsatzsteuer in Rechnung. Ein System, das ihn als valid behandelt, gibt eine ungeprüfte Nummer frei. Beides ist falsch. Halten Sie die Rechnung zurück und wiederholen Sie die Prüfung.

In Deutschland können Sie neben der einfachen auch eine qualifizierte Bestätigungsabfrage beim Bundeszentralamt für Steuern stellen, die auch Name und Anschrift abgleicht. Wann Sie erneut prüfen und wie die Abfrage automatisiert wird, steht im Beitrag zur VIES-Prüfung.

Die Entscheidung als Datensatz speichern

Wenn die Entscheidung nur als Ergebnis im PDF existiert, lässt sie sich später nicht mehr begründen. Speichern Sie deshalb pro Rechnungsposition einen unveränderlichen Datensatz mit Eingaben und Ergebnis:

tax_decision
  invoice_line_id    inv_2026_001842_l1
  decided_at         2026-11-03T06:00:12Z
  rule_version       eu-b2b-2026-01
  customer_country   FR
  customer_type      business
  vat_id             FR99999999999
  vat_check_id       chk_7f3a   (Ergebnis valid, 2026-10-28)
  supply_type        saas_subscription
  treatment          reverse_charge
  rate               0
  category_code      AE
  note_key           steuerschuldnerschaft_leistungsempfaenger

Drei Felder machen den Unterschied. vat_check_id verweist auf das gespeicherte Prüfergebnis, nicht auf den aktuellen Stand am Kunden. rule_version zeigt, welche Regel galt, auch wenn Sie die Regel später ändern. Und note_key holt den Hinweistext aus der Regel, damit das PDF-Template ihn nicht selbst entscheidet.

Ändert sich eine Eingabe, entsteht für neue Positionen ein neuer Datensatz. Bestehende Datensätze überschreiben Sie nie.

Wenn sich der Status mitten im Abo ändert

Ein Ablauf mit erfundenen Zahlen: Ein Kunde in Wien bucht am 1. Februar einen Plan zu 600 € netto im Monat, monatlich im Voraus. Bei der Anmeldung gibt er keine USt-IdNr. an. Ihr System behandelt ihn als Privatkunden und berechnet österreichische Steuer über OSS. Am 14. Februar trägt er eine USt-IdNr. nach, die Prüfung ergibt valid.

• Die Februar-Rechnung vom 1. Februar bleibt, wie sie ist. Ob sie storniert und als Reverse-Charge-Rechnung neu ausgestellt wird, klären Sie mit Ihrer Steuerberatung. Das System muss beide Wege können, ohne das Original zu verändern.
• Die März-Rechnung vom 1. März entsteht mit einem neuen Entscheidungsdatensatz: Reverse Charge, Verweis auf die Prüfung vom 14. Februar.
• Ein Upgrade am 20. März erzeugt eine anteilige Position. Sie verwendet den Status zum Zeitpunkt ihrer Erstellung, nicht den vom Monatsanfang.

Der umgekehrte Fall ist gefährlicher. Bei der Verlängerung am 1. Mai meldet VIES die Nummer als ungültig, etwa nach einer Umstrukturierung beim Kunden. Ein System mit Kundenflag rechnet weiter ohne Steuer. Ein System mit Zustandsmodell hält die Mai-Rechnung an, bis jemand die neue Nummer prüft oder die Steuer anders festlegt. Steht hinter der neuen Nummer eine andere Gesellschaft, legen Sie einen neuen Kundendatensatz an. Die alten Rechnungen bleiben der alten Nummer zugeordnet.

Gutschriften erben die Entscheidung der Originalrechnung

Im Mai bekommt derselbe Kunde für einen Ausfall im März eine Gutschrift über 150 €. Gemeint ist hier die kaufmännische Gutschrift, also eine Rechnungskorrektur, nicht die umsatzsteuerliche Gutschrift nach § 14 Abs. 2 UStG. Ein typischer Fehler: Die Gutschrift wird wie eine neue Rechnung behandelt und läuft durch die aktuelle Steuerentscheidung. Gilt im Mai ein anderer Status als im März, steht auf der Gutschrift eine andere Steuerbehandlung als auf der Rechnung, die sie korrigiert. Die Summen in ZM und Voranmeldung passen dann nicht mehr zusammen.

Die Regel ist einfach: Eine Gutschrift bezieht sich auf eine konkrete Originalposition und kopiert deren Entscheidungsdatensatz, einschließlich USt-IdNr., Steuerkategorie und Hinweistext. Das gilt genauso für anteilige Gutschriften bei Downgrades, für Stornos und für Erstattungen. Eine Gutschrift ohne Bezug auf eine Originalposition sollte Ihr System gar nicht erst zulassen.

Sechs Testfälle vor dem Go-live

Bevor Reverse Charge produktiv läuft, sollten diese Fälle als automatisierte Tests im Billing-System bestehen. Jeder prüft ein konkretes Ergebnis:

1. EU-Geschäftskunde mit gültiger Nummer: Reverse Charge, Kategorie AE, Hinweistext, kein Steuerbetrag.
2. Dieselbe Nummer mit Prüfergebnis invalid: Rechnung geht in die Prüfung, nichts wird versendet.
3. Prüfdienst nicht erreichbar: Status unavailable, Rechnung wartet, Wiederholung ist geplant.
4. USt-IdNr. wird im laufenden Monat nachgetragen: nur neue Positionen ändern sich, das Original bleibt unverändert.
5. Gutschrift nach Statuswechsel: übernimmt die Entscheidung der Originalposition, nicht den aktuellen Status.
6. Regeländerung: alte Rechnungen zeigen weiter die alte rule_version.

Kontier speichert die Steuerentscheidung je Rechnungsposition mit Prüfnachweis und Regelversion und leitet Gutschriften aus der Originalposition ab. Das ist Teil des europäischen Billing-Workflows.