Autor: Benedikt Köhler

Alle reden gerade über KI in der Buchhaltung. Die Berater haben ihre Slides fertig. Die Softwareanbieter labeln ihre OCR-Tools um. LinkedIn ist voll mit Posts à la „So habe ich meine Finanzprozesse automatisiert – kommentiere FINANCE für meinen n8n-Workflow.“ Wrapper überall.

Ich bin mir ziemlich sicher: KI wird die Buchhaltung verändern. Aber nicht so, wie die meisten denken, und wahrscheinlich nicht so schnell, wie die Schlagzeilen suggerieren.

Das Begriffschaos

Fangen wir bei den Basics an, denn die Sprache drumherum ist ein Desaster. Wenn Leute „KI in der Buchhaltung“ sagen, können sie Folgendes meinen:

Regelbasierte Automatisierung: Wenn Rechnungsbetrag > 10.000, dann an CFO weiterleiten. Wenn „Innergemeinschaftliche Lieferung nach § 4 1b“, dann „USt_00″. Das ist keine KI. Das ist Code mit Marketingbudget.

Machine-Learning-Klassifikatoren: Trainierte Modelle, die Transaktionen anhand von Mustern kategorisieren. Die sind tatsächlich nützlich und gibt es seit Jahren. Aber sie generalisieren oft schlecht und sind schwer aktuell zu halten, weil sie meist eine Black Box sind.

OCR und Dokumentenextraktion: Rechnungen lesen und Lieferantennamen, Beträge, Daten extrahieren. Das ist inzwischen Standard. Und manchmal funktioniert es sogar.

Large Language Models: Unser liebstes neues Spielzeug. GPT, Claude, Gemini. Können Kontext verstehen, chaotische Inputs interpretieren, Sonderfälle behandeln. Aber auch: Zahlen mit absoluter Überzeugung halluzinieren.

Die meisten „KI-Buchhaltungs“-Produkte heute sind eigentlich ML-Klassifikatoren mit einem LLM-Chatbot obendrauf. Was okay ist, aber seien wir ehrlich, was wir da vor uns haben.

Wo KI heute schon funktioniert

Hinter dem ganzen Marketing-Gerede passieren echte Dinge:

Belegerfassung und -extraktion. Moderne Systeme können Rechnungen in jedem Format lesen, jeder Sprache, jeder Scan-Qualität. Die Kombination aus Vision Models und LLMs hat dieses Problem im Prinzip gelöst. Für Sonderfälle braucht man noch Menschen, aber 80-90% Durchlaufquote ist machbar. Und wenn eine Rechnung in neuem Format kommt, funktioniert es trotzdem. Because AI.

Transaktionskategorisierung. Für Standardfälle sind ML-Modelle exzellent darin, euren Kontenrahmen zu lernen und konsistent anzuwenden. Sie werden freitagnachmittags nicht müde. Sie haben keine „kreativen“ Interpretationen von Kostenstellen. Übrigens: KI heißt nicht automatisch LLM. Es gibt eine tolle Familie von Encoder-Modellen unter 1 Milliarde Parameter, die bei Klassifikationsaufgaben hervorragend sind.

Anomalie-Erkennung. Doppelte Rechnungen finden, ungewöhnliche Beträge, Lieferanten, die plötzlich ihre Bankverbindung geändert haben. Mustererkennung im großen Stil ist genau das, was ML gut kann. Und schnell. Sehr nützlich für Betrugsprävention und Audit-Vorbereitung.

Natural Language Queries. „Zeig mir alle Marketing-Ausgaben über 50k vom letzten Quartal“ ohne SQL zu schreiben. Das funktioniert jetzt. Keine Magie, aber sieht aus wie Magie und spart echt Zeit. Warum nicht mal mit seinen Geschäftsdaten chatten? 😉

Der gemeinsame Nenner? Das sind alles Aufgaben, bei denen „meistens ungefähr richtig“ wertvoll ist und Menschen das Ergebnis leicht prüfen können.

Wo es interessant wird (und gefährlich)

