Dokumente mit AI und Structured Outputs auslesen

Hundert Lieferanten, hundert Layouts

Dass eine AI die Felder einer Rechnung findet, ist heute der einfache Teil. Schwieriger ist, aus ihrer Antwort etwas zu machen, auf das eine Zahlung folgen darf. Dort entscheidet sich, ob aus einer überzeugenden Demo ein Prozess wird.

Inhaltlich sind Kreditorenrechnungen immer gleich: Es geht um einen Betrag, den jemand von jemandem will. Formal sind sie immer anders. Jeder Lieferant hat sein eigenes Layout, ein Teil kommt digital, ein grosser Teil eingescannt, manchmal mit Stempel oder handschriftlicher Kontierung darauf.

Ohne Automatisierung öffnet jemand das PDF, liest Lieferant, Rechnungsnummer, Datum, Betrag und Zahlungsangaben heraus und tippt sie in die Buchhaltung. Ein paar Minuten pro Rechnung, jeden Tag. Die Arbeit ist nicht schwierig, aber monoton, und monotone Arbeit erzeugt Fehler. Zudem bringt sie wenig Mehrwert.

Warum die naheliegenden Wege nicht tragen

Der klassische Weg ist Texterkennung mit Regeln. Das Problem ist nicht die Texterkennung, sondern die Bedeutung. Auf einer Rechnung stehen fünf Beträge, drei Datumsangaben und zwei Adressen. Welcher Betrag am Ende zu zahlen ist, ergibt sich nur aus dem Layout, und der Kontierungsstempel steht nicht immer an derselben Stelle. Regeln dafür muss man für jeden Lieferanten einzeln erfassen, bevor auch nur eine Rechnung automatisch durchläuft, und bei jedem neuen Lieferanten von vorn. Dieser Ansatz wird umso teurer, je vielfältiger der Eingang ist, und genau dann will man Automatisierung.

Der zweite naheliegende Weg ist, eine AI zu fragen. Das löst das Bedeutungsproblem sofort, die Antworten sind erstaunlich gut. Nur ist die Antwort nicht für einen Menschen gedacht, sondern für eine Maschine, und die braucht ein verlässliches Format. Beim ersten Aufruf kommt ein sauberes Datenobjekt zurück, beim zweiten dasselbe in einen Fliesstext verpackt, beim dritten heisst ein Feld plötzlich anders. Man kann das nachträglich glattbügeln und baut damit genau die Regelsammlung, der man entkommen wollte.

Structured Outputs: das Schema ist der eigentliche Auftrag

Structured Outputs packen das Integrations-Problem an der Wurzel. Statt die AI im Prompt um ein Format zu bitten, gibt man ihr ein Schema vor: eine verbindliche Beschreibung der erwarteten Datenstruktur. Etwas anderes als eine schemakonforme Antwort kann sie gar nicht mehr produzieren: Abweichende Antworten werden nicht verworfen, sie entstehen gar nicht erst.

Das alleine ist ein grosser Mehrwert. Aber überrascht hat mich etwas anderes: Das Schema steuert die Extraktion stärker als jede Prompt-Formulierung. Am Ende sind fast alle fachlichen Anweisungen dorthin gewandert. Das nachfolgende Beispiel zeigt, wie unspektakulär, aber dafür wirksam das ist:

{
  "rechnungsdatum": {
    "type": ["string", "null"],
    "description": "Format YYYY-MM-DD. Nicht mit Lieferdatum oder Fälligkeit verwechseln."
  },
  "brutto": {
    "type": "number",
    "description": "Zu zahlender Endbetrag. Nicht das Zwischentotal, nicht eine einzelne Position. Inkl. Mehrwertsteuer."
  },
  "waehrung": { "type": "string", "enum": ["CHF", "EUR", "USD", "GBP", "andere"] }
}

Drei Kniffe stecken in diesen wenigen Zeilen.

Am wichtigsten ist die Erlaubnis, ein Feld leer zu lassen. Muss ein Feld zwingend gefüllt werden und das Dokument enthält den Wert nicht, dann erfindet die AI einen. Nicht aus Bosheit, sondern weil die Vorgabe sie dazu zwingt. Eine erfundene IBAN ist der schlimmste denkbare Fall in einem Zahlungsprozess. Erst mit erlaubtem Leerwert entsteht der Unterschied zwischen «steht nicht im Dokument» und «steht falsch im Dokument».

