EU-Steuerlogik im SaaS-Billing: Reihenfolge der Entscheidungen

Die meisten Steuerfehler im SaaS-Billing entstehen nicht durch einen falschen Satz in der Tabelle. Sie entstehen, weil die Fragen in der falschen Reihenfolge gestellt werden. Wer zuerst nach dem Land fragt und dann den Satz nachschlägt, berechnet einem französischen Unternehmen mit gültiger USt-IdNr. französische Umsatzsteuer. Wer zuerst die Zahlungsart auswertet, lässt den Payment-Provider über den Leistungsort entscheiden.

Dieser Beitrag beschreibt die Architektur: welche Entscheidungen in welcher Reihenfolge fallen, wie das Ergebnis gespeichert wird und wie Sie eine geänderte Regel testen, bevor sie live geht. Die Beispiele gehen von einem Anbieter mit Sitz in Deutschland aus, der elektronische Leistungen verkauft.

Fünf Fragen, immer in derselben Reihenfolge

1. Wer ist der Kunde? Unternehmer oder Verbraucher, und auf welchem Nachweis beruht diese Einordnung.
2. Wo ist die Leistung steuerbar? Bei Unternehmern grundsätzlich am Sitz des Kunden. Bei Verbrauchern liegt der Leistungsort für elektronische Leistungen an deren Wohnsitz, sofern die EU-weite Schwelle von 10.000 Euro überschritten ist oder Sie auf sie verzichtet haben (§ 3a Abs. 5 UStG).
3. Wer schuldet die Steuer? Bei Leistungen an Unternehmer in anderen EU-Staaten der Kunde (Reverse Charge), sonst der Anbieter.
4. Welcher Satz gilt? Erst jetzt, und nur wenn der Anbieter die Steuer schuldet: Satz des Leistungsorts für die Steuerkategorie des Produkts, gültig am Leistungsdatum.
5. Wie wird gemeldet und was steht auf der Rechnung? Umsatzsteuer-Voranmeldung, OSS-Erklärung oder Zusammenfassende Meldung, dazu der passende Rechnungshinweis.

Jede Frage braucht die Antwort der vorherigen. Der Steuersatz kommt an vierter Stelle, weil er bei einem Reverse-Charge-Kunden gar nicht gebraucht wird. Die Meldung kommt zuletzt, weil sie sich vollständig aus den ersten vier Antworten ergibt. Wenn Ihr Code an irgendeiner Stelle den Meldeweg aus etwas anderem ableitet als aus diesen Antworten, entsteht dort die nächste Differenz.

Die Entscheidungstabelle für einen deutschen Anbieter

Aus den fünf Fragen ergibt sich eine kleine Tabelle. Schreiben Sie sie für Ihr Geschäft auf, lassen Sie sie von Ihrer Steuerberatung abnehmen und codieren Sie erst dann.

Die dritte Zeile ist die, die in den meisten Systemen fehlt. Ein Kunde, der angibt, Unternehmer zu sein, dessen USt-IdNr. aber noch nicht bestätigt ist, darf nicht still in die zweite Zeile rutschen. Welche Behandlung Sie stattdessen wählen, ist eine Abwägung zwischen Conversion und Risiko. Wichtig ist, dass es eine ausdrückliche Zeile gibt. Wie die Prüfung selbst läuft, beschreibt der Beitrag zur VIES-Prüfung.

Die zweite Zeile verlangt auf der Rechnung die Angabe „Steuerschuldnerschaft des Leistungsempfängers“ (§ 14a UStG) und eine Meldung in der Zusammenfassenden Meldung. Die Details stehen im Beitrag zur Reverse-Charge-Rechnung.

Das Ergebnis als Entscheidungsobjekt speichern

Die fünf Antworten gehören in ein eigenes Objekt, das pro Rechnungszeile gespeichert und von der Rechnung nur referenziert wird. Eine Skizze:

{
  "tax_decision_id": "td_7f3a",
  "inputs": {
    "customer_status": "BUSINESS_VERIFIED",
    "vat_id_check_ref": "chk_1029",
    "customer_country": "FR",
    "product_tax_category": "ELECTRONIC_SERVICE",
    "supply_date": "2026-10-01"
  },
  "outputs": {
    "place_of_supply": "FR",
    "tax_liable": "CUSTOMER",
    "scheme": "REVERSE_CHARGE",
    "rate": null,
    "invoice_note": "REVERSE_CHARGE_NOTE",
    "report": "ZM"
  },
  "rule_version": "tax-rules@41",
  "decided_at": "2026-10-01T06:12:44Z"
}

