USt-Voranmeldung mit KI: Wo Reverse-Charge und Dreiecksgeschäfte LLM-Pipelines zerlegen

Warum die UStVA scheinbar ein perfekter LLM-Use-Case ist

Die Umsatzsteuer-Voranmeldung sieht aus wie der Lehrbuch-Fall für Automatisierung. Repetitive Struktur, monatlich oder quartalsweise wiederkehrend, amtlich standardisiertes Datenformat (ELSTER-XML in Deutschland, FinanzOnline in Österreich), klar definierte Kennzahlen, deterministische Fristen. Genau die Art Aufgabe, bei der ein KI-Agent auf den ersten Blick Stunden pro Mandant einspart.

In der Praxis stimmt das auch. Belegerkennung per OCR, Extraktion von Nettobetrag, Steuersatz, Lieferantendaten und UID-Nummer, anschließende Übergabe an ein LLM, das die Buchungslogik vorschlägt: Das funktioniert bei Standardrechnungen aus dem Inland mit 20 Prozent USt (AT) oder 19 Prozent USt (DE) zuverlässig. Trefferquoten von 90 Prozent und mehr sind in diesem Segment realistisch.

Das Problem ist nur: Die 10 Prozent, die nicht funktionieren, sind genau die Fälle mit dem größten Haftungsrisiko. Und sie liegen nicht im Formular. Sie liegen in der Klassifikation der Umsätze davor.

Wer als Wirtschaftsprüfer oder Steuerberater eine LLM-Pipeline für die UStVA aufsetzt, ohne diese Edge-Cases architektonisch zu adressieren, baut sich ein schönes Effizienz-Tool und ein latentes Haftungsproblem in einem Aufwasch.

Edge-Case 1: Reverse-Charge nach §13b UStG (DE) bzw. §19 UStG (AT)

Die Steuerschuldnerschaft des Leistungsempfängers ist der Klassiker. Ein deutsches Beratungsunternehmen kauft eine SaaS-Lizenz bei einem irischen Anbieter. Rechnungsbetrag netto, Hinweis „VAT reverse-charge, Article 196 VAT Directive” irgendwo im Fußbereich der Rechnung. Der Leistungsort wechselt nach §3a Abs. 2 UStG zum Empfänger, die deutsche Steuerschuld geht auf den Leistungsempfänger über.

Was LLMs hier konsistent falsch machen: Sie lesen den Rechnungstext oberflächlich. Wenn der Reverse-Charge-Hinweis fehlt oder mehrdeutig formuliert ist (was bei kleineren EU-Anbietern regelmäßig vorkommt), klassifiziert das Modell den Vorgang als normalen Vorsteuerabzug. Oder umgekehrt: Bei einer Inlandsrechnung mit unglücklicher Formulierung sieht das Modell einen Reverse-Charge, der gar nicht existiert.

Die Folge im Formular ist nicht harmlos. Im deutschen UStVA-Vordruck landet ein §13b-Umsatz in den Kennzahlen 84/85 oder 67 (je nach Leistungsart). Trägt das Modell den Betrag stattdessen in Kennzahl 81 (Lieferungen zu 19 Prozent) ein, ist die Voranmeldung formal falsch. Der Vorsteuerüberhang wird unzutreffend ausgewiesen, und bei einer Umsatzsteuer-Nachschau fällt das auf. Spätestens.

Noch unangenehmer: Die Korrektur per berichtigter Voranmeldung ist machbar, aber sie hinterlässt Spuren. Und wenn der Mandant in mehreren Perioden hintereinander betroffen ist, weil die Pipeline systematisch denselben Fehler macht, ist die Diskussion mit dem Finanzamt aufwendig.

Edge-Case 2: Innergemeinschaftliches Dreiecksgeschäft

