Das Schwere ist nicht das Lesen
Legen Sie einem heutigen Modell eine eingescannte Lieferantenrechnung vor, und es nennt Ihnen Rechnungsnummer, Nettobetrag und Steuersatz. Diese Demo entsteht an einem Nachmittag — und genau deshalb werden so viele Vorhaben zur Dokumentenverarbeitung bewilligt und versanden dann. Das Lesen ist der gelöste Teil. Ungelöst ist das Vertrauen: Das Modell liefert dasselbe zuversichtliche JSON, ob es den Betrag korrekt erfasst oder ihn von einem verwischten Fax plausibel zusammenfantasiert hat.
Das ist deshalb entscheidend, weil der Nutzen nicht in der Trefferquote steckt, sondern im Anteil der Belege, die kein Mensch mehr anfasst. Nehmen Sie einen Zulieferer mit 2.000 Eingangsrechnungen im Monat. Erfasst das System jedes Feld zu 95 Prozent korrekt, kann aber nicht sagen, welche 5 Prozent falsch sind, muss die Kreditorenbuchhaltung weiterhin alle 2.000 prüfen. Gewonnen ist nichts. Ein System mit 90 Prozent, das die Fehlgriffe zuverlässig markiert, lässt 90 Prozent dunkel durchlaufen — und darin liegt der gesamte Ertrag.
Prüfen Sie zuerst, ob Sie überhaupt KI brauchen
Bevor jemand eine OCR-Strecke für Rechnungen baut, sollte er in die PDFs hineinsehen. Seit dem 1. Januar 2025 muss jedes inländische Unternehmen strukturierte E-Rechnungen im B2B-Verkehr empfangen können; die Pflicht zum Ausstellen greift ab 2027 für Unternehmen über 800.000 Euro Vorjahresumsatz und ab 2028 für alle. Ihr Eingangsmix verschiebt sich also, während Sie das Projekt noch zuschneiden.
Zwei Formate sind relevant. Die XRechnung ist reines XML. ZUGFeRD — und das französische Pendant Factur-X — ist ein Hybrid: ein PDF/A-3, das aussieht wie eine gewöhnliche Rechnung, die vollständigen Rechnungsdaten aber als eingebettetes XML mitführt. Beide folgen dem semantischen Modell der EN 16931. Ich habe erlebt, wie Teams ein ZUGFeRD-PDF durch OCR und ein Vision-Modell schicken und damit teuer und fehlerbehaftet rekonstruieren, was als Anhang in derselben Datei liegt: exakt korrekt und kostenlos auslesbar.
Die erste Stufe einer Eingangsstrecke ist deshalb kein Modell, sondern eine Abfrage: Hängt an diesem PDF ein EN-16931-XML? Wenn ja, parsen und den Rest überspringen. Dieser Zweig ist deterministisch, zu 100 Prozent korrekt und braucht keine Prüfliste. KI ist für den Rest zuständig — für die Scans, für die PDFs jener Lieferanten, die sich auf Jahre nicht bewegen werden, für Lieferscheine und Auftragsbestätigungen, die keine Norm abdeckt. Bauen Sie den langweiligen Zweig zuerst, dann wird der KI-Zweig kleiner, günstiger und leichter zu verantworten.
Wie eine Pipeline aussieht, die hält
Produktiv überlebt kein kluger Prompt über dem ganzen Dokument. Es überlebt eine Kette schmaler Stufen, von denen sich jede messen lässt und jede verweigern darf.
Die OCR setzt eine Obergrenze, die keine spätere Stufe hebt
Jede nachgelagerte Stufe erbt die Fehler der Texterkennung, und ein Sprachmodell bricht bei schlechter Eingabe nicht sauber ab — es füllt die Lücke mit etwas Plausiblem. Eine „1“, die einem Fax-Artefakt zum Opfer fällt, erzeugt keine Fehlermeldung, sondern einen selbstbewussten falschen Betrag. Tesseract genügt bei sauberem Digitaltext und wird unzuverlässig, sobald Tabellenlinien, Stempel oder ein schiefer Scan ins Spiel kommen. Azure Document Intelligence, AWS Textract oder Google Document AI beherrschen Layout und Tabellen spürbar besser — und bedeuten, Lieferantenrechnungen an einen US-Konzern zu geben. Das ist eine Entscheidung, die man bewusst trifft und nicht in der Prüfung entdeckt. Im eigenen Haus sind PaddleOCR und docTR brauchbar, ebenso Vision-Sprachmodelle, die den separaten OCR-Schritt ganz einsparen — bei deutlich höheren Hardwarekosten. Testen Sie Kandidaten an Ihren 200 hässlichsten Belegen, nicht an einer sauberen Auswahl.
Erst klassifizieren, dann extrahieren
Der Reflex ist ein Prompt, der jeden Beleg liest. Widerstehen Sie ihm. Sortieren Sie zuerst — Rechnung, Gutschrift, Lieferschein, Auftragsbestätigung, Mahnung — und extrahieren Sie dann mit einem Schema, das für diesen Typ geschrieben wurde. Die Klassifikation ist die günstige, langweilige, robuste Hälfte: wenige Klassen, leicht zu messen, leicht zu korrigieren. Sie verschafft Ihnen außerdem eine ehrliche Klasse „unbekannt“ — so werden Belege, mit denen niemand gerechnet hat, geparkt statt still in eine Rechnungsform gepresst. Extraktionsfehler sind teuer und leise, Klassifikationsfehler günstig und laut. Verlagern Sie so viel Entscheidung wie möglich in die laute Hälfte.
Structured Output garantiert die Form, nicht die Wahrheit
Constrained Decoding gegen ein JSON-Schema, das inzwischen jeder ernsthafte Serving-Stack beherrscht, ist wirklich nützlich. Es beseitigt eine ganze Klasse von Parsing-Fehlern und garantiert, dass der Nettobetrag eine Zahl und das Datum ein Datum ist. Es ist zugleich die Stelle, an der Teams zu früh ruhig werden. Schema-valides JSON, das 1.847,00 Euro meldet, während auf der Rechnung 1.347,00 Euro steht, ist einwandfrei gültig und vollständig falsch. Gültigkeit ist eine Eigenschaft des Ausgabeformats, Richtigkeit eine Eigenschaft der Welt. Das Schema müssen Sie übrigens selten erfinden: Für Rechnungen legt § 14 UStG die Pflichtangaben fest und die EN 16931 die Semantik. Nehmen Sie beides.
Konfidenz ist nicht das, was das Modell behauptet
Fragen Sie ein Modell nach seiner Sicherheit, nennt es Ihnen 0,95 — im selben Tonfall, ob es richtig oder falsch liegt. Token-Wahrscheinlichkeiten messen, wie gewöhnlich der Text aussah, nicht, ob das Feld stimmt. Wer seine Prüfschwelle auf die selbstberichtete Konfidenz baut, bekommt ein System, das die falschen Belege prüft.
Echte Konfidenz entsteht aus der Übereinstimmung unabhängiger Prüfungen, die mit dem Modell nichts zu tun haben. Bei einer Rechnung haben Sie dabei einen seltenen Luxus: Der Beleg prüft sich weitgehend selbst, und Ihr ERP prüft den Rest. Ergeben die Positionen in Summe den Nettobetrag? Ergibt Netto plus Steuer zum ausgewiesenen Satz den Bruttobetrag? Führt die USt-IdNr. zu einem bekannten Lieferanten im Stammdatensatz, und stimmt die IBAN mit der hinterlegten überein? Existiert die Bestellnummer, und liegt der Betrag innerhalb der Toleranz zum Wareneingang? Jede Prüfung ist deterministisch und billig. Ein Beleg, bei dem alle übereinstimmen, ist auf eine Weise sicher, die kein Konfidenzwert ausdrücken kann — und weicht eine ab, wissen Sie nicht nur, dass Sie den Beleg umleiten müssen, sondern auch, welches Feld Sie dem Prüfer zuerst zeigen.
Das ist zugleich die ehrliche Antwort auf „Welche Schwelle nehmen wir?“. Sie greifen die Zahl nicht aus dem Modell. Sie definieren das Fehlerbudget, lassen die Prüfungen im Schattenbetrieb gegen das laufen, was Ihr Team tatsächlich gebucht hat, und lesen ab, wo die Linie liegt. Dieser Vergleich gegen einen echten Ist-Wert ist dieselbe Disziplin, auf der jede belastbare Kosten-Nutzen-Rechnung beruht.
Wo es auf das ERP trifft
Die Extraktion sind ein paar Wochen. Die Anbindung ist das Projekt. Eine Buchung in SAP, Dynamics, Sage oder DATEV ist kein JSON-Feld, sondern eine Buchung auf Sachkonto und Kostenstelle, verknüpft mit Bestellung und Wareneingang, in einem System, das geprüft wird. Drei Randbedingungen gehören benannt, bevor Sie einen Termin zusagen. Buchungen müssen idempotent sein, denn dieselbe Rechnung kommt zweimal — einmal per E-Mail, einmal per Post —, und die Dublettenerkennung braucht einen echten Schlüssel statt eines Dateinamens. Korrekturen müssen Stornos sein, keine Änderungen: Die GoBD verlangt, dass eine einmal erfolgte Buchung nachvollziehbar und unveränderbar bleibt. Eine KI, die eine Buchung still überschreibt, ist damit ein Compliance-Mangel und nicht bloß ein Qualitätsthema. Und es braucht eine Verfahrensdokumentation, die festhält, wie Belege verarbeitet und Fehler behandelt werden — sie zu schreiben zwingt zu Antworten, die das Projekt sonst im Vagen ließe.
Lassen Sie das System zuerst wochenlang im Schattenbetrieb mitlaufen, ohne eine einzige Buchung. Es erzeugt seinen Vorschlag parallel zu dem, was das Team tatsächlich bucht, und Sie vergleichen. Der Schattenbetrieb ist die günstigste Messung, die Sie je vornehmen — und die Stelle, an der herauskommt, dass ein Teil Ihrer Lieferanten die Bestellnummer ins Referenzfeld schreibt, ein anderer sie im Positionstext vergräbt und einer sie ausschließlich in den Dateinamen des PDFs setzt. Solche Funde sind der Grund, warum die Datenarbeit die Modellarbeit meist überwiegt.
Wovon ich abraten würde
Ich würde nicht mit Verträgen anfangen. Sie sind der Anwendungsfall, nach dem alle fragen, und das schlechteste erste Projekt: geringe Stückzahl, hohe Varianz, keine Rechenlogik zum Gegenprüfen, und Konsequenzen, die alles unterhalb einer menschlichen Prüfung untragbar machen. Die Ökonomie ist genau umgekehrt zur Rechnung, bei der die Menge hoch ist, das Schema gesetzlich feststeht und der Beleg sich selbst prüft. Als zweites Projekt sind Verträge sinnvoll, sobald Strecke und Prüfprozess stehen. Als erstes lehren sie Sie nichts, was günstig wäre.
Ich würde auch kein Modell als Eröffnungszug feinjustieren. Fine-Tuning ist eine denkbare Antwort auf „unsere Belege sind wirklich ungewöhnlich“, aber fast nie der Grund, warum eine Strecke schwächelt: Schlechte OCR, ein fehlender Belegtyp und ein Schema, das nicht zur ERP-Kontenlogik passt, erklären das Meiste — und alle drei sind billiger zu beheben. Ebenso wenig würde ich im ersten Monat unbeaufsichtigt buchen lassen, wie gut die Zahlen auch aussehen. Und ich würde keine Prüfmaske bauen, die dem Bearbeiter dreißig Felder zeigt, wenn drei strittig sind. Wer die ganze Rechnung erneut lesen muss, um die Maschine zu kontrollieren, hat durch die Maschine nichts gespart. Wo ein solcher Anwendungsfall gegenüber den anderen auf Ihrer Liste steht, ist eine eigene Frage — dafür ist die Übersicht der Anwendungsfälle da.
Wo Tippel ins Spiel kommt
Die Dokumentenverarbeitung ist der Anwendungsfall, zu dem ich am häufigsten als Einstieg rate — und der, bei dem ich am häufigsten für einen kleineren Zuschnitt plädiere, als der Kunde mitbringt: ein Belegtyp, ein Eingangskanal, Schattenbetrieb, eine ehrliche Dunkelverarbeitungsquote. Das liegt nah am KI-Readiness-Check — ein bezahltes, zeitlich begrenztes Stück Engineering an Ihren echten Belegen, das mit einer Zahl und einem Go/No-Go endet statt mit einer Demo, und dessen Gebühr bei Beauftragung angerechnet wird. On-Premise ist hier eine normale und keine exotische Antwort; Lieferantenrechnungen sind genau die Daten, die man ungern außer Haus gibt. Gebaut wird direkt von dem Engineer, der es zugeschnitten hat.
Wenn bei Ihnen ein Stapel Rechnungen, Bestellungen oder Lieferscheine liegt, den jemand von Hand abtippt, lohnt sich ein Gespräch. Melden Sie sich — und bringen Sie Ihre hässlichsten Scans mit.