Incoterms, Multi-Country-Sourcing und das Steuerkennzeichen-Problem
Wer heute einkauft, kauft selten nur im eigenen Land. Ein mittelständischer Maschinenbauer bezieht Gussteile aus Polen, Elektronik aus Taiwan über einen Distributor in den Niederlanden, Software-Lizenzen aus Irland und Verpackung von einem deutschen Lieferanten, der wiederum aus Tschechien importiert. Auf jeder Bestellung steht eine Klausel mit drei Buchstaben: EXW, FCA, FOB, CIF, DAP, DDP. Und irgendwo am Ende der Kette sitzt jemand, der für genau diese Rechnung ein Steuerkennzeichen vergeben muss.
Das ist der Punkt, an dem es regelmäßig schiefgeht. Nicht weil die Leute schlecht sind, sondern weil die Aufgabe strukturell unterschätzt wird.
Was Incoterms sind — und was sie ausdrücklich nicht sind
Incoterms regeln drei Dinge: wann der Gefahrübergang stattfindet, wer welche Transportkosten trägt und wer die Zollabwicklung übernimmt. Das ist eine handelsrechtliche, logistische Vereinbarung. Mehr nicht.
Was Incoterms nicht regeln: die umsatzsteuerliche Behandlung. Es gibt kein Steuerkennzeichen, das einer Incoterm-Klausel zugeordnet ist. „DDP" ist kein Steuersachverhalt. Trotzdem ist genau das einer der häufigsten Denkfehler in der Praxis — die Klausel von der Bestellung ablesen und im Kopf eine 1:1-Zuordnung zu einem Tax Code bauen.
Die Wahrheit ist subtiler: Der Incoterm ist kein Entscheider, aber ein wichtiger Indikator. Er beeinflusst, wer Schuldner der Einfuhrumsatzsteuer ist, in welchem Land der Ort der Lieferung liegt, ob eine Registrierungspflicht im Bestimmungsland entsteht — aber immer nur im Zusammenspiel mit anderen Fakten. Ein DDP-Lieferant aus einem Drittland, der nach Deutschland liefert, schuldet hier die Einfuhrumsatzsteuer und braucht unter Umständen eine deutsche Registrierung. Derselbe Lieferant unter DAP — und plötzlich ist der Käufer der Importeur, mit ganz anderem Vorsteuerabzug und anderem Kennzeichen.
Gleiche Ware. Gleicher Lieferant. Ein Buchstabe anders. Anderes Steuerkennzeichen.
Warum Multi-Country-Sourcing die Sache eskalieren lässt
Bei einer simplen inländischen Rechnung ist das Steuerkennzeichen meist trivial. Die Komplexität entsteht nicht durch das einzelne Land, sondern durch die Kombination:
- Reihengeschäfte. A in Italien verkauft an B in Deutschland, B verkauft an C in Frankreich, die Ware geht direkt von Italien nach Frankreich. Welche Lieferung in dieser Kette ist die „bewegte" Lieferung (§ 3 Abs. 6a UStG)? Davon hängt ab, welcher Beteiligte die steuerfreie innergemeinschaftliche Lieferung hat und wer wo Umsatzsteuer abführt. Der Incoterm zwischen den Parteien ist eines der Indizien für die Transportzuordnung.
- Dreiecksgeschäfte (§ 25b UStG) mit ihrer Vereinfachungsregelung — die nur greift, wenn jede Voraussetzung exakt erfüllt ist.
- Konsignations- und Call-off-Lager (§ 6b UStG seit den Quick Fixes 2020) — die Ware bewegt sich, der steuerliche Umsatz aber zeitversetzt.
- Drittlandsimport mit Zwischenlager in der EU, bei dem der Incoterm darüber entscheidet, ob überhaupt ein innergemeinschaftlicher Vorgang oder eine Einfuhr vorliegt.
- Bauleistungen und sonstige Leistungen über die Grenze, bei denen Reverse Charge nach § 13b greift — oder eben nicht, je nach Ansässigkeit und Leistungsort.
Jede dieser Konstellationen verlangt sechs bis acht Einzelfakten, die an völlig unterschiedlichen Stellen liegen: der Incoterm auf der Bestellung, die USt-IDs in den Stammdaten, die tatsächliche Warenbewegung im Lieferschein, die Leistungsart im Vertrag, die Position in der Lieferkette in den Köpfen des Einkaufs. Niemand sieht diese Fakten an einem Ort. Und genau deshalb wird im Zweifel das genommen, was „beim letzten Mal auch ging".
Warum generische KI das nicht löst
Der naheliegende Gedanke 2026: „Dann fragen wir halt ein großes Sprachmodell." Das funktioniert nicht zuverlässig, und zwar aus denselben Gründen, die wir an anderer Stelle ausführlich beschrieben haben — generische Modelle klingen kompetent, liegen aber bei konkreten Steuerfällen gefährlich oft daneben. Ein LLM erklärt Ihnen Incoterms lehrbuchreif. Es wird Ihnen mit voller Überzeugung sagen, dieser Vorgang sei ein Dreiecksgeschäft — und dabei übersehen, dass eine der drei Parteien keine gültige USt-ID im richtigen Land hat.
Das deckt sich exakt mit dem Muster, das wir generell bei KI in der Buchhaltung sehen: stark in der Interpretation, gefährlich in der unbeaufsichtigten Entscheidung. Und es ist dasselbe strukturelle Problem wie bei den klassischen SAP-Steuerkennzeichen-Tabellen: Eine starre Zuordnungslogik kann den Kontext nicht erfassen, ein halluzinierendes Modell erfasst ihn falsch.
Wo ein speziell trainiertes Small Language Model wirklich hilft
Die Lösung ist keine größere KI. Sie ist eine arbeitsteilige Architektur mit einem kleinen, domänenspezifisch trainierten Modell im Zentrum.
Die entscheidende Einsicht: Fragen Sie das Modell nicht, welches Steuerkennzeichen es sein soll. Lassen Sie es den schwierigen, aber für KI gut lösbaren Teil machen — die Faktenextraktion und -normalisierung:
- Den Incoterm aus der Bestellung lesen und korrekt interpretieren — inklusive der Schreibvarianten, Freitextangaben und der Frage, zwischen welchen Parteien er gilt.
- Ansässigkeit und USt-ID-Status aller Beteiligten aus Stammdaten und Rechnung zusammenführen.
- Ware vs. sonstige Leistung unterscheiden, die tatsächliche Warenbewegung aus dem Lieferschein rekonstruieren, die Position in einer möglichen Reihe erkennen.
Diese normalisierten Fakten gehen anschließend in eine deterministische Regel-Engine, die das Steuerkennzeichen ableitet — nachvollziehbar, prüfungssicher, ohne Halluzinationsspielraum. Keine Kreativität nötig, wo Steuerrecht ein Entscheidungsbaum ist.
Warum ein kleines, speziell trainiertes Modell und nicht das größte verfügbare?
| Kriterium | Generisches Groß-LLM | Spezialisiertes SLM |
|---|---|---|
| Incoterm-/Sourcing-Semantik | Oberflächlich, aus Webdaten | Auf Beschaffungs- und Steuerdokumenten trainiert |
| Datenschutz | Cloud, Daten verlassen das Haus | On-Prem / in Ihrer Umgebung lauffähig |
| Reaktion auf Rechtsänderung | Monate bis zum nächsten Trainingszyklus | Tage durch gezieltes Nachtraining |
| Kosten im Massenbetrieb | Hoch, tokenbasiert | Niedrig, effiziente Inferenz |
| Prüfungstauglichkeit | Plausibel, nicht verifizierbar | Voller Audit-Trail über die Regelschicht |
Sensible Einkaufs- und Lieferantendaten gehören zu den vertraulichsten Informationen eines Unternehmens. Ein Modell, das klein genug ist, um in der eigenen Umgebung zu laufen, löst das Datenschutzproblem nebenbei mit — und ist gleichzeitig billig genug, um es auf jede einzelne Eingangsrechnung anzuwenden, nicht nur auf die auffälligen.
Was das konkret für Finanzteams heißt
Drei pragmatische Schlussfolgerungen:
- Lesen Sie nie das Steuerkennzeichen aus dem Incoterm allein ab. Der Incoterm ist ein Indiz, kein Urteil. Wer ihn als Steuersachverhalt behandelt, produziert systematisch Prüfungsfeststellungen.
- Erfassen Sie die zugrunde liegenden Fakten, nicht nur das Ergebnis. Ein dokumentierter Pfad — welche USt-ID, welche Warenbewegung, welche Regel — ist bei der nächsten Betriebsprüfung mehr wert als ein „passendes" Kennzeichen ohne Begründung.
- Fangen Sie eingegrenzt an. Nicht „das gesamte Sourcing automatisieren", sondern ein wiederkehrendes, schmerzhaftes Szenario — etwa Drittlandsimporte mit DAP/DDP — sauber lösen, lernen, dann erweitern.
KI ersetzt hier niemanden. Sie nimmt dem Buchhalter die Rekonstruktionsarbeit ab und legt ihm eine begründete, prüfbare Empfehlung vor. Die Verantwortung bleibt beim Menschen — aber er arbeitet mit dem Kontext statt gegen ihn.
Genau an dieser Verbindung — KI-gestützte Faktenextraktion plus regelbasierte, prüfungssichere Steuerlogik — arbeiten wir bei HybridAI, unter anderem mit VAT Intelligence für grenzüberschreitende Sachverhalte. Kein generischer Chatbot, der Steuerkennzeichen rät. Sondern ein System, das versteht, dass zwischen einem Incoterm und einem korrekten Tax Code mehr liegt als ein Lookup.