Dokumenten-Pipeline

Die Architektur

Die Pipeline läuft in zwei Stufen über einem gemeinsamen Dateisystem, wobei der Schnitt der Arbeit folgt und nicht der Technik. Stufe 1 ist der Brieföffner: Sie öffnet, liest und sortiert die eingehende Post, damit nichts liegen bleibt, an dem eine Frist hängt. Stufe 2 ist die Vorstufe zur Buchhaltung: Sie macht aus den täglichen Geschäftsdokumenten abgeglichene Daten, die man auch abfragen kann.

Der ganze Entwurf hängt an einer Naht. Ein Dokument zu lesen ist unscharf und menschlich, dafür ist das Modell da. Zu entscheiden, was das Dokument ist und wohin es gehört, lässt sich dagegen als Regel exakt aufschreiben, und diese Regeln stehen in Code, sodass das Modell nie raten muss.

Stufe 1, der Brieföffner

Am Anfang steht ein überwachter Ordner. Jedes PDF bekommt über seinen Content-Hash eine Identität und wird in ein Pydantic-Schema mit rund 24 Feldern gelesen. Dahinter liegt eine Abstraktion, die einen Hauptanbieter betreibt und bei Fehlern automatisch auf einen zweiten ausweicht.

Wohin ein Dokument gehört, zum Unternehmen, zu einem Mietobjekt oder zum Haushalt, und ob es geschäftsrelevant ist, entscheidet deterministisches Python und nie das Modell. Haushaltsunterlagen wandern in eine recipient/year/category/-Hierarchie und nach Notion.

Gescannt wird weiterhin von Hand, weshalb gelegentlich ein Geschäftsdokument im falschen Eingangsordner landet. Dieselbe Klassifizierung fängt es dort ab und schickt es an Stufe 2 weiter, sodass aus einem verlegten Scan keine Lücke in den Büchern wird.

Die Leseschicht steht in ihrer zweiten Bauform. Angefangen hat sie als lokales Tesseract-OCR, das ein allgemeines Sprachmodell fütterte. Heute nimmt ein dokumenten-natives Modell (Mistral OCR) das PDF direkt entgegen und liefert layoutbewusstes Markdown samt den typisierten Feldern in einem einzigen Aufruf. Ungecachtes Volumen läuft gebündelt als Batch-Job zum halben Seitenpreis. Dass dieser Wechsel nur eine Konfiguration kostete und keinen Umbau, ist das Verdienst der Anbieterabstraktion.

Die Betriebsschicht

Was aus einem Skript ein System macht, ist nicht das Modell, sondern das, was darum herum liegt.

Der Extraktionscache ist über Schema- und Prompt-Hash versioniert, sodass eine Prompt-Änderung genau die Extraktionen entwertet, die sie betrifft; nur die werden zum Batch-Preis neu gerechnet.

Einen erneut gescannten Brief erkennt das System an einem inhaltlichen Fingerabdruck aus Absender, Datum, Betrag und Referenznummer, nicht an der Byte-Gleichheit, und legt ihn in einen Duplikatordner statt ein zweites Mal ins Archiv.

Jedes Dokument trägt eine UUID in den Metadaten des PDFs, die es über Dateisystem, Notion-Index und ein selbst gehostetes Paperless-ngx-Volltextarchiv hinweg begleitet.

Schwache Extraktionen werden nie stillschweigend abgelegt: Sie bekommen ein Prüf-Flag, ein Mensch korrigiert sie in der Archiv-Oberfläche, und die Korrektur fließt zurück in Cache und Index. Harte Fehlschläge gehen in Quarantäne.

Die Taxonomie wuchs von neun auf fünfzehn Dokumenttypen, darunter Steuerbescheide, Gehaltsabrechnungen, Kontoauszüge und Bescheinigungen. Jede Extraktion wird mit Steuerrelevanz und Kontext getaggt, denn in einem deutschen Haushalt ist die Auffindbarkeit zur Steuerzeit der halbe Sinn des Ablegens.

Stufe 2, die Vorstufe zur Buchhaltung

Hier werden die rund fünfzehn Geschäftsdokumente pro Tag zu Buchhaltungsdaten. Ein Keyword-Klassifikator sortiert jedes zunächst in einen von vier Typen mit je eigenem typisiertem Schema: Rechnung, Tagesabschluss, Artikelbericht oder Kartenabrechnung.