Das ig. Dreiecksgeschäft nach Art. 141 MwStSystRL ist der Fall, bei dem ich LLMs noch keine produktive Pipeline anvertrauen würde. Drei Parteien, zwei Mitgliedstaaten, Vereinfachungsregel für das mittlere Unternehmen. Die Vereinfachung greift nur, wenn alle Bedingungen gleichzeitig erfüllt sind: korrekte UID des Erwerbers, ausdrücklicher Hinweis auf der Rechnung („Innergemeinschaftliches Dreiecksgeschäft, Steuerschuldnerschaft des Empfängers”), korrekte Eintragung in die Zusammenfassende Meldung.

Was LLMs hier liefern: plausibel klingende Klassifikationen, die fachlich nicht halten. Ein typisches Muster: Die Rechnung enthält eine UID-Nummer und einen EU-Empfänger, das Modell ordnet den Vorgang als reguläre innergemeinschaftliche Lieferung ein. Die Vereinfachungsregel des Dreiecksgeschäfts wird übersehen, weil das Modell die zweite Lieferbeziehung in der Kette nicht erkennt.

Konsequenz: Die Zusammenfassende Meldung wird falsch befüllt. Der Hinweis auf das Dreiecksgeschäft fehlt, das mittlere Unternehmen verliert die Vereinfachung und müsste sich theoretisch im Bestimmungsland registrieren. Das ist der Fall, bei dem aus einem automatisierten Workflow am Ende eine umsatzsteuerliche Registrierungspflicht im Ausland wird, von der der Mandant nichts ahnt.

Ich halte diesen Edge-Case für den einen Fall, bei dem die Trefferquote des LLM ehrlich gemessen werden muss, bevor irgendetwas produktiv geht. In den Tests, die ich aus der Praxis kenne, liegt die Quote bei Standard-LLMs ohne spezifisches Tuning bei deutlich unter 70 Prozent.

Edge-Case 3: Bauleistungen und Gebäudereinigung

Der dritte Klassiker. §13b Abs. 2 Nr. 4 UStG in Deutschland, §19 Abs. 1a UStG in Österreich. Die Steuerschuld geht auf den Leistungsempfänger über, wenn dieser selbst Bauleistungen erbringt. Klingt einfach. Ist es nicht.

Das LLM muss aus dem Rechnungstext zwei Dinge ableiten: Erstens, ob es sich um eine Bauleistung im Sinne des Gesetzes handelt. Zweitens, ob der Leistungsempfänger nachhaltig Bauleistungen erbringt. Beides ist in der Rechnung selbst meist nicht eindeutig erkennbar.

Die typische Fehlklassifikation: Das Modell sieht „Renovierungsarbeiten Bürogebäude” und ordnet pauschal §13b zu. Tatsächlich kann ein Großteil der Leistung Planung, Projektsteuerung oder Reinigung gewesen sein, also keine Bauleistung im engeren Sinne. Oder umgekehrt: Eine als „Instandhaltung” deklarierte Position ist tatsächlich eine Bauleistung, das Modell übersieht den Steuerschuldnerschafts-Wechsel.

In Österreich kommt die Subunternehmerkette dazu. Bei Bauleistungen mit Haftungsübergang nach §82a EStG müssen zusätzlich Auftraggeberhaftung und Sozialversicherungs-Aspekte mitgedacht werden. Das ist nichts, was ein LLM aus dem Rechnungstext ableiten kann. Hier braucht es Mandantenstammdaten, die das Modell als strukturierten Input bekommen muss.

Besonders heikel sind Gemischtrechnungen: 50 Prozent Bauleistung, 50 Prozent Planung in einer Rechnungsposition. Die korrekte Behandlung ist die Aufteilung, das LLM neigt zur einheitlichen Klassifikation. In dem Fall liegt der Fehler nicht in der Kennzahl, sondern in der Bemessungsgrundlage.

Warum LLMs in diesen Fällen strukturell halluzinieren

Das ist kein Tuning-Problem. Es ist ein Architektur-Problem.