Jetzt zum schwierigen Teil.

Sobald KI eine Entscheidung mit rechtlichen oder steuerlichen Konsequenzen treffen soll, ändert sich alles. Nehmen wir die Umsatzsteuer-Ermittlung bei einer Eingangsrechnung. Klingt einfach: 19%, oder?

Außer wenn nicht. Sitzt der Lieferant in einem anderen EU-Land? Ist das eine Dienstleistung oder eine Ware? Greift Reverse Charge? Ist es eine Bauleistung (§13b)? Ist der Lieferant überhaupt umsatzsteuerlich registriert? Dreiecksgeschäft? Gab es eine Pandemie mit Sondersteuersätzen?

Ich habe über dieses spezifische Problem mit Steuerkennzeichen in ERP-Systemen schon geschrieben. Kurzversion: Es gibt dutzende Sonderfälle, und Fehler bedeuten Prüfungsfeststellungen, Steuernachzahlungen und möglicherweise Betrugsvorwürfe.

Die unbequeme Wahrheit: LLMs sind sehr gut darin zu erklären, was Reverse Charge ist. Im akademischen Stil oder als Sonett. Aber sie sind gefährlich unzuverlässig darin zu bestimmen, ob eine konkrete Rechnung es anwenden sollte. Der Unterschied ist wichtig.

Das Halluzinationsproblem ist real. Ein LLM wird dir mit voller Überzeugung sagen, dass diese Rechnung eindeutig als innergemeinschaftliche Lieferung zu behandeln ist. Es zitiert vielleicht sogar die relevante EU-Richtlinie. Und liegt trotzdem komplett falsch, weil es nicht bemerkt hat, dass der Lieferant eine deutsche USt-ID hat, oder weil die Ware das Land nie verlassen hat. Ich habe ein paar Beispiele durch verschiedene LLMs gejagt – und sie hatten sehr starke Meinungen. Aber nicht unbedingt richtige. Deshalb bauen wir gerade eine VATBench, um das besser zu verstehen.

Wenn Claude oder GPT bei kreativem Schreiben einen Fehler macht, bekommt man einen seltsamen Satz. Wenn es bei der Steuerermittlung einen Fehler macht, bekommt man eine sechsstellige Nachzahlung bei der nächsten Prüfung.

Die hybride KI-Architektur, die wirklich funktioniert

Was heißt das also? Nicht „KI schlecht, Menschen gut.“ Die Antwort ist architektonisch. Ein Muster, das wirklich funktioniert, kombiniert drei Dinge:

LLMs für Interpretation. Lass das Sprachmodell die Rechnung lesen, relevante Fakten extrahieren, den Transaktionstyp klassifizieren, die Jurisdiktion des Lieferanten identifizieren. Das können sie gut – Informationsextraktion!

Strukturierte Regeln für Entscheidungen. Steuerrecht ist nicht kreativ. Es ist ein Entscheidungsbaum mit vielen Verzweigungen aber klarer Logik. Sobald man die Fakten hat, sollte die Regelanwendung deterministisch sein. Keine Kreativität nötig. Keine Halluzination möglich.

Transparente Audit Trails. Jede Entscheidung muss dokumentieren, warum sie getroffen wurde. Welche Rechnungsfelder extrahiert wurden. Wie der Lieferant klassifiziert wurde. Welche Regel das Steuerkennzeichen bestimmt hat. Wenn der Prüfer fragt, braucht man Antworten.

Die Kernerkenntnis: Frag das LLM nicht, welches Steuerkennzeichen es sein soll. Frag es, die Fakten zu extrahieren, dann wende deine Regeln an. Nicht halb so sexy wie „unsere KI macht alles automatisch.“ Aber es funktioniert.

Was das für CFO-Offices und Finanzteams bedeutet

Ein paar praktische Schlussfolgerungen:

Ihr werdet nicht ersetzt. Die „KI automatisiert Buchhaltung weg“-Takes werden meist von Leuten geschrieben, die noch nie einen Monatsabschluss gemacht haben.