Erst danach entscheidet ein kostenbewusster Router, wie gelesen wird. Die Ergebnisse liegen zlib-komprimiert in SQLite, archiviert nach year/month/type.

Jedes Dokument geht an das günstigste Werkzeug, das es tatsächlich lesen kann. Für das teure wird nur gezahlt, wenn es sich lohnt.

Zum Schluss gleicht die Pipeline die Positionen gegen einen Lieferantenartikelkatalog in Supabase ab, sodass dasselbe Produkt über Anbieter hinweg zusammenfindet, egal wie eine einzelne Rechnung es nennt. Erst dieser Abgleich macht aus rohen Extraktionen vergleichbare Daten und beantwortet die artikelgenaue Frage auf Abruf statt halbjährlich.

Entscheidungen und Abwägungen

Sprachmodelle lesen Fakten, Code trifft Entscheidungen. Das Modell liest, regelbasiertes Python klassifiziert nach Geschäftskontext und leitet weiter. Das Modell zu fragen, zu welcher Einheit eine Rechnung gehört, hieße, es raten zu lassen, und ein Fehlgriff schlägt hier bis in die steuerliche Behandlung durch, während ein Tippfehler das Harmlosere wäre. Also wird es nicht gefragt.

Rückfall auch bei Validierungsfehlern, nicht nur bei API-Fehlern. Ein Anbieter kann eine wohlgeformte, selbstbewusste Antwort liefern, die trotzdem nicht zum Schema passt, und genau das ist der gefährliche Fall, weil eine plausible Fehlextraktion unbemerkt in den Büchern landet. Deshalb wird jedes Ergebnis validiert, bevor es angenommen wird, und ein Validierungsfehler fällt auf einen anderen Anbieter durch. Bezahlt wird das mit Latenz und den Kosten eines zweiten Aufrufs.

Die Anbietermigration war eine Entscheidung, kein Automatismus. Den Ausschlag gab die Genauigkeit pro Nacharbeit und nicht der Listenpreis, denn eine günstigere Extraktion, die einen Nachmittag Datenbereinigung nach sich zieht, ist am Ende teurer.

Über die vierte Migration hat ein Prüfstand entschieden. Eine frühere Fassung dieser Studie räumte ein, dass die Genauigkeit im Alltag hoch, aber ungemessen war. Aus der Lücke wurde ein Arbeitspaket: ein von Hand gelabelter Referenzkorpus und eine Bewertung Feld für Feld über Empfänger, Typ, Datum, Betrag und Referenznummer.

Hält man dabei das Parsing konstant und tauscht nur den Extraktor, zeigt sich, dass der Extraktionsschritt Massenware ist. Ein günstiges allgemeines Modell hielt auf identischem Markdown mit dem spezialisierten Dienst mit, zu etwa einem Zweihundertstel der Kosten. Der eigentliche Wert des bisherigen Anbieters lag damit in seinem Parsing.

Über die ganze Kette zog das dokumenten-native Modell dann gleich oder vorbei, und ein Korpuslauf über alle vier Dokumenttypen entschied die Sache mit nahezu perfekter Übereinstimmung bei Daten und Beträgen.

Eine Abweichung von der Referenz ist zunächst ein Befund. Jede Abweichung zwischen dem neuen Kandidaten und dem bisherigen Anbieter wurde von Hand angesehen statt weggemittelt. Etliche gingen dabei auf das Konto des bisherigen Anbieters, darunter Kassenberichte, die sein eigener Bestand als Rechnungen geführt hatte. Entschieden hat am Ende das Protokoll der Abweichungen und nicht die Übereinstimmungsquote.

Batch statt Sofortverarbeitung, mit einem lokalen Pfad in Reserve. Post ist nicht zeitkritisch, weshalb ungecachte PDFs als Batch zum halben Seitenpreis laufen, mit Minuten Latenz und gelegentlich einer Stunde; fällt das Batching aus, greifen automatisch synchrone Aufrufe.

Für Dokumente, die das Haus besser nicht verlassen, liegt ein vollständig lokaler Pfad vermessen und einsatzbereit bereit. Docling parst brauchbar in einer halben bis wenigen Minuten pro Dokument auf der CPU, während die GPU-gebundenen Alternativen Marker und MinerU über eine halbe Stunde für ein einzelnes PDF brauchten.

