Das Abtippen von Belegen ist eine der teuersten Routinetätigkeiten im Büro, gemessen daran, wie wenig Urteilsvermögen sie verlangt. Eine Rechnung kommt als PDF, jemand öffnet sie, liest Lieferant, Betrag und Positionen ab und tippt alles in die Buchhaltungssoftware. Genau diese Tätigkeit können Sprachmodelle inzwischen gut übernehmen. Gut heißt allerdings nicht fehlerfrei, und wer das Thema ernsthaft angeht, sollte beides verstehen: warum es heute deutlich besser funktioniert als frühere Ansätze, und wo es weiterhin schiefgeht.

Warum das früher an Vorlagen scheiterte

Automatisches Belegauslesen gibt es seit Jahrzehnten, unter dem Kürzel OCR. Die klassische Variante funktionierte so: Man definiert pro Lieferant eine Vorlage, also die Information, dass der Rechnungsbetrag rechts unten steht und die Rechnungsnummer oben links. Das funktioniert, solange der Lieferant sein Layout nicht ändert und solange man bereit ist, für jeden neuen Lieferanten eine Vorlage zu pflegen. Bei drei Großlieferanten geht das. Bei zweihundert wechselnden Lieferanten wird die Vorlagenpflege selbst zum Vollzeitjob.

Sprachmodelle lösen das Problem anders. Sie lesen das Dokument inhaltlich, so wie ein Mensch, der noch nie eine Rechnung dieses Lieferanten gesehen hat und trotzdem sofort weiß, wo der Betrag steht. Eine Vorlage braucht es nicht mehr. Das ist der eigentliche Durchbruch der letzten Jahre, unspektakulär formuliert: Software kommt jetzt mit Layouts zurecht, die sie nicht kennt.

Und unbekannte Layouts bleiben der Normalfall. Laut einer Bitkom-Befragung (2024) unter 1.103 deutschen Unternehmen ab 20 Beschäftigten empfangen 96 Prozent Rechnungen per E-Mail und 93 Prozent akzeptieren weiterhin Briefpost, aber nur 45 Prozent können strukturierte E-Rechnungen verarbeiten, die das Auslesen überflüssig machen würden. Der Rest liest ab. Oder lässt lesen.

	OCR mit Vorlagen	Sprachmodell
Neuer Lieferant	Vorlage anlegen und testen	funktioniert ohne Vorbereitung
Layout-Änderung	Vorlage bricht, Wartung nötig	unkritisch
Laufender Aufwand	wächst mit jedem Lieferanten	Validierungsregeln pflegen
Typische Fehler	Feld an falscher Stelle gelesen	plausible Zahlendreher, Handschrift

Was ein moderner Auslese-Workflow konkret tut

Der Ablauf, den wir typischerweise bauen, hat vier Stationen. Das Dokument trifft ein, per E-Mail-Anhang, Scan oder Upload. Das Modell liest es aus und liefert strukturierte Daten: Lieferant, Datum, Rechnungsnummer, Nettobeträge, Steuersätze, einzelne Positionen. Dann folgt der Schritt, der über die Verlässlichkeit entscheidet: die Validierung. Feste, programmierte Regeln prüfen, ob die Positionen sich zum Gesamtbetrag summieren, ob die UID-Nummer ein gültiges Format hat, ob der Lieferant im Stammdatensatz existiert, ob eine passende Bestellung vorliegt.

Erst wenn diese Prüfungen bestanden sind, wandern die Daten ins ERP oder in die Buchhaltung. Fällt eine Prüfung durch oder meldet das Modell Unsicherheit, landet der Beleg in einer Prüfliste für einen Menschen, mit dem Originaldokument und den erkannten Werten nebeneinander. Korrigieren dauert dann Sekunden statt Minuten, weil man nicht mehr abtippt, sondern nur noch vergleicht.

Die ehrliche Fehlerliste

Damit keine falschen Erwartungen entstehen: Diese Fälle machen in der Praxis Probleme.

Schlechte Scans und Handyfotos: schief, unscharf, abgeschnitten. Was ein Mensch mühsam entziffert, entziffert das Modell auch nur mühsam, und manchmal falsch.
Handschriftliche Ergänzungen, etwa ein korrigierter Betrag am Rand. Das Modell übersieht sie oder gewichtet sie falsch.
Mehrdeutige Positionen: Sammelpositionen, Teillieferungen, Gutschriften auf derselben Rechnung. Hier ist oft nicht die Erkennung das Problem, sondern die fachliche Zuordnung.
Zahlendreher mit Plausibilität: Erkennt das Modell 1.580 statt 1.850, fällt das keiner Formatprüfung auf. Solche Fehler fängt nur der Abgleich mit der Bestellung oder die menschliche Prüfung.

Konfidenz: die wichtigste Stellschraube

Ein gut gebauter Workflow behandelt nicht alle Belege gleich. Er unterscheidet nach Sicherheit: Ein sauberes PDF eines bekannten Lieferanten mit passender Bestellung kann automatisch durchlaufen. Ein erstmaliger Lieferant, ein ungewöhnlich hoher Betrag oder ein Widerspruch zwischen erkannten Werten geht immer an einen Menschen. Wo diese Schwellen liegen, ist keine technische Frage, sondern eine geschäftliche, und sie gehört zu Beginn des Projekts entschieden, nicht nachträglich.

Unsere Faustregel: lieber am Anfang zu viel zur Prüfung schicken und die Schwellen nach ein paar Wochen echter Daten lockern, als umgekehrt. Vertrauen in so einen Workflow baut sich über nachvollziehbare Wochen auf und ist nach einem einzigen still durchgerutschten Fehler wieder weg.

Verträge sind ein anderes Spiel als Rechnungen

Rechnungen und Lieferscheine sind strukturierte Dokumente mit klaren Zielfeldern. Verträge sind es nicht. Hier geht es meist nicht um Datenübernahme, sondern um Fragen wie: Welche Kündigungsfristen stehen in unseren dreißig Lieferverträgen? Wo verstecken sich automatische Verlängerungen? Ein Sprachmodell kann solche Klauseln zuverlässig finden und mit Fundstelle zusammenfassen, quer über einen ganzen Ordner.

Was es nicht kann, ist die juristische Bewertung. Ob eine Klausel wirksam ist, ob sie im konkreten Fall greift, ob man sich darauf verlassen sollte: Das bleibt beim Anwalt. Der sinnvolle Einsatz ist die Vorarbeit, also aus dreihundert Seiten die fünf relevanten Stellen herauszuholen, samt Verweis, damit ein Mensch dort gezielt weiterliest.

Datenschutz: wo die Belege verarbeitet werden

Rechnungen enthalten Geschäftsdaten, Verträge oft weit Sensibleres. Bevor irgendein Dokument an ein Modell geht, gehört geklärt, wo dieses Modell läuft. Die Bandbreite reicht von APIs mit Auftragsverarbeitungsvertrag über EU-Cloud-Betrieb bis zu Modellen auf eigener Hardware. Welcher Weg passt, hängt von der Sensibilität der Dokumente und den eigenen Vorgaben ab; für die meisten Rechnungsworkflows reicht eine sauber vertraglich geregelte API, für Verträge mit Geheimhaltungspflichten oft nicht.

Wichtig ist nur, dass diese Entscheidung am Anfang fällt und dokumentiert wird. Nachträglich festzustellen, dass zwei Jahre Eingangsrechnungen durch einen Dienst ohne Auftragsverarbeitungsvertrag gelaufen sind, ist ein vermeidbares Gespräch mit dem Datenschutzbeauftragten.