Euer Job verändert sich. Weniger Dateneingabe, mehr Kontrolle. Weniger manuelles Matching, mehr Ausnahmebehandlung. Weniger Tippen, mehr Denken. Wenn ihr 60% eurer Zeit mit automatisierbaren Aufgaben verbringt, solltet ihr definitiv über KI reden.

Ihr müsst die Tools verstehen. Nicht wie man ein LLM von Grund auf baut (obwohl das echt Spaß macht). Aber wie sie funktionieren, wo sie scheitern, was sie können und was nicht. Die Finance-Leader, die erfolgreich sein werden, sind die, die KI-Anbieter mit echtem technischen Verständnis bewerten können.

Fangt mit eingegrenzten Problemen an. Versucht nicht, „die gesamte Finance-Funktion KI-fähig zu machen.“ Wählt einen schmerzhaften Prozess mit klaren Erfolgskriterien. Rechnungserfassung. Spesenkategorisierung. Intercompany-Abstimmung. Bringt das zum Laufen, lernt daraus, dann erweitert.

Fazit: KI in der Buchhaltung

KI in der Buchhaltung ist gleichzeitig real, nützlich und überhypt. Die Technologie funktioniert für Informationsextraktion, Mustererkennung und Natural-Language-Interfaces. Sie funktioniert nicht – nicht sicher – für unbeaufsichtigte Entscheidungen bei allem mit rechtlichen Konsequenzen.

Der Ansatz, der gewinnt, kombiniert die Interpretationsfähigkeit von LLMs mit der Präzision regelbasierter Systeme und der Aufsicht menschlicher Experten. Weniger aufregend als „vollautonome KI-Buchhaltung“, aber es ist das, was tatsächlich ausgeliefert wird, tatsächlich funktioniert und tatsächlich Prüfungen übersteht.

Wer jemals in einem SAP-System einen Kreditorenbeleg gebucht hat, kennt das dieses Feld: Steuerkennzeichen. Zwei Buchstaben, manchmal mit Ziffer. V0, V1, V7, VM, VN. Klingt harmlos, ist es aber nicht. Hinter diesem unscheinbaren Feld verbirgt sich eines der fehleranfälligsten Konstrukte im gesamten Finanzwesen. Ein Paradebeispiel dafür, wie gut gemeinte Systematik und Realität in Konflikt geraden können.

Was hier wie ein Konfigurationsdetail aussieht, ist in der Praxis eine der häufigsten Ursachen für umsatzsteuerliche Fehler. Und einer der größten blinden Flecken in SAP-basierten Finanzprozessen.

Wir sprechen regelmäßig mit Finanzteams in mittelständischen Unternehmen, und das Muster ist fast immer dasselbe: Die SAP Steuerkennzeichen wurden irgendwann eingerichtet, niemand weiß mehr genau von wem, die Dokumentation ist lückenhaft, und trotzdem bucht das Team jeden Tag damit. Bis zur nächsten Betriebsprüfung. Dann wird es interessant.

Was Steuerkennzeichen eigentlich tun sollen

Die Grundidee ist einleuchtend. Ein Steuerkennzeichen in SAP definiert, wie ein Geschäftsvorfall steuerlich zu behandeln ist: Welcher Steuersatz gilt? Auf welches Steuerkonto wird gebucht? Ist Vorsteuerabzug möglich? Das System soll sicherstellen, dass bei jeder Buchung automatisch die richtige Steuer berechnet und auf das richtige Konto geschrieben wird.

Kein Wunder also, dass viele Nutzer gezielt nach „Steuerkennzeichen SAP Übersicht“ oder „Steuerkennzeichen SAP Tabelle“ suchen, in der Hoffnung, dort eine eindeutige Antwort zu finden.

In der SAP-Konfiguration werden diese Kennzeichen in der Transaktion FTXP gepflegt. Dort definiert man pro Steuerkennzeichen den Prozentsatz, die zugehörigen Konten und diverse Steuerungsparameter. Die zentralen Tabellen dahinter sind ein kleines Universum für sich.

