EU-Steuerfehler im SaaS-Billing: acht Fälle und ihre Korrektur

Steuerfehler im Billing fallen selten dort auf, wo sie entstehen. Ein fehlender Prüfstatus beim Kunden zeigt sich erst, wenn die Zusammenfassende Meldung (ZM) nicht zu den Rechnungen passt. Eine überschriebene Adresse zeigt sich erst, wenn eine Gutschrift im falschen Land landet. Dieser Beitrag sammelt acht Fehler, die in SaaS-Abrechnungen mit EU-Kunden immer wieder auftreten. Zu jedem stehen das Symptom, die Ursache, die Korrektur und eine Abfrage, die ihn künftig vor der Meldung findet.

Die Beispiele gehen von einem Anbieter mit Sitz in Deutschland aus. In welcher Reihenfolge die Steuerentscheidungen im System fallen sollten, beschreibt der Beitrag zur EU-Steuerlogik im SaaS-Billing. Hier geht es um das, was schiefgeht, wenn diese Reihenfolge fehlt.

Kundeneinordnung: Fehler vor der ersten Rechnung

1. Eingegebene USt-IdNr. schaltet direkt Reverse Charge

Symptom: Rechnungen ohne Umsatzsteuer an Kunden, deren Nummer nie bestätigt wurde, oder an Nummern mit Tippfehler. In der ZM tauchen Nummern auf, die das Prüfverfahren ablehnt.

Ursache: Das Checkout-Feld für die USt-IdNr. ist gleichzeitig der Schalter für die Steuerbehandlung. Was eingegeben wird, gilt als geprüft.

Korrektur: Eine Nummer bekommt einen Status (pending, valid, invalid, unavailable), und nur valid mit gespeichertem Prüfnachweis führt in den Reverse Charge. Für alles andere gibt es eine ausdrückliche Regel. Wie die Prüfung abläuft, steht im Beitrag zur VIES-Prüfung. Bereits ausgestellte Rechnungen korrigieren Sie über Gutschrift und neue Rechnung, nachdem Finance den Fall bewertet hat.

Abfrage: Rechnungszeilen mit Reverse Charge, deren Kunde keinen Prüfnachweis mit Datum vor der Rechnung hat.

2. Reverse Charge ohne den Pflichthinweis

Symptom: Die Rechnung weist keine Steuer aus, nennt aber auch den Grund nicht. Oder sie trägt den Hinweis und weist trotzdem Steuer aus, weil Vorlage und Berechnung aus verschiedenen Quellen lesen.

Ursache: Der Hinweistext ist Teil des PDF-Templates und hängt an einem anderen Feld als die Steuerberechnung.

Korrektur: Bei Reverse Charge verlangt § 14a UStG die Angabe „Steuerschuldnerschaft des Leistungsempfängers“. Hinweis, Steuerbetrag und Buchungskonto müssen aus demselben gespeicherten Steuerergebnis der Rechnungszeile kommen.

Abfrage: Rechnungen, bei denen der Steuerbetrag null ist und kein Hinweis gesetzt ist, und umgekehrt.

Leistungsort: Fehler bei Verbrauchern

3. Das Land kommt aus einem einzigen Feld

Symptom: Ein Verbraucher in Österreich wird mit deutscher Steuer abgerechnet, weil seine Kreditkarte in Deutschland ausgegeben wurde. Oder ein Verbraucher in Deutschland mit österreichischer Steuer, weil er sich über ein Wiener Netz eingeloggt hat.

Ursache: Der Code nimmt das erste verfügbare Länderfeld, meist das des Payment-Providers.

Korrektur: Die Durchführungsverordnung (EU) 282/2011 enthält Vermutungsregeln für den Ort des Leistungsempfängers. Speichern Sie die verfügbaren Indizien einzeln und welches davon entschieden hat. Widersprechen sie sich, entsteht ein Prüffall.

Abfrage: Kunden, bei denen Rechnungsland, Zahlungsmittelland und IP-Land nicht übereinstimmen, ohne dokumentierte Entscheidung.

4. Die Adresse wird überschrieben

Symptom: Eine Gutschrift für eine Leistung aus dem Frühjahr trägt das Land, in das der Kunde im Herbst gezogen ist. Die Korrektur landet in einem Land, in dem nie ein Umsatz stattfand.

Ursache: Das Kundenprofil kennt nur den aktuellen Stand, und Belege lesen ihn zur Laufzeit.

