Vom Beleg zum Buchungsvorschlag: Was KI in der Buchhaltung verändert

Rechnung kommt rein, die Belegerkennung liest Lieferant, Rechnungsnummer, Datum und Betrag aus. Das funktioniert seit Jahren und inzwischen auch ziemlich zuverlässig. Die Arbeit, die danach in der Buchhaltung liegen bleibt, ist aber eine ganz andere: Wofür war das eigentlich? Gibt es dazu eine Bestellung? Und auf welche Kostenstelle gehört es?

Diese Fragen beantwortet heute fast immer jemand, der den Betrieb kennt. Jemand, der weiß, dass „Hebebühne 3“ in der Werkstatt steht und dass Herr Maier die Wartung letzte Woche telefonisch beauftragt hat. Genau dieses Zusammenführen von Belegtext und Firmenwissen ist die Stelle, an der Sprachmodelle in der Buchhaltung interessant werden. Beim Auslesen selbst bringen sie wenig Neues.

Die Beispielrechnung

Nehmen wir eine erfundene, aber sehr typische Eingangsrechnung eines Servicedienstleisters:

Nichts Besonderes. Für die Buchhaltung steckt trotzdem eine Menge darin, was nicht auf dem Papier steht. Eine Bestellnummer fehlt, es gibt nur den Hinweis auf Herrn Maier. In der Warenwirtschaft liegt tatsächlich eine Bestellung an Kessler, Text: „Wartung Hebebühne lt. Angebot, 2 Std. inkl. Dichtungen“. Abgerechnet sind aber 2,5 Stunden, und das Hydrauliköl stand nirgends in der Bestellung. Die Kostenstelle hängt daran, wo Hebebühne 3 steht und wem sie gehört.

Was die Belegerkennung liefert

Eine gute Belegerkennung gibt Dir aus diesem PDF die Kopfdaten und meistens auch die Positionen als saubere Felder zurück: Lieferant, USt-IdNr., Rechnungsnummer, Datum, Positionstexte, Mengen, Preise, Steuersatz, Summen. Bei einer E-Rechnung im Format XRechnung oder ZUGFeRD entfällt sogar das Auslesen, die Felder kommen strukturiert mit.

Damit ist ihr Teil erledigt. Was eine Hebebühne ist, weiß sie nicht. Welche davon Deinem Betrieb gehört, erst recht nicht. Und an dieser Stelle hilft auch die schönste XML-Datei nicht weiter, denn die Zuordnung zu Bestellung und Kostenstelle ist Wissen aus Deinem Unternehmen, nicht aus dem Beleg.

Was Regeln erledigen und was ein Sprachmodell

Bevor irgendwo ein Modell ins Spiel kommt, lohnt eine nüchterne Aufteilung. Alles, was sich als Regel formulieren lässt, gehört in eine Regel. Regeln sind schnell, kosten pro Aufruf nichts und liefern beim tausendsten Beleg dasselbe Ergebnis wie beim ersten. Für einen Prüfer sind sie außerdem leicht nachzuvollziehen.

Auffällig an dieser Liste: Das Modell rechnet nie, und es entscheidet nichts allein. Es verbindet Texte mit Daten, die es nicht selbst erfunden hat. Genau darin ist es stark. Ein Sprachmodell versteht ohne weitere Pflege, dass „Hebebühne 3, Halle B“ auf der Rechnung und „Hebebühne Nr. 3 (Werkstatt Halle B)“ im Inventar dasselbe Gerät meinen. Eine Regel bräuchte dafür eine Zuordnungstabelle, die in der Praxis niemand aktuell hält.

Der Ablauf an der Beispielrechnung

1. Regeln zuerst

Der Kreditor wird über die USt-IdNr. gefunden. Eine Rechnung RE-26-1187 von Kessler gibt es noch nicht. 386,80 plus 73,49 ergibt 460,29, die Rechnung ist in sich stimmig. Inländischer Lieferant, 19 %, daraus folgt der Steuerschlüssel. Die Bankverbindung entspricht der im Kreditor hinterlegten.