T007A enthält die Grunddaten der Steuerkennzeichen. Hier wird definiert, ob es sich um Vorsteuer, Ausgangssteuer oder eine sonstige Steuerart handelt. T007S liefert die Beschreibungstexte. A003 speichert die eigentlichen Konditionssätze für die Steuerfindung mit den Prozentsätzen. T007B definiert, welche Konten angesprochen werden, also die Verbindung zwischen Steuerkennzeichen und Hauptbuch. T007V definiert die Zuordnung zu den Feldern der Umsatzsteuervoranmeldung.

Wer sich durch diese Tabellen klickt, stößt auf ein komplexes Geflecht von Abhängigkeiten. Ein Steuerkennzeichen ist eben nicht nur ein Prozentsatz. Es ist ein Bündel von Steuerungsparametern: Welche Steuerart? Welche Buchungsrichtung? Welches Konto für die Steuer, welches für die Bemessungsgrundlage? Welche Kennzahl in welchem Feld der UStVA? Ist die Steuer abziehbar? Wird sie beim Zahlungseingang fällig oder bei Rechnungsstellung?

Kurz zusammengefasst:

Tabelle	Funktion
T007A	Art des Steuerkennzeichens (Vorsteuer, Umsatzsteuer etc.)
T007S	Beschreibungstexte
A003	Steuersätze und Konditionen
T007B	Zuordnung zu Steuerkonten
T007V	Zuordnung zur USt-Voranmeldung

Das klingt nach einem sauberen System. Ist es auch, solange man in einer Welt lebt, in der es nur deutsche Inlandsgeschäfte mit 19% oder 7% Mehrwertsteuer gibt.

Die Realität: Wo die Systematik bröckelt

Leider sieht die Realität anders aus. Schon bei einem einfachen deutschen Unternehmen mit EU-Geschäft wird die Sache komplex. Innergemeinschaftliche Lieferungen, Reverse-Charge-Verfahren, Dreiecksgeschäfte, steuerfreie Ausfuhren, nicht steuerbare Leistungen: Für jeden dieser Fälle braucht man eigene Steuerkennzeichen. Und jedes dieser Kennzeichen muss korrekt konfiguriert sein. Richtiger Prozentsatz, richtiges Konto, richtiges Kennzeichen in der Umsatzsteuervoranmeldung.

Das Problem beginnt schon bei der Anlage. Viele Unternehmen kopieren Steuerkennzeichen aus Vorlagen oder von Beratern, ohne die Hintergründe vollständig zu verstehen. Die Frage „Warum haben wir eigentlich V1 und V7 für 19%?“ kann oft niemand beantworten. V1 steht typischerweise für Vorsteuer abzugsfähig, V7 für Vorsteuer nicht abzugsfähig. Aber das ist nur Konvention, keine harte SAP-Logik.

Dann kommen die Sonderfälle. Ein paar Beispiele aus der Praxis:

Reverse Charge bei Bauleistungen (§13b UStG): Der Leistungsempfänger schuldet die Umsatzsteuer. Das Steuerkennzeichen muss eine Steuer ausweisen, die aber nicht als Vorsteuer abgezogen, sondern gleichzeitig als Umsatzsteuer geschuldet wird. In SAP bedeutet das: zwei verschiedene Konten, spezielle Kennzeichen für die UStVA, und ein Buchhalter, der verstehen muss, wann dieser Fall überhaupt vorliegt.

Der Klassiker: Innergemeinschaftlicher Erwerb: Ware aus einem EU-Land, die Steuer wird im Inland geschuldet. Wieder zwei Buchungen (Vorsteuer und Umsatzsteuer), wieder spezielle UStVA-Kennzeichen, wieder die Frage: Wann genau liegt ein ig. Erwerb vor und wann eine normale Einfuhr?

Einfuhrumsatzsteuer: Ware aus Drittland, Steuer wird beim Zoll gezahlt. Das Steuerkennzeichen muss die EUSt als Vorsteuer erfassen, aber es gibt keine korrespondierende Umsatzsteuer. Die EUSt wird oft separat gezahlt und muss mit dem Zollbeleg abgestimmt werden. Das vergessen viele.