Erstens spiegeln die Trainingsdaten überwiegend Standardfälle. Umsatzsteuerliche Sonderfälle sind in den öffentlich verfügbaren Korpora unterrepräsentiert. UStR, BMF-Schreiben und UStH-Kommentierung sind teilweise lizenzpflichtig und fehlen in den Pretraining-Daten der gängigen Modelle. Das Modell hat schlicht weniger Material gesehen, an dem es Sonderfälle gelernt hätte.

Zweitens betreiben LLMs kein Regelwerk-Reasoning. Sie interpolieren plausible Antworten. Das UStG funktioniert aber nicht plausibel, sondern normativ. Eine Bedingung ist erfüllt oder nicht. Die Vereinfachungsregel beim Dreiecksgeschäft greift oder sie greift nicht. Probabilistische Modelle sind für diese Art von Boolean-Logik die falsche Werkzeugklasse.

Drittens das Kontextfenster-Problem bei Buchungsketten. Wenn das Modell in einem längeren Prompt erst die Mandantenstammdaten, dann mehrere Rechnungen, dann den Buchungskontext bekommt, gehen frühe Prämissen verloren. Die Information, dass der Mandant kein nachhaltiger Bauleistungserbringer ist, steht im ersten Drittel des Prompts und beeinflusst die Klassifikation der letzten Rechnung nicht mehr zuverlässig.

Viertens, und das ist der gefährlichste Punkt: LLMs haben keine kalibrierte Selbsteinschätzung. Der Konfidenz-Score, den manche APIs liefern, korreliert mit der sprachlichen Plausibilität der Antwort, nicht mit der juristischen Korrektheit. Eine selbstbewusst falsche §13b-Klassifikation sieht für die Pipeline genauso aus wie eine korrekte.

Welche Vorprüf-Layer der Kanzlei-Stack 2026 braucht

Die pragmatische Antwort heißt nicht „kein LLM”. Sie heißt: Das LLM darf nicht alleine entscheiden. Konkret braucht der Stack vier Schichten.

Layer 1: Regelbasierter Klassifikator vor dem LLM. Bevor irgendein LLM eine Rechnung sieht, läuft ein deterministischer Filter. UID-Nummer valide (per VIES-Abfrage)? Ländercode des Lieferanten? Leistungsart aus dem Kontenrahmen ableitbar? Schwellenwerte für innergemeinschaftliche Erwerbe? Das sind Regeln, keine Wahrscheinlichkeiten. Sie gehören in Python-Code, nicht in einen Prompt.

Layer 2: Sonderfallfilter mit Review-Queue. Jede Transaktion mit Risikomerkmalen (Drittland-Bezug, Bauleistung, ig. Lieferung in der EU, Reverse-Charge-Verdacht, Differenzbesteuerung) wird geflaggt und in eine manuelle Review-Queue geschoben. Das LLM darf hier maximal einen Klassifikationsvorschlag mit Begründung liefern, die finale Entscheidung trifft der Berufsträger. Diese Queue sollte pro Mandant nicht mehr als 5 bis 15 Prozent des Belegvolumens umfassen, sonst stimmt die Vorfilterung nicht.

Layer 3: Output-Validator gegen die Vorperiode. Bevor das XML an ELSTER oder FinanzOnline geht, läuft ein Plausibilitätscheck. Sind die Kennzahlen in der Größenordnung der Vorperioden? Stimmt das Verhältnis von Vorsteuer zu Umsatzsteuer mit dem historischen Profil des Mandanten überein? Tauchen plötzlich Kennzahlen auf, die in den letzten 12 Monaten nie befüllt waren? Solche Anomalien sind oft das einzige Signal, dass die Klassifikation davor schiefgegangen ist.

Layer 4: Human-in-the-Loop mit Audit-Trail. Für alle geflaggten Fälle braucht es eine dokumentierte Freigabe durch den Berufsträger, inklusive Zeitstempel und Entscheidungsbegründung. Das ist nicht Bürokratie, das ist Haftungsschutz. Wenn das Finanzamt drei Jahre später nachfragt, warum eine bestimmte Klassifikation so getroffen wurde, ist der Audit-Trail die Verteidigungslinie. Eine Pipeline ohne diese Dokumentation ist im Beschwerdefall nicht verteidigbar.