Drei Eigenschaften machen das Objekt nützlich. Es speichert Eingaben und Ergebnisse, sodass sich die Entscheidung erklären lässt, ohne die Regeln erneut auszuführen. Es trägt die Regelversion, sodass eine spätere Änderung alte Rechnungen nicht umdeutet. Und es ist die einzige Quelle für alles Nachgelagerte: Rechnungs-PDF, E-Rechnung, Buchungsexport und Meldung lesen dieselben Felder. Wenn das PDF einen Reverse-Charge-Hinweis zeigt und der Buchungsexport trotzdem ein Konto für steuerpflichtige Umsätze bebucht, lesen zwei Komponenten aus verschiedenen Quellen.

Die Steuerkategorie des Produkts gehört in den versionierten Produktkatalog, nicht in den Code des Checkouts. Wie Sie Produkte und Preise so versionieren, dass alte Rechnungen ihre Kategorie behalten, beschreibt der Beitrag zur Produktkatalog-Versionierung.

Wann neu entschieden wird und wann nicht

Eine Steuerentscheidung entsteht, wenn eine Rechnungszeile finalisiert wird. Die Vorschau im Checkout darf dieselbe Logik aufrufen, ist aber nur eine Vorschau: Beim Finalisieren wird mit den dann gültigen Daten neu entschieden.

Neue Entscheidungen lösen aus: eine erfolgreiche oder gescheiterte Prüfung der USt-IdNr., eine Adressänderung, eine neue Version der Satztabelle, ein neues Produkt. Jede dieser Änderungen bekommt ein Wirksamkeitsdatum und wirkt nur auf Zeilen, die danach finalisiert werden.

Keine neue Entscheidung bekommen finalisierte Zeilen. Eine Gutschrift übernimmt die Entscheidung der Zeile, die sie korrigiert, statt eine eigene zu treffen. Eine anteilige Abrechnung bei einem Upgrade zur Monatsmitte erzeugt zwei Zeilen mit je eigener Entscheidung, falls sich der Kundenstatus dazwischen geändert hat. Muss eine alte Rechnung tatsächlich steuerlich anders behandelt werden, geschieht das über einen neuen Beleg mit Freigabe, nie über einen stillen Neulauf.

Eine Regeländerung testen, bevor sie live geht

Weil die Regeln versioniert sind, lassen sie sich wie Code testen. Zwei Tests reichen für den Anfang.

Erstens ein fester Satz von Referenzfällen mit erwartetem Ergebnis, einer pro Zeile der Entscheidungstabelle und einige Grenzfälle dazu: Verbraucher, dessen Rechnung die Schwelle gerade überschreitet; Unternehmer, dessen Prüfung wegen eines Ausfalls nicht beantwortet wurde; Adressänderung mitten im Abrechnungszeitraum; Gutschrift auf eine Zeile aus dem Vorquartal. Finance schreibt die erwarteten Ergebnisse, Engineering macht sie zu automatischen Tests.

Zweitens ein Wiederholungslauf: Die neue Regelversion wird gegen die gespeicherten Eingaben aller Entscheidungen des letzten Quartals ausgeführt und das Ergebnis mit den gespeicherten Ausgaben verglichen. Jede Abweichung ist entweder beabsichtigt, weil sich die Regel ab einem Datum ändern soll, oder ein Fehler. Unbeabsichtigte Abweichungen müssen null sein, bevor die Version live geht.

Womit Sie anfangen

Prüfen Sie zuerst an zehn echten Rechnungszeilen aus verschiedenen Ländern und Kundentypen, ob Ihr System heute diese Fragen beantworten kann: Welche der fünf Entscheidungen wurde getroffen, auf welcher Eingabe, mit welcher Regelversion? Wenn die Antwort für eine Zeile nur durch Nachrechnen entsteht, fehlt das gespeicherte Entscheidungsobjekt. Bauen Sie es vor jeder weiteren Steuerfunktion.

Zweitens: Suchen Sie im Code nach Stellen, an denen ein Steuersatz ohne vorherige Frage nach Kundenstatus und Steuerschuldner gelesen wird. Jede davon ist ein Kandidat für einen Reverse-Charge-Fehler.

Kontier speichert die Steuerentscheidung mit Eingaben und Regelversion pro Rechnungszeile und stellt sie über die Billing-API bereit.