Differenzbesteuerung (§25a UStG): Gebrauchtwarenhändler dürfen nur die Differenz zwischen Ein- und Verkaufspreis versteuern. Spezielle Steuerkennzeichen, spezielle Berechnung, spezielle Dokumentationspflichten.

Man könnte diese Liste beliebig fortsetzen. Photovoltaik-Anlagen mit Nullsteuersatz, Kleinunternehmerregelung, steuerfreie Heilbehandlungen (zum Glück für Unternehmen nicht so relevant), Reiseleistungen. Jeder dieser Fälle hat eigene Regeln, und jede dieser Regeln muss in SAP abgebildet werden.

In all diesen Fällen entscheidet nicht das System, sondern der Mensch. SAP führt lediglich aus, was ihm vorgegeben wurde.

Der manuelle Workaround: Wissen in Köpfen statt im System

Was passiert in der Praxis? Die meisten Unternehmen lösen das Problem durch Menschen. Es gibt den einen Kollegen, der „das mit den Steuern kann“. Er weiß, dass bei Lieferant X aus Österreich Kennzeichen VM zu verwenden ist, weil der Reverse Charge macht, aber bei Lieferant Y aus Österreich das normale V1, weil der eine deutsche USt-ID hat. Er weiß auch, dass bei bestimmten Rechnungen das Kennzeichen manuell übersteuert werden muss, weil der Kreditorenstamm nicht stimmt.

Dieses Wissen ist nirgendwo dokumentiert. Es existiert in Köpfen, in Excel-Listen mit „Tipps zur Kontierung_final_letzterStand_2024“, in Post-its am Monitor. Wenn dieser Kollege im Urlaub ist, krank wird oder das Unternehmen verlässt, hat man ein Problem. Wenn er einen schlechten Tag hat und das falsche Kennzeichen wählt, hat man auch ein Problem. Nur merkt man das erst später.

Die SAP-Standardlogik hilft hier nur bedingt. Ja, man kann im Kreditorenstamm ein Standard-Steuerkennzeichen hinterlegen. Aber das funktioniert nur, solange dieser Kreditor immer dieselbe Art von Leistung liefert, immer aus demselben Land, immer unter denselben steuerlichen Voraussetzungen. Sobald ein Lieferant mal eine Dienstleistung statt einer Warenlieferung fakturiert, greift das Standard-Kennzeichen ins Leere.

Auch die automatische Steuerfindung über Konditionstechnik (im SD-Bereich) hat ihre Grenzen. Sie ist komplex zu konfigurieren, schwer zu durchschauen und löst das grundsätzliche Problem nicht: Dass die steuerliche Beurteilung eines Vorgangs von Informationen abhängt, die im Beleg nicht oder nicht vollständig vorhanden sind.

Das Prüfungsrisiko: Wenn der Betriebsprüfer nachrechnet

Warum ist das alles mehr als ein akademisches Problem? Weil Betriebsprüfer genau dort hinschauen. Die Finanzverwaltung weiß, dass Steuerkennzeichen ein Schwachpunkt sind. Moderne Prüfungen arbeiten datenbasiert: Der Prüfer lädt sich die Buchungsdaten herunter und lässt Algorithmen laufen, die Unstimmigkeiten finden.

Typische Prüfansätze: Wurden bei innergemeinschaftlichen Erwerben die Kennzeichen für ig. Erwerb verwendet, oder fälschlich normale Vorsteuer? Stimmen die Summen der Steuerkennzeichen mit den UStVA-Meldungen überein? Gibt es Buchungen mit Steuerkennzeichen, die zum Kreditor nicht passen (z.B. deutscher Kreditor mit ig. Erwerb)?

Die Strafen können empfindlich sein. Bei systematischen Fehlern drohen Steuernachzahlungen plus Zinsen. Bei grober Fahrlässigkeit kommen Verspätungszuschläge dazu. Und wenn Vorsatz unterstellt wird, wird es strafrechtlich relevant.