Die Grundregel hinter den vier Layern: LLM für Extraktion und Drafting. Niemals für die finale USt-Klassifikation bei Sonderfällen.

Implementierungs-Roadmap für die Kanzlei

Wer das ernst umsetzen will, sollte in dieser Reihenfolge vorgehen.

Schritt 1: Edge-Case-Inventur der Mandate. Welcher Anteil der Mandate hat innergemeinschaftliche Geschäfte? Wie viele Bauunternehmer, Handwerker mit Reverse-Charge-Bezug, Onlinehändler mit OSS-Verfahren? Ohne diese Inventur weiß die Kanzlei nicht, wie groß das Edge-Case-Volumen überhaupt ist. Aus meiner Sicht ist das der Schritt, der am häufigsten übersprungen wird. Die typische Annahme „bei uns sind das Einzelfälle” hält der Auswertung selten stand.

Schritt 2: Shadow-Mode-Pilot. Die LLM-Pipeline läuft drei Monate parallel zur manuellen Bearbeitung. Output wird verglichen, Fehler werden klassifiziert. Welche Edge-Cases produzieren systematisch Fehler, welche nicht? Diese Messung ist die einzige belastbare Grundlage für die spätere Risikoklassenbildung. Ohne Shadow-Mode keine produktive Pipeline.

Schritt 3: Risikoklassen definieren. A: Vollautomatische Verarbeitung (Standardinlandsrechnungen, klar klassifizierbar). B: LLM-Vorschlag mit Stichproben-Review. C: Pflicht-Review durch Berufsträger. Die Schwellenwerte zwischen den Klassen sind kanzleispezifisch und hängen von der Mandantenstruktur ab.

Schritt 4: RAG mit fachlicher Wissensbasis. Das LLM bekommt Zugriff auf UStR, BMF-Schreiben, UStH-Kommentierung über einen Retrieval-Layer. Das verbessert die Qualität bei Sonderfällen messbar, ersetzt aber den Human-in-the-Loop nicht. Wichtig: Die Wissensbasis muss versioniert sein, sonst gibt es Probleme bei Gesetzesänderungen.

Schritt 5: Laufendes Monitoring. Jahressteuergesetze, BMF-Schreiben, EuGH-Entscheidungen ändern die Klassifikationslogik. Die Pipeline braucht einen definierten Prozess, wie solche Änderungen in die Regeln und Prompts einfließen. Sonst hat die Kanzlei in zwei Jahren eine Pipeline, die auf veraltetem Recht arbeitet.

Was das für die Architekturfrage bedeutet

Die eigentliche Diskussion in der Kanzlei ist nicht „KI ja oder nein”. Sie ist: Welche Entscheidungsebene darf die KI alleine treffen?

Für die Extraktion strukturierter Daten aus Rechnungen: ja, alleine. Für die Erstklassifikation von Standardvorgängen: ja, mit Stichproben-Kontrolle. Für die Klassifikation bei Reverse-Charge, Dreiecksgeschäften oder Bauleistungen: nein, nie alleine. Diese Trennlinie sauber zu ziehen, ist der eigentliche Architekturentwurf, nicht die Modellauswahl.

Die Effizienzgewinne sind real. Bei einem typischen mittelständischen Kanzleimandanten mit 200 bis 800 Belegen pro Monat sind 60 bis 80 Prozent Zeitersparnis bei der UStVA-Vorbereitung realistisch, wenn die Pipeline sauber gebaut ist. Aber genau diese 20 bis 40 Prozent, die übrigbleiben, sind die haftungskritischen Fälle. Das ist keine Schwäche der Automatisierung, sondern ihr Wesensmerkmal.

Wer als Wirtschaftsprüfer oder Steuerberater eine LLM-Pipeline für die UStVA aufsetzt und die vier Layer nicht hat, automatisiert nicht die Arbeit. Er automatisiert das Risiko.