Dokumenten- und Vorgangsagent: Belege lesen, prüfen und den nächsten Schritt vorbereiten

Im Backoffice eines mittelständischen Betriebs wiederholen sich viele Handgriffe täglich: Eine Rechnung kommt als PDF, jemand öffnet sie, sucht Lieferantennummer, Bestellbezug, Beträge und Steuersätze heraus, prüft gegen den Wareneingang und tippt die Werte ins ERP. Bei Lieferscheinen, Reisekostenbelegen, Zollpapieren oder Antragsformularen sieht der Ablauf ähnlich aus. Die fachliche Entscheidung ist selten schwierig, der Aufwand steckt im Suchen und Übertragen.

Genau diese Mischung macht den Prozess geeignet für einen Piloten. Es gibt ein klares Eingangsobjekt, nachvollziehbare Prüfregeln und ein eindeutiges Ergebnis. Fehler lassen sich messen, weil jeder Beleg später ohnehin geprüft und gebucht wird. Und die Grenze zwischen Vorbereitung und verbindlicher Handlung ist leicht zu ziehen: Der Agent bereitet vor, ein Mensch bucht oder gibt die Zahlung frei.

Seit dem 1. Januar 2025 müssen inländische Unternehmen nach Darstellung des Bundesfinanzministeriums E-Rechnungen empfangen können; ein E-Mail-Postfach reicht dafür aus. Als E-Rechnung gilt nur noch ein strukturiertes elektronisches Format, das eine elektronische Verarbeitung ermöglicht, etwa XRechnung oder ZUGFeRD ab Version 2.0.1 mit Ausnahme der Profile MINIMUM und BASIC-WL. Ein einfaches PDF zählt als sonstige Rechnung. Für die Ausstellung gelten Übergangsfristen bis Ende 2026 beziehungsweise Ende 2027.

Für den Agenten folgt daraus eine klare Reihenfolge: Liegt ein strukturierter Teil vor, wird dieser gelesen, nicht das Bild. Das BMF weist darauf hin, dass bei hybriden Formaten inzwischen die Daten des strukturierten Teils maßgeblich sind, wenn sie vom Bildteil abweichen. Texterkennung und Sprachmodell kommen vor allem bei Papier, einfachen PDFs, Lieferscheinen und Anhängen zum Einsatz. Wer das sauber trennt, reduziert Fehlerquellen und kann die KI dort einsetzen, wo es wirklich Freitext zu verstehen gibt.

Der Kern ist ein festes Zielschema je Dokumenttyp. Für eine Eingangsrechnung gehören dazu Lieferant, Rechnungsnummer, Datum, Leistungszeitraum, Netto- und Bruttobetrag, Steuersatz, Bestellnummer und Bankverbindung. Der Agent füllt dieses Schema und liefert zu jedem Feld einen Konfidenzwert sowie die Stelle im Dokument, an der er den Wert gefunden hat. Dadurch kann die prüfende Person mit einem Klick sehen, woher eine Zahl stammt.

Danach greifen Regeln, die unabhängig vom Modell formuliert sind: Stimmt die Summe der Positionen mit dem Gesamtbetrag überein? Existiert die Bestellung und ist der Wareneingang gebucht? Hat sich die Bankverbindung des Lieferanten gegenüber den Stammdaten geändert? Gerade die letzte Prüfung ist wichtig, weil geänderte Kontodaten ein bekanntes Betrugsmuster sind. Solche Abweichungen führen nie zu einer automatischen Übernahme, sondern immer in die Prüfliste.

Die Konfidenzschwelle wird nicht geschätzt, sondern im Testbetrieb kalibriert. Man lässt den Agenten eine Stichprobe bereits gebuchter Belege verarbeiten und vergleicht seine Werte mit den tatsächlich gebuchten. So zeigt sich, ab welcher Schwelle Felder zuverlässig sind und welche Dokumenttypen noch nicht reif für eine Vorbefüllung sind.

Ein Beleg ist selten Selbstzweck. Hinter einer Rechnung steht eine Freigabe durch die Kostenstelle, hinter einem Lieferschein eine Wareneingangsbuchung, hinter einem Antragsformular ein Bearbeitungsschritt im CRM. Der Agent erzeugt deshalb nicht nur einen Datensatz, sondern einen Vorgang: Er ordnet den Beleg der richtigen Person oder Gruppe zu, setzt eine Frist, hängt die Prüfergebnisse an und legt bei Unklarheiten ein Klärungsticket an.

Technisch braucht der Agent dafür Lesezugriff auf Stammdaten und Bestellungen sowie Schreibrechte für Entwürfe, Tickets und Ablage. Das Recht, Buchungen festzuschreiben, Zahlungen auszulösen oder Lieferantenstammdaten zu ändern, bleibt ausdrücklich beim Menschen. Das entspricht einer Empfehlung, die auch im OWASP-Katalog zu Risiken von Sprachmodell-Anwendungen auftaucht: zu viel Funktionalität, zu weitreichende Berechtigungen und zu viel Autonomie gelten dort als Ursachen für Schäden.

Steuerlich relevante Belege unterliegen Aufbewahrungspflichten. Nach der FAQ des Bundesfinanzministeriums ist bei einer E-Rechnung zumindest der strukturierte Teil unversehrt in seiner ursprünglichen Form aufzubewahren; ergänzend verweist das Ministerium auf die GoBD in der zuletzt geänderten Fassung. Für den Agenten heißt das: Er arbeitet immer mit einer Kopie, das Original bleibt unverändert im Archiv, und jede Änderung an extrahierten Werten wird mit Person und Zeitpunkt protokolliert. Die konkrete Bewertung gehört in die Verfahrensdokumentation und zur Steuerberatung.

Viele Belege enthalten personenbezogene Daten, etwa Namen auf Reisekostenbelegen oder Kontaktdaten von Ansprechpartnern. Die DSGVO verlangt unter anderem Zweckbindung, Datenminimierung und angemessene Sicherheit. Praktisch bedeutet das: Der Agent liest nur die Felder, die für den Vorgang nötig sind, Testdaten werden anonymisiert, und bei externen Modellanbietern sind Auftragsverarbeitung, Speicherort und Aufbewahrung von Eingaben zu klären.