Korrektur: Steuerlich relevante Kundendaten werden mit Gültigkeitsbeginn versioniert. Jede Rechnungszeile speichert das Steuerergebnis, das bei ihrer Finalisierung galt, und Gutschriften übernehmen es von der Ursprungszeile. Wie das bei Quartalen funktioniert, die bereits in der OSS-Erklärung stehen, zeigt der Beitrag zum OSS-Quartalsabschluss.

Abfrage: Gutschriften ohne Verweis auf eine Ursprungszeile.

Beträge: Rundung und Bruttopreise

5. Jede Komponente rundet anders

Ein Beispiel: Eine Rechnung hat drei Positionen zu je 0,99 Euro netto, Steuersatz 19 %. Rundet das System pro Zeile, ergeben sich 3 × 0,19 Euro = 0,57 Euro Steuer. Rundet es auf die Summe, ergibt sich 2,97 × 0,19 = 0,5643, also 0,56 Euro. Wenn der Checkout pro Zeile rundet, die Rechnung auf die Summe und der Buchungsexport noch einmal anders, entstehen Cent-Differenzen, die sich über Tausende Rechnungen zu einem Betrag summieren, den niemand erklären kann.

Korrektur: Eine Rundungsregel, an einer Stelle berechnet, von PDF, E-Rechnung und Buchungsexport nur gelesen. Strukturierte E-Rechnungen prüfen Summen und Steuerbeträge streng; wie Sie das vor dem Versand testen, steht im Beitrag zur XRechnung-Validierung.

Abfrage: Rechnungen, bei denen die gespeicherte Steuersumme von der Neuberechnung nach der festgelegten Regel abweicht.

6. Bruttopreise ohne Entscheidung, wer den Satzunterschied trägt

Symptom: Der Nettoerlös pro Abo schwankt je nach Land, und niemand hat es so entschieden.

Ursache: Für Verbraucher wird ein einheitlicher Bruttopreis angezeigt, etwa 11,90 Euro. Bei 19 % sind das 10,00 Euro netto, in einem Land mit 25 % nur noch 9,52 Euro. Das ist zulässig, muss aber gewollt sein, und die Preislogik muss den Nettobetrag aus dem Bruttopreis zurückrechnen, statt Steuer auf einen Nettopreis aufzuschlagen.

Korrektur: Pro Preis speichern, ob er netto oder brutto gilt, und diese Angabe vom Angebot bis zur Rechnung durchreichen.

Belege und Meldungen: Fehler nach dem Versand

7. Rechnungen werden nach dem Versand bearbeitet

Symptom: Das PDF beim Kunden unterscheidet sich vom Beleg im System, oder der gemeldete Betrag passt zu keiner aktuellen Rechnung mehr.

Ursache: Support oder Finance korrigiert einen Fehler direkt in der versendeten Rechnung.

Korrektur: Eine versendete Rechnung bleibt, wie sie ist. Rechnungen sind in Deutschland acht Jahre aufzubewahren (§ 14b UStG). Korrigiert wird über Storno oder Gutschrift und gegebenenfalls eine neue Rechnung, jeweils mit Verweis auf das Original. Eine fehlgeschlagene Lastschrift oder ein Chargeback ist dabei ein Zahlungsereignis: Es storniert keine Rechnung. Wie ein endgültiger Zahlungsausfall steuerlich zu behandeln ist, entscheidet Finance gesondert.

Abfrage: Rechnungen mit Änderungszeitpunkt nach dem Versandzeitpunkt.

8. ZM und Reverse-Charge-Rechnungen passen nicht zusammen

Symptom: Die Summe in der ZM weicht von der Summe der Reverse-Charge-Rechnungen ab.

Ursache: Die ZM wird aus der Buchhaltung erstellt, die Reverse-Charge-Kennzeichnung steht aber nur im Billing, oder Gutschriften werden in einer der beiden Quellen nicht berücksichtigt.

Korrektur: Beide Zahlen kommen aus denselben Rechnungszeilen. Je USt-IdNr. des Kunden und Meldezeitraum muss die Summe der Reverse-Charge-Zeilen, Gutschriften eingeschlossen, der gemeldeten Zeile entsprechen.

Die Prüfliste vor jeder Meldung

Beginnen Sie mit den Fehlern 1 und 4. Sie erzeugen die teuersten Korrekturen, weil sie viele Rechnungen auf einmal betreffen. Kontier speichert das Steuerergebnis pro Rechnungszeile mit Prüfnachweis und Verweis auf die Ursprungszeile in seiner Billing-Infrastruktur für Europa, sodass diese Abfragen direkt auf den Belegdaten laufen.