ERP & Automatisierung
Vom Posteingang ins ERP: Anatomie einer Dokumenten-Pipeline
Dieser Artikel richtet sich an die, die es bauen oder verantworten müssen: IT-Leitung, ERP-Verantwortliche, Entwickler. Er beschreibt die Architektur einer Dokumenten-Pipeline — PDF-Beleg rein, validierter ERP-Datensatz raus — so konkret, wie es ohne Codebasis geht. Die Management-Perspektive liefert der Leitfaden zur Belegautomatisierung; hier geht es um das Wie.
Die zentrale Designaussage vorweg: Das Sprachmodell ist die kleinste Komponente des Systems. Wer „KI-Extraktion” als API-Call mit PDF im Prompt versteht, baut eine Demo. Produktionsreif wird das System durch alles, was um das Modell herumsteht — deterministisches Routing, Provenienz, Validierung, Eskalation und Feedback.
Drei Designprinzipien
1. Minimal vordeterminiert. Fest definiert sind nur das Zielschema (die Felder des ERP-Belegmodells) und universelle Invarianten (Arithmetik, Pflichtfelder). Alles Layout- und Absenderspezifische wird zur Laufzeit erkannt — keine Templates, keine Absender-Regeln. Jede absenderspezifische Sonderlocke, die man sich erspart, ist gesparte Wartung über die gesamte Lebensdauer.
2. Das Modell schreibt ab, es rechnet nicht. Das LLM überträgt ausschließlich Werte, die wörtlich im Dokument stehen. Abgeleitete Größen — Nettopreise, Zeilensummen, Prüfsummen — berechnet deterministischer Code. Sprachmodelle sind starke Leser und unzuverlässige Rechner; die Arbeitsteilung nutzt beide Eigenschaften.
3. Das Qualitätsziel ist „0 % unentdeckte Fehler”, nicht „100 % Genauigkeit”. Rohgenauigkeit von 100 % ist bei freien Layouts unerreichbar (warum, steht hier). Die Architektur ist deshalb darauf ausgelegt, jeden zweifelhaften Wert zu erkennen und auszuleiten — nicht darauf, Unfehlbarkeit zu behaupten.
Stufe 0 — Identität und Routing
Bevor irgendein Modell läuft, bekommt jede eingehende Datei eine Identität: ihren SHA-256-Hash. Gegen eine Unique-Spalte in der Ziel-Datenbank geprüft, erledigt das die Dubletten-Frage strukturell — dieselbe Bestellung, zweimal gemailt oder erneut weitergeleitet, wird als Dublette markiert, bevor Rechenzeit anfällt und bevor ein Doppel-Import droht.
Danach routet ein Datei-Router nach Eingangstyp: Bereits strukturierte Eingänge — CSV-Anhänge, echte E-Rechnungen (XRechnung, ZUGFeRD-XML) — werden deterministisch geparst und direkt aufs Zielschema gemappt. Kein LLM, keine Unsicherheit. Der KI-Pfad ist ausschließlich für das reserviert, was ihn braucht: unstrukturierte PDFs. Diese Weiche klingt trivial und ist eine der wirksamsten Entscheidungen der Architektur — sie hält den probabilistischen Anteil des Systems so klein wie möglich.
Stufe 1 — Parsing: Layout zu Markdown, mit Provenienz
Ein Layout-Parser (bewährt: Docling, Open Source) wandelt das PDF in strukturiertes Markdown — Tabellen als Tabellen, Lesereihenfolge aufgelöst, auf CPU in Sekunden. Bei born-digital erzeugten PDFs, dem Normalfall im B2B-Verkehr, bleibt OCR komplett aus: Der vorhandene Text-Layer wird direkt ausgewertet, was schneller und fehlerärmer ist als jeder Erkennungsschritt.
Das Markdown wird vollständig gespeichert — als Provenienz-Anker. Jeder später extrahierte Wert muss sich gegen diesen Rohtext belegen lassen; zusätzlich wird je Position die Original-Textzeile mitgeführt. Ohne diese Verankerung ist Grounding (Stufe 3) unmöglich und jede Fehlersuche Archäologie.
Was in realen Belegen auf den Parser wartet, unterschätzt man leicht. Vier wiederkehrende Fallen: Artikelbezeichnungen, die über drei Zeilen laufen (Artikelzeile, Größenzeile, EAN-Zeile — eine Position, drei Tabellenzeilen); Seitenumbrüche mitten in der Positionstabelle samt Übertragszeile, die wie eine Position aussieht, aber keine ist; zwei „Total”-Zeilen — mit und ohne Mehrwertsteuer — von denen genau eine ins Zielfeld gehört; und Schweizer Zahlenformate mit Apostroph als Tausendertrenner (1’234.56). Ein Parser, der Tabellenstruktur erhält, entschärft die Hälfte dieser Fälle; den Rest muss das Mapping mit präzisen Regeln abfangen.
Stufe 2 — Mapping: zwei Schemata, constrained Decoding, Regeln mit Begründung
Der Kern der Stufe ist eine bewusste Trennung in zwei Schemata mit verschiedenen Rollen:
- Das Extraktionsschema sieht das LLM. Es enthält ausschließlich Felder, die wörtlich im Beleg stehen — Kopfdaten, Positionen, je Position die Quellzeile. Jedes Feld ist nullable: Was nicht im Text steht, ist null, nicht geraten.
- Das Prüf- und Datenbankmodell sieht das LLM nie. Hier leben Decimal-Beträge, berechnete Felder, Konfidenz-Score und Status — vergeben von der Pipeline, niemals vom Modell.
Die Ausgabe wird per Constrained Decoding erzwungen: Eine aus dem Schema generierte Grammatik beschränkt die Token-Auswahl, das Modell kann kein ungültiges JSON erzeugen. Zwei Feinheiten aus der Praxis: Erstens garantiert die Grammatik nur Syntax, nie Werte — sie ersetzt keine einzige Prüfung. Zweitens sollte nur die finale Ausgabe constrained sein; wer einem Modell auch das Denken in Grammatik zwingt, verschlechtert die Ergebnisse (in der Literatur als Alignment-Tax bekannt).
Für den System-Prompt gilt eine einfache Disziplin: Jede Regel existiert wegen eines konkreten, beobachteten Fehlers. Typische Beispiele: „Gesamtsumme ist die Endsumme ohne Mehrwertsteuer — steht ‚Total excl. VAT’ im Text, nimm exakt diesen Wert” (weil das Modell sonst das Brutto-Total greift); „Zahlen als reine JSON-Zahl, Apostroph-Tausendertrenner entfernen”; „Datum roh übernehmen, nicht umformatieren” (Normalisierung macht deterministischer Code, der dabei Fehler werfen kann statt sie zu kaschieren). Prompts, die so entstehen, bleiben kurz, begründet und testbar — Prompt-Folklore hat in einer Pipeline nichts verloren.
Stufe 3 — Validierung: der Teil, der das Vertrauen erzeugt
Jetzt wird aus extrahiert „geprüft”. Drei Prüffamilien, alle deterministisch, alle in normalem, unit-testbarem Code:
- Arithmetik mit Decimal und expliziten Toleranzen. Menge × Einzelpreis, Rabatte eingerechnet, muss die Positionssumme ergeben; die Positionssummen die Belegsumme. Gerechnet wird mit Decimal (nie float), mit definierter Rundung und zwei Toleranzen: eine Rundungseinheit je Position, kumuliert etwas mehr auf Kopfebene — reale Belege runden je Zeile. Diese Invarianten machen die häufigste Fehlerklasse — Ziffernfehler in Zahlenfeldern — mathematisch sichtbar.
- Grounding gegen die Quelle. Jeder Wert muss sich im gespeicherten Rohtext wiederfinden; die je Position mitgeführte Quellzeile wird gegen das Original re-verankert (Fuzzy-Match auf den Rohtext, nicht Vertrauen in die Modell-Hypothese). Was nicht belegbar ist, gilt als nicht extrahiert. Das fängt Halluzinationen auch dort, wo keine Arithmetik greift.
- Stammdaten- und Konsistenzprüfung. Artikelnummern gegen den Artikelstamm (wohlgemerkt: die eigene Nummernwelt — Kundennummern des Absenders variieren und werden mitgeführt, aber nicht gegen den Stamm erzwungen), Partner gegen Stammdaten, Währung, Datumslogik, Vollständigkeit der Positionsanzahl.
Aus den Ergebnissen vergibt die Pipeline Score und Status — etwa: automatisch übernommen, Review nötig, fehlgeschlagen, Dublette. Wichtig: Self-Healing nur mit Beleg. Korrigiert das System einen Wert selbst (etwa über die Arithmetik), wird die Korrektur nur akzeptiert, wenn der korrigierte Wert im Quelltext belegbar ist — sonst geht der Fall an Menschen. Ein System, das eigene Fehler durch plausible Vermutungen „repariert”, ist gefährlicher als eines, das sie meldet.
Stufe 4 — Eskalation: Vision und Reasoning als Ausnahme, nicht als Default
Schlagen Prüfungen fehl, eskaliert die Pipeline gestuft — und erst jetzt kommen die schwereren Werkzeuge: Ein Vision-Modell liest Belege mit kaputtem oder fehlendem Text-Layer (Scans, Fotos, exotische PDF-Generatoren) direkt aus dem Bild. Ein Reasoning-Durchgang klärt mehrdeutige Fälle — erst frei denken, dann das Ergebnis separat ins Schema mappen.
Warum nicht gleich so? Weil beides im Standardpfad mehr schadet als nützt: Die Mapping-Aufgabe ist Abschreiben, kein Schlussfolgern — Reasoning auf Zahlenfeldern erhöht die Halluzinationsneigung, kostet ein Vielfaches an Latenz und verträgt sich schlecht mit Constrained Decoding. Vision ist für born-digital PDFs mit sauberem Text-Layer unnötig teuer und schlechter auditierbar als Text-Parsing. Eskalation ist der Ort für schwere Geschütze; der Standardpfad bleibt schlank, schnell und nachvollziehbar.
Stufe 5 — Mensch in der Schleife, der lernt
Die verbleibenden Fälle landen in einer Review-Oberfläche: Beleg links, extrahierte und geprüfte Daten rechts, Abweichungen markiert, Korrektur in Sekunden. Zwei Eigenschaften entscheiden über den Wert dieser Stufe: Erstens muss sie vorbefüllt sein — Review heißt prüfen, nicht erfassen. Zweitens fließt jede Korrektur als Beispiel zurück in die Pipeline (Few-Shot-Beispiele im Prompt, Erweiterung des Test-Sets) — die Review-Quote ist keine Konstante, sondern eine fallende Kurve.
Evaluation und Betrieb: ohne Gold-Set ist alles Anekdote
Gemessen wird gegen ein Gold-Set: reale Belege mit manuell festgelegtem Soll-Ergebnis, aufgebaut in zwei Wellen (≈10 Belege für die Pipeline-Logik, ≈100 für die Schwellen-Kalibrierung) — zwingend inklusive zurückgehaltener Absender, die beim Tuning nie gesehen wurden, denn die eigentliche Frage ist die Generalisierung auf Unbekanntes. Sinnvolle Metriken: Feld-Genauigkeit, zeilenweise Line-Item-Genauigkeit (der Schwachpunkt jeder Extraktion), Dokument-Exact-Match und die Straight-Through-Rate. Und ein Test, der nie fehlen darf: Ein bewusst eingebauter Fehler muss von den Prüfungen gefangen werden — eine Validierung, die nie anschlägt, ist Dekoration.
Im Betrieb wird Qualität pro Absender beobachtet, aber nicht pro Absender geroutet: Das Routing entscheidet allein über Signale (Konfidenz, Validierungs- und Grounding-Ergebnis), Absender-Labels machen im Monitoring sichtbar, ob jemand systematisch schlechter läuft. So bleibt das System template-frei, ohne blind zu sein.
Deployment-seitig ist das Ganze unspektakulär — und das ist das Kompliment: Inference-Server (vLLM oder Ollama) mit dem Mapping-Modell, Worker für Parsing/Pipeline/Validierung, Queue, Review-UI; alles als Docker-Compose, GPU-Durchreichung via NVIDIA Container Toolkit. Auf Hardware der DGX-Spark-Klasse (128 GB Unified Memory) bleiben Mapping- und Vision-Modell gleichzeitig resident — Eskalationen warten nicht auf Modell-Swaps. Die Hardware- und Souveränitätsfragen im Detail sprengen diesen Artikel.
Fazit
Eine produktionsreife Dokumenten-Pipeline ist zu 20 Prozent Modell und zu 80 Prozent Systemarchitektur: deterministisches Routing, Provenienz ab dem ersten Byte, ein enges Extraktionsschema, Validierung mit Mathematik und Quellen-Grounding, Eskalation nach Signalen und ein Review-Pfad, der lernt. Nichts daran ist Magie — es ist solides Software-Engineering um eine probabilistische Komponente herum. Genau deshalb funktioniert es: Das Modell darf sich irren, das System merkt es.
kitun baut solche Pipelines als maßgeschneiderte ERP-Module — on-premise, mit Open-Weights-Modellen, Gold-Set-Evaluation und ohne Stückkosten pro Beleg. Architektur-Fragen zum eigenen Belegeingang: gern im 20-minütigen Gespräch.