Bei manchen Prüfungen kann ein einziges falsch konfiguriertes Steuerkennzeichen zu sechsstelligen Nachzahlungen führen. Nicht weil jemand betrügen wollte, sondern weil die Komplexität schlicht zu hoch war.

Zwischenfazit: Steuerkennzeichen in SAP sind kein Randthema, sondern ein systemischer Risikofaktor.

Das Skalierungsproblem: Wachstum macht es schlimmer

Was bei zehn Kreditoren noch funktioniert, wird bei hundert schwierig und bei tausend praktisch unmöglich. Jeder neue Lieferant muss steuerlich beurteilt werden. Jede Änderung in der Gesetzgebung (und davon gibt es reichlich) muss in den Stammdaten und Kennzeichen nachgezogen werden. Jeder neue Geschäftsfall erfordert möglicherweise ein neues Steuerkennzeichen.

Unternehmen, die wachsen, ob organisch oder durch Akquisition, stehen vor einem klassischen Dilemma: Entweder sie investieren massiv in Stammdatenpflege und Prozessdokumentation, oder sie leben mit dem Risiko. Beides ist teuer, nur auf unterschiedliche Weise.

Die steuerlichen Anforderungen werden auch nicht einfacher. E-Invoicing-Pflichten, neue Meldepflichten im EU-Kontext, Änderungen bei Reverse Charge. Das regulatorische Umfeld verdichtet sich. Wer heute schon am Limit arbeitet, wird morgen überholt.

SAP und DATEV: Der kritische Übergang

Ein Aspekt, der in vielen Diskussionen untergeht: Die Steuerkennzeichen müssen nicht nur in SAP stimmen. Sie müssen auch korrekt in nachgelagerte Systeme übergeben werden. Viele Unternehmen arbeiten mit DATEV für die Steuerdeklaration oder den Steuerberater. Und genau an dieser Schnittstelle entstehen neue Fehlerquellen.

SAP und DATEV sprechen nicht dieselbe Sprache. Ein Steuerkennzeichen V1 in SAP muss in einen DATEV-Steuerschlüssel übersetzt werden, und diese Übersetzung ist keineswegs trivial. Unterschiedliche Mandanten, unterschiedliche Kontenrahmen, unterschiedliche Interpretationen desselben Sachverhalts. Was in SAP korrekt gebucht wurde, kann in DATEV falsch ankommen, wenn die Mapping-Tabellen nicht sauber gepflegt sind.

Das Ergebnis: Die UStVA stimmt nicht mit den SAP-Daten überein. Der Steuerberater fragt nach. Die Abstimmung kostet Zeit. Im schlimmsten Fall werden Fehler erst bei der Jahresabschlussprüfung entdeckt, Monate nach der ursprünglichen Buchung.