Dann der erste Punkt, an dem die Regeln aufhören: Eine Bestellnummer steht nicht auf dem Beleg, ein exakter Abgleich ist also nicht möglich. Früher wäre die Rechnung hier zu einem Klärfall geworden.

2. Kontext aus der Sage 100 zusammenstellen

Das Sprachmodell bekommt keinen Zugang zur Datenbank. Es bekommt ein kleines, vorbereitetes Paket mit genau dem, was es für diese Rechnung braucht:

• Die offenen Bestellungen an Kessler aus den letzten acht Wochen, hier zwei Stück
• Die aktiven Kostenstellen mit Bezeichnung
• Die Anlagen und Geräte mit Standort und zuständiger Kostenstelle
• Die letzten Buchungen auf diesen Kreditor mit Konto und Kostenstelle

Dieses Paket ist mit ein paar festen Abfragen geschnürt. Das liegt am Datenmodell der Sage 100: Bestellungen, Kontokorrent, Kostenstellen und Buchungshistorie hängen über klare Schlüssel zusammen, und das seit vielen Versionen stabil. Für so eine Anwendung ist das eine sehr dankbare Grundlage. Wie wir solche festen Zugriffe grundsätzlich bauen, steht im Beitrag zu Sprachmodellen und ERP.

3. Das Modell ordnet zu

Die Aufgabe an das Modell ist eng formuliert: Ordne jede Position einer Bestellposition zu oder sage, dass es keine gibt. Wähle die Kostenstelle aus der übergebenen Liste oder antworte mit „unklar“. Begründe jede Zuordnung. Beträge gibst Du nicht zurück. Die Antwort kommt als strukturierte Daten, nicht als Fließtext:

{
  "bestellung": {
    "nummer": "B-2026-0412",
    "sicherheit": "hoch",
    "begruendung": "Gleicher Lieferant, Auftrag am 02.10. durch Maier, Bestelltext nennt Wartung Hebebühne"
  },
  "positionen": [
    { "pos": 1, "art": "Dienstleistung", "bestellposition": 1, "kostenstelle": "430",
      "hinweis": "2,5 Std. berechnet, 2 Std. bestellt" },
    { "pos": 2, "art": "Ersatzteil", "bestellposition": 1, "kostenstelle": "430" },
    { "pos": 3, "art": "Betriebsstoff", "bestellposition": null, "kostenstelle": "430",
      "hinweis": "Nicht bestellt, passt fachlich zur Wartung" },
    { "pos": 4, "art": "Nebenkosten", "bestellposition": 1, "kostenstelle": "430" }
  ]
}

Die Kostenstelle 430 ist hier die Werkstatt. Das Modell hat sie über den Inventareintrag der Hebebühne gefunden und nicht, weil Kessler sonst immer auf 430 gebucht wird. Beides steht in der Begründung, die der Mensch später sieht.

4. Regeln prüfen die Antwort

Was aus dem Modell kommt, wird behandelt wie jede andere Eingabe von außen. Sie wird geprüft. Gibt es Bestellung B-2026-0412, gehört sie zu Kessler, ist sie noch offen? Ist Kostenstelle 430 aktiv? Steht jede Rechnungsposition genau einmal in der Antwort? Fällt eine dieser Prüfungen durch, wird der Beleg zum Klärfall, egal wie überzeugend die Begründung formuliert ist.

Weil das Modell keine Beträge liefert, kann es auch keine Beträge verfälschen. Die Zahlen im Buchungsvorschlag stammen aus der Belegerkennung und den Regeln, nie aus dem Sprachmodell.

5. Der Buchungsvorschlag

Am Ende steht ein Vorschlag, keine Buchung. Er landet in der Sage 100 als Stapel zur Freigabe und wird über die Objektschicht angelegt, damit dieselben Prüfungen greifen wie bei einer Erfassung von Hand. Die Buchhalterin sieht Kreditor, Konto, Kostenstelle, die zugeordnete Bestellung, die Begründung und zwei markierte Stellen: Die halbe Stunde mehr und das nicht bestellte Öl. Sie fragt kurz bei Herrn Maier nach und gibt frei.