Was schiefging

Der Prüfstand sollte eine saubere Genauigkeitstabelle liefern. Geliefert hat er die Antwort dann auf dem Umweg über seine eigenen Fehlschläge.

Der spezialisierte OCR-Dienst gab rohe beschriftete Boxen zurück, die auf das Zielschema nicht passten, sodass ohne eine eigene Normalisierungsschicht darüber jede Position unabgeglichen blieb. In der Produktion hieß das, 10.842 Positionen aus rund 1.800 Dokumenten nachzuziehen, die der alte Dienst zwar als Text erfasst, aber nie strukturiert hatte, dazu rund 70 Schreibvarianten von Händlernamen zusammenzuführen.

Das allgemeine Modell war brauchbar, bei schlechten Scans aber nicht fehlerfrei: ein Datum um ein Jahr falsch gelesen, ein Anbietername zu OCR-Rauschen verstümmelt. Auch die Schema-Garantie der Erfassung ist ehrlich gemeint, aber unvollkommen, denn die Validierung treibt den Rückfall zwar an der Lesegrenze, das schließlich geschriebene Dict läuft danach jedoch durch eine leichtere Konvertierungsschicht. An der Schreibgrenze ist die Garantie damit schwächer.

Der Erfassungsprüfstand von 2026 brach auf lehrreichere Weise: Auf etwa der Hälfte des Korpus gab das dokumenten-native Modell ein leeres {} zurück. Ursache war ein Schema, in dem jedes Feld Optional stand, was der Structured-Output-Modus als Erlaubnis liest, gar nichts zu liefern. Die Kernfelder auf Pflicht zu setzen hat es behoben, und dieses Vertragsdetail steht in keiner Dokumentation.

Danach ist der Prompt an je einer beobachteten Fehllesung gewachsen. Auf einem Kassenbon gab das Modell das gegebene Bargeld statt des zu zahlenden Betrags zurück, auf B2B-Rechnungen setzte es den Käufer ins Absenderfeld statt des Ausstellers im Briefkopf. Jede Regel im Prompt führt auf eine konkrete Zeile im Abweichungsprotokoll zurück.

Auch die Referenzdaten hielten nicht. Das als Referenz genutzte Archiv enthielt falsch benannte Dateien, etwa einen Supermarkt-Bon, der als Artikelbericht abgelegt war, und die Auswertungs-CSV zerbrach an einem nicht maskierten Komma in einem Dateinamen. Weil der Bestand des bisherigen Anbieters selbst Fehlklassifizierungen enthielt, bestrafte die rohe Übereinstimmungsquote den Kandidaten am Ende dafür, recht zu haben.

Zwei Kleinigkeiten aus dem Betrieb blieben hängen: Batch-Jobs antworteten mit HTTP 402, bis in der Anbieterkonsole die Abrechnung aktiviert war. Das Batch-Ergebnis wiederum kommt als Streaming-Antwort, die man erst lesen muss, damit die Nutzlast überhaupt existiert.

Der letzte Bruch war kein technischer. Haushaltspost als Aufgabe mit Frist in Notion abzulegen funktionierte genau wie entworfen. Im August 2026 standen in dieser Aufgabendatenbank trotzdem 48 offene Einträge, jeder einzelne überfällig, und kein einziger davon war dort falsch gelandet.

Die Diagnose heißt Holprinzip statt Bringprinzip. Eine Frist in einer Datenbank existiert nur für den, der die Datenbank öffnet, und genau dieses Öffnen war der eine Schritt, den das System niemandem abnehmen konnte. Nebenbei war die Schriftverkehr-Datenbank zu einem zweiten Archiv neben dem Volltextarchiv geworden, was Doppelung ist und keine Redundanz.

Deshalb wird die Aufgaben-Ebene abgebaut und nicht repariert: Fristen werden künftig dorthin geschoben, wo der Blick ohnehin liegt, weil eine Datenbank, die man eigens aufsuchen muss, genau das nicht leistet. Das Archiv behält dabei einen Ort. Das ist der nützlichere Befund dieser Studie, denn ein System, das niemand aufsucht, steht am Ende genauso da wie eines, das nie gebaut wurde, und keine Genauigkeitszahl fängt das auf.