Dazu die geschlossene Auswahl: Ein Wert ausserhalb der Liste lässt sich gar nicht mehr darstellen, und das Aufräumen im Nachhinein entfällt. Der Ausweichwert «andere» gehört trotzdem dazu, denn sonst zwingt die Liste die AI bei einer exotischen Währung wieder zum Erfinden. Mit ihm landet die Rechnung stattdessen bei einem Menschen.

Der Satz «Nicht mit Lieferdatum oder Fälligkeit verwechseln» ist Fachwissen aus der Kreditorenbuchhaltung. Er steht jetzt im Schema, versioniert und lesbar, an einer Stelle statt in den Köpfen von drei Leuten.

Ein vierter steht nicht im Auszug: Wir lassen zu jedem Wert das wörtliche Zitat aus dem Dokument mitliefern, samt Seitenzahl. Wer kontrolliert, muss die Rechnung nicht neu lesen, sondern nur Zitat und Wert vergleichen.

Der Wert entsteht nach der Extraktion

Ein sauberes Datenobjekt bringt für sich noch keinen Nutzen. Der Nutzen liegt in den Schritten, die darauf aufbauen und die vorher so einfach nicht umsetzbar waren.

Drei davon laufen, bevor ein Mensch die Rechnung sieht. Netto plus Mehrwertsteuer muss Brutto ergeben: Diese eine Regel findet den Grossteil der Lesefehler, welche auch die AI macht, bevor ein Mensch hinschaut, und sie kostet nichts. Das System gleicht den Lieferanten mit den Kreditoren-Stammdaten ab und prüft die IBAN gegen die hinterlegte. Und Lieferant plus Rechnungsnummer verrät doppelt eingereichte Rechnungen, die häufiger sind, als man denkt.

Die IBAN-Prüfung ist der Punkt, an dem die Automatisierung Geld verdient statt nur Zeit zu sparen. Weicht die IBAN von den Stammdaten ab, ist das kein Extraktionsfehler, den man wegklickt. Rechnungsbetrug funktioniert genau so. Eine abweichende IBAN führt darum immer zur manuellen Prüfung, egal wie korrekt die Extraktion aussieht.

Erst danach kommt ein Buchungsvorschlag mit Konto und Kostenstelle, und der stammt bewusst nicht von der AI. Die AI liest, was auf dem Papier steht. Was daraus für eine Buchung folgt, entscheidet die eigene Logik, denn dieser Teil muss nachvollziehbar bleiben. Die Reihenfolge ist der ganze Trick: prüfen, dann anreichern, dann vorlegen. Wer die Extraktion direkt an den ERP-Import hängt, hat eine sehr effiziente Maschine für falsche Buchungen gebaut.

Der Mensch gibt frei

Das System liest und prüft, ein Mensch gibt frei. Das ist keine Notlösung wegen schwacher Technik, denn schemakonform heisst nicht korrekt. Die Technik garantiert die Form der Antwort, nicht ihren Inhalt: Ein sauberes Datenobjekt mit dem falschen Betrag sieht fehlerlos aus, und am Ende dieses Prozesses steht eine Zahlung.

Der Gewinn liegt nicht im Wegfall der Kontrolle, sondern in ihrer Verkürzung. Die Maske ist vorbefüllt, jedes Feld zeigt seine Belegstelle, leere Felder und Befunde sind markiert. Aus Abtippen wird Bestätigen.

Vorbefüllte Prüfmaske: Zu jedem Feld ist die Textstelle sichtbar, aus der der Wert stammt

Fazit

Structured Outputs leisten zwei Dinge. Sie machen die Ausgabe der AI zu einer Schnittstelle, auf der man Software bauen kann. Und sie verlagern das Fachwissen an einen Ort, an dem es lesbar und versionierbar ist.

Was sie nicht leisten, ist die Verantwortung für die Richtigkeit der Daten. Die bleibt beim Prozess und am Ende bei einem Menschen, der freigibt. Aus mehreren Minuten Erfassung wird eine kurze Bestätigung. Ich halte das für das ehrlichere Ziel, auch wenn «vollautomatisch» in einer Präsentation besser klingt.