Aus ein paar Minuten Recherche in drei Masken ist eine Rückfrage geworden, und zwar eine, die tatsächlich jemand stellen sollte.

Wo es schiefgehen kann

Ein Sprachmodell kann sich irren, und es irrt sich in vollständigen, gut klingenden Sätzen. Dagegen hilft die geschlossene Liste: Wer nur aus vorhandenen Kostenstellen und Bestellungen wählen darf, kann keine erfinden. Und gegen eine falsche, aber existierende Zuordnung hilft nur, dass ein Mensch freigibt und die Begründung liest.

Das größere Risiko sind die Stammdaten. Wenn ein Drittel aller Eingangsrechnungen bisher auf „Sonstiges“ gebucht wurde, lernt jedes System aus der Historie genau das. Eine Anlagenliste ohne Standort oder ohne Kostenstelle macht die Zuordnung im Beispiel unmöglich, egal wie gut das Modell ist. In vielen Projekten ist das Aufräumen dieser Listen der eigentliche Aufwand.

Dann die Gewöhnung. Nach ein paar Wochen mit guten Vorschlägen klickt niemand mehr in die Begründung. Miss deshalb von Anfang an, wie oft Vorschläge korrigiert werden, und schau Dir die Korrekturen regelmäßig an. Wenn die Quote steigt, stimmt etwas mit den Daten nicht.

Und schließlich die Frage, wohin die Daten gehen. Rechnungen enthalten Namen, Adressen und manchmal mehr. Schick dem Modell nur, was es für die Zuordnung braucht, und kläre Anbieter, Serverstandort und Auftragsverarbeitung mit Deinem Datenschutzbeauftragten. Wer Belege automatisiert vorkontiert, sollte das außerdem in der Verfahrensdokumentation beschreiben.

Aus Korrekturen werden Regeln

Ein Punkt, der in Diskussionen über KI in der Buchhaltung fast immer fehlt: Das Sprachmodell muss nicht für immer zuständig bleiben. Jede Korrektur ist ein Datenpunkt. Wenn die Buchhaltung Hydrauliköl dreimal hintereinander von der Werkstatt auf das Lager umkontiert, weil Öl dort zentral eingekauft wird, braucht es kein besseres Modell. Es braucht eine Regel.

Mit der Zeit wandern so die stabilen Fälle vom Modell zu festen Regeln, und das Modell kümmert sich um das, was wirklich neu oder unklar ist. Das System wird dadurch billiger, schneller und leichter zu prüfen. Wir halten das für den gesündesten Weg, Sprachmodelle in einem so regelgebundenen Bereich einzusetzen.

Wie ich anfangen würde

1. Eine Rechnungsart auswählen. Die, bei der heute am häufigsten nachgefragt wird. Oft sind das Service- und Instandhaltungsrechnungen ohne Bestellnummer.
2. Erst die Regeln bauen. Kreditor, Dubletten, Rechnerik, Steuerschlüssel, Abgleich mit Bestellnummer. Das allein nimmt schon einen guten Teil der Handarbeit weg.
3. Das Modell nur für Zuordnungsfragen einsetzen. Mit geschlossenen Listen, Pflicht zur Begründung und der Möglichkeit, „unklar“ zu sagen.
4. Vorschläge erzeugen, keine Buchungen. Und die Korrekturquote messen, bevor Du über irgendeine Form von Automatik ohne Freigabe nachdenkst.

Was KI in der Buchhaltung verändert, ist weniger das Erfassen. Das war mit Belegerkennung und E-Rechnung schon vorher auf dem Weg. Neu ist, dass das Wissen, das bisher nur im Kopf der erfahrenen Kollegin steckte, aus den Stammdaten der Sage 100 erschlossen werden kann. Vorausgesetzt, es steht dort auch drin.