Wer dieses Problem kennt, weiß: Der [Übergang von SAP nach DATEV](#link-begleitartikel-datev) ist ein eigenes Thema, das sorgfältige Planung erfordert.

Der Ausweg: Vom manuellen Wissen zur systematischen Automatisierung

An diesem Punkt muss man sich ehrlich fragen: Ist das Problem überhaupt manuell lösbar? Theoretisch ja, mit genug Personal, genug Schulung, genug Kontrolle. Praktisch nein, weil die Kosten dafür in keinem Verhältnis stehen und weil Menschen Fehler machen, gerade bei repetitiven Aufgaben.

Die logische Konsequenz ist Automatisierung. Aber nicht Automatisierung im Sinne von „wir schreiben ein paar ABAP-Reports“, sondern eine intelligente Systemunterstützung, die bei jeder Buchung die steuerliche Beurteilung übernimmt.

Was müsste ein solches System leisten? Es müsste die relevanten Informationen aus dem Beleg extrahieren: Kreditor, Leistungsart, Herkunftsland, USt-ID, Warenbewegung. Diese Informationen gegen das geltende Steuerrecht abgleichen. Das passende Steuerkennzeichen vorschlagen oder direkt setzen. Und nachvollziehbar dokumentieren, warum es zu dieser Empfehlung gekommen ist.

Die Rolle von KI: Nicht Magie, sondern Methode

Hier kommen moderne KI-Ansätze ins Spiel. Nicht als Wunderlösung, sondern als Werkzeug für ein Problem, das mit regelbasierter Programmierung allein nicht mehr zu beherrschen ist.

Die Stärke von KI-Sprachmodellen (Large Language Models oder auch Small Language Models) liegt darin, unstrukturierte Informationen zu verstehen und einzuordnen. Eine Rechnung mit dem Text „Consulting services as per framework agreement“ ist für einen Menschen sofort als Dienstleistung erkennbar. Für eine klassische regelbasierte Software ist das schwierig, sie bräuchte explizite Schlüsselwörter oder Stammdateneinträge. Ein LLM kann diese Einordnung leisten.

Aber ein LLM allein reicht nicht, und das ist entscheidend. Steuerrecht ist nicht kreativ. Es ist binär: richtig oder falsch. Ein System, das Steuerkennzeichen vorschlägt, darf nicht halluzinieren. Es braucht eine Architektur, die die Interpretationsfähigkeit von KI mit der Präzision regelbasierter Systeme verbindet. Das LLM für die Informationsextraktion und Klassifikation, strukturierte Abfragen für die Anwendung des Steuerrechts.

Die technischen Komponenten dafür existieren. Retrieval-Augmented Generation (RAG) erlaubt es, aktuelle Rechtsvorschriften und interne Richtlinien in den Entscheidungsprozess einzubeziehen. SQL-Abfragen gegen SAP-Tabellen liefern die harten Fakten aus den Stammdaten. Eine saubere Orchestrierung sorgt dafür, dass das Ergebnis nachvollziehbar und prüfungssicher dokumentiert wird.

Der Weg nach vorn

Steuerkennzeichen in SAP sind kein IT-Problem. Sie sind ein Prozessproblem, das durch IT gelöst werden kann, aber nur mit dem richtigen Ansatz. Wer versucht, die Komplexität mit mehr Personal, mehr Schulung, mehr Kontrolle zu beherrschen, kämpft gegen Windmühlen. Die Komplexität wächst schneller als jede Organisation skalieren kann.

Der realistischere Weg: Die Entscheidungslogik aus den Köpfen holen und in ein System überführen, das bei jeder Buchung konsistent, nachvollziehbar und prüfungssicher arbeitet. Das bedeutet nicht, den Menschen aus dem Prozess zu entfernen. Es bedeutet, ihm die richtigen Werkzeuge an die Hand zu geben. Ein System, das die Informationen aus der Rechnung liest, gegen die Stammdaten und das geltende Recht abgleicht, und einen qualifizierten Vorschlag macht. Der Buchhalter bleibt in der Verantwortung, aber er arbeitet mit einer prüfbaren Empfehlung statt gegen die Komplexität.

Das ist technisch anspruchsvoll. Es erfordert saubere Datenarchitektur, eine intelligente Verknüpfung von Regellogik und maschinellem Lernen, und eine enge Integration mit dem SAP-System. Aber es ist machbar. Die Technologie ist da. Was oft fehlt, ist der Mut, das Problem strukturell anzugehen, statt es jedes Quartal mit Überstunden vor der UStVA zu lösen.

Für jedes Unternehmen, das wächst oder das seine Prüfungsrisiken ernst nimmt, ist diese Automatisierung früher oder später unvermeidlich. Die Frage ist nicht ob, sondern wann. Und ob man vorbereitet ist, wenn der Betriebsprüfer klingelt.

Wer Steuerkennzeichen nicht mehr manuell entscheiden will, sondern kontextuell und prüfungssicher automatisieren möchte, braucht dafür andere Werkzeuge als Tabellen und Erfahrungswissen.

Wenn heute von Fortschritten bei generativer KI die Rede ist, heißt es schnell: „Das neue Modell ist besser.“ Gemeint ist dann je nachdem: mehr Wissen, bessere Antworten, stabileres Verhalten, bessere Benchmarks oder ein angenehmerer Stil. Technisch sauber ist diese Aussage aber selten, denn in der Praxis entstehen Verbesserungen auf mehreren Ebenen, die man auseinanderhalten sollte. Sonst redet man aneinander vorbei.

Ganz am Anfang stehen die Trainingsdaten. Sie legen fest, was ein Modell überhaupt lernen kann. Welche Welt es sieht, welche Themen es kennt, welche Sprachen es versteht. In den letzten Jahren kamen viele Sprünge nicht nur daher, dass Modelle größer wurden, sondern weil Daten besser kuratiert, gemischt oder gezielt synthetisch ergänzt wurden („Synthetic Data Revolution“). Zwei Modelle mit identischer Architektur können sich massiv unterscheiden, wenn die Datenbasis eine andere ist. Das wird oft unterschätzt, weil Daten selten öffentlich sind – ihr Effekt ist aber enorm. Und im Finetuning kann man Modelle gezielt neuen Spezialthemen aussetzen, um ihre Kenntnisse zu vertiefen.

Darauf baut dann die Mikro-Architektur auf. Hier geht es um das Innenleben des Modells: Attention, Normalisierung, Optimizer, Trainingsstabilität, Post-Training etc. Viel Fortschritt entsteht hier leise und vergleichsweise unspektakulär (jedenfalls außerhalb der Hardcore AI-Bubble). Modelle gleicher Größe sind heute schlicht besser trainiert als noch vor ein oder zwei Jahren und erzielen bessere Werte in den Benchmarks.

Die Makro-Architektur beschreibt dann die globale Struktur des Modells. Wie Information durch die Layer fließt, welche Teile wann aktiv sind und wie Kapazität genutzt wird. Konzepte wie Mixture-of-Experts oder lernbare Hyper-Connections zwischen Layern verändern nicht einzelne Bausteine, sondern die Gesamtorganisation. Gerade bei Small Language Models ist das ein wichtiger Hebel, weil man mehr Leistung herausholen kann, ohne proportional mehr Rechenbudget zu brauchen.

Am meisten unterschätzt wird jedoch der Harness. Er entscheidet, wie ein Modell tatsächlich eingesetzt wird. Welche Informationen in den Kontext gelangen, wie mit langen Kontexten umgegangen wird, ob Tools genutzt werden dürfen, ob geplant, geprüft oder rekursiv nachgebessert wird. Spätestens hier zeigt sich: Kontext ist keine kostenlose Ressource. Wer alles in den Prompt kippt, bekommt selten bessere Antworten, sondern oft instabiles Verhalten (Stichwort: „Context Rot“).

Ansätze wie Recursive Language Models zeigen sehr schön, wie groß der Effekt reiner Harness-Innovationen sein kann. Das Modell bleibt gleich, aber der Kontext wird nicht mehr blind gefüttert, sondern aktiv durchsucht und strukturiert. Plötzlich werden Aufgaben lösbar, die vorher außerhalb der Reichweite lagen. Nicht, weil das Modell schlauer ist, sondern weil es besser genutzt wird.

Im Unternehmens-Umfeld ist das nichts Neues. Der Unterschied zwischen einem Demo-Chatbot und einem produktiven System liegt fast nie im Modell. Er liegt in Tests, Staging, Zugriffskontrollen, Auditierbarkeit, deterministischer Tool-Nutzung und sauberer Evaluation. Kurz gesagt: im Harness.

Diese Vier-Layer-Sicht hilft, Fortschritt realistischer einzuordnen. Daten bestimmen, was gelernt werden kann. Mikro-Architektur bestimmt, wie gut gelernt wird. Makro-Architektur bestimmt, wie viel davon nutzbar ist. Und der Harness entscheidet, wie viel davon am Ende wirklich ankommt. Wer nur auf „das Modell“ schaut, verpasst oft genau die spannendsten Entwicklungen.