Dokumenten-Pipeline

Das geschäftliche Problem

Ein kleines Unternehmen, ein paar Mietobjekte und der Haushalt dahinter erzeugen zwei Papierströme. Der erste ist eingehende Post — Rechnungen, Behördenbriefe, Mahnungen, Steuer- und Immobilienunterlagen —, die geöffnet, verstanden, klassifiziert, abgelegt und vor Ablauf einer Frist bearbeitet werden muss. Von Hand waren das 5–10 Stunden im Monat, und die Finanzdokumente waren der unerbittliche Teil: eine übersehene Rechnung ist ein verpasster Fälligkeitstermin.

Der zweite Strom ist schwerer und operativ: die täglichen Geschäftsdokumente — Kassen-Tagesabschlüsse, artikelgenaue Verkaufsberichte, Kartenabrechnungs-Übersichten, Lieferantenrechnungen. Etwa fünfzehn davon kommen jeden Tag an. Jedes wurde früher von Hand Zeile für Zeile in Tabellen getippt, und dieser Aufwand war hoch genug, dass die Zahlen nur alle sechs Monate durchgearbeitet wurden. Neue Artikel wurden aus dem Bauch heraus aufgenommen — zwei Quartale konnten vergehen, bevor die Zahlen zeigten, ob einer ein Verkaufsschlager oder Ladenhüter war. Für ein kleines Unternehmen ist diese Verzögerung teuer: Es ist Kapital, das im falschen Bestand steckt und Monate zu spät entdeckt wird.

Eine Zahl, die man vertippt, ist ein Fehler, den man Monate später findet. Ein Verkaufsbericht, den man nie tippt, ist eine Entscheidung, die man blind trifft.

Das Lesen ist unscharf und menschlich; das Klassifizieren, Ablegen und Routen sind Regeln, die man exakt benennen kann. Das System ist auf dieser Nahtstelle gebaut — eine breite Triage-Eingangstür für die Post und eine hochpräzise Extraktions-Engine für die täglichen Geschäftsdokumente dahinter.

Die Architektur

Die Pipeline läuft in zwei Stufen über ein gemeinsames Dateisystem. Stufe 1 ist der Brieföffner: Sie öffnet, liest und triagiert eingehende Post. Stufe 2 — Landing AI, die Vorstufe zur Buchhaltung — verwandelt die täglichen Geschäftsdokumente in buchhaltungsreife, abgeglichene Daten.

Stufe 1 — der Brieföffner. Ein überwachter Ordner; jedes PDF wird über seinen Content-Hash identifiziert und in ein ~24-Felder-Pydantic-Schema gelesen — hinter einer Multi-Backend-Provider-Abstraktion, die einen Primär-Provider mit einem automatischen Fallback betreibt. Deterministisches Python — nie das Modell — entscheidet, zu welchem Kontext ein Dokument gehört (das Unternehmen, ein Mietobjekt, der Haushalt) und ob es geschäftsrelevant ist. Haushalts- und sonstige Unterlagen werden in einer recipient/year/category/-Hierarchie abgelegt und nach Notion synchronisiert. Stufe 1 ist überwiegend Post, aber das Scannen ist menschlich: gelegentlich landet ein Geschäftsdokument im falschen Eingangsordner. Dieselbe Inhalts-Klassifizierung fängt es ab und leitet es an Stufe 2 um, statt es falsch abzulegen, sodass ein verlegter Scan nicht zu einem fehlenden Eintrag in den Büchern wird.

Die Leseschicht in Stufe 1 ist in ihrer zweiten Architektur. Sie begann als lokales Tesseract-OCR, das ein allgemeines LLM fütterte; heute nimmt ein dokumenten-natives Parse-Extract-Modell (Mistral OCR) das PDF direkt entgegen und liefert layoutbewusstes Markdown plus die typisierten Felder in einem Aufruf — ungecachtes Volumen gebündelt in asynchrone Batch-Jobs zum halben Seitenpreis. Die Provider-Abstraktion ist es, die diesen Wechsel zu einer Konfigurationsänderung statt einem Umbau machte.

Die Betriebsschicht. Was die Iteration von 2026 um das Modell herum ergänzt hat, ist der Teil, der aus einem Skript ein System macht. Der Extraktions-Cache ist über Schema- und Prompt-Hash versioniert, sodass eine Prompt-Änderung genau die Extraktionen invalidiert, die sie betrifft — neu gerechnet zum Batch-Preis. Ein erneut gescannter Brief wird über einen Inhalts-Fingerabdruck (Absender, Datum, Betrag, Referenznummer) statt über Byte-Identität erkannt und in einen Duplikate-Ordner umgeleitet, statt doppelt abgelegt zu werden. Jedes Dokument trägt eine UUID, eingebettet in die Metadaten des PDFs selbst, die es über Dateisystem, Notion-Index und ein selbst gehostetes Paperless-ngx-Volltextarchiv hinweg begleitet. Degradierte Extraktionen werden nie stillschweigend abgelegt: Sie tragen ein Prüf-Flag, werden von einem Menschen in der Archiv-Oberfläche korrigiert, 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 — Steuerbescheide, Gehaltsabrechnungen, Kontoauszüge, Bescheinigungen —, jede Extraktion mit Steuerrelevanz und -kontext getaggt, denn in einem deutschen Haushalt ist Auffindbarkeit zur Steuerzeit der halbe Sinn des Ablegens.

Stufe 2 — die Buchhaltungs-Vorstufe. Hier werden die rund fünfzehn Geschäftsdokumente pro Tag zu Buchhaltungsdaten. Jedes wird zuerst von einem Keyword-Scoring-Klassifikator in einen von vier Dokumenttypen sortiert — Rechnung, Tagesabschluss, Artikelbericht, Kartenabrechnung —, jeder mit eigenem typisiertem Schema. Ein kostenbewusster dreistufiger Router entscheidet dann, wie es gelesen wird, und die Ergebnisse werden zlib-komprimiert in SQLite gespeichert, archiviert nach year/month/type.

Leiten Sie jedes Dokument an das günstigste Werkzeug, das es tatsächlich lesen kann — und zahlen Sie für das teure nur, wenn es sich lohnt.

Abgleich. Extrahierte Positionen werden gegen einen Lieferanten-Artikelkatalog (in Supabase) abgeglichen, sodass dasselbe Produkt über Anbieter hinweg zusammenfindet, wie auch immer eine bestimmte Rechnung es nennt — so werden aus rohen Extraktionen vergleichbare, abfragbare Daten statt unverbundener Zeilen. Dieser Abgleich macht artikelgenaue Auswertung auf Abruf beantwortbar, statt nur alle sechs Monate.

Entscheidungen & Abwägungen

LLMs extrahieren Fakten; deterministischer Code trifft Entscheidungen. Das Modell liest; regelbasiertes Python klassifiziert nach Geschäftskontext und routet. Das Modell zu fragen, zu welcher Entität eine Rechnung gehört, hieße, es raten zu lassen — also tut es das nie.

Fallback bei Validierungsfehler, nicht nur bei API-Fehlern. Ein Provider kann eine selbstbewusste, wohlgeformte Antwort liefern, die trotzdem nicht zum Schema passt — der gefährliche Fall, denn eine plausible-aber-falsche Extraktion segelt in die Bücher. Daher wird ein Ergebnis validiert, bevor es akzeptiert wird, und ein Validierungsfehler fällt zu einem anderen Provider durch. Die Abwägung sind Latenz und Kosten eines zweiten Aufrufs, erkauft für garantierte Struktur.

Die Provider-Migration war eine Entscheidung, kein Automatismus. Entscheidend war nicht der Schlagzeilen-Preis, sondern Genauigkeit-pro-Nacharbeit: eine günstigere Extraktion, die einen Nachmittag Datenbereinigung braucht, ist nicht günstiger.

Die vierte Migration wurde durch einen Prüfstand verdient, nicht durch ein Bauchgefühl. Eine frühere Fassung dieser Studie räumte ein, dass die Genauigkeit in der Praxis hoch, aber ungemessen war. Diese Lücke wurde zur Arbeit: ein von Hand gelabelter Ground-Truth-Korpus und feldgenaues Scoring — Empfänger, Typ, Datum, Betrag, Referenznummer — verglichen die Kandidaten Schicht für Schicht. Das Parsing konstant zu halten und nur den Extraktor zu tauschen zeigte, dass der Extraktionsschritt Massenware ist: Ein günstiges allgemeines LLM hielt auf identischem Markdown mit dem spezialisierten Dienst mit, zu etwa 1/200 der Kosten — was den eigentlichen Wert des Incumbents in seinem Parsing verortete. Das dokumenten-native Modell hielt dann Ende-zu-Ende mit oder schlug ihn, und ein Korpuslauf über alle vier Geschäftsdokumenttypen entschied es mit nahezu perfekter Übereinstimmung bei Daten und Beträgen.

Abweichung von der Referenz ist Evidenz, kein Fehler. Jede Divergenz zwischen Herausforderer und Incumbent wurde von Hand geprüft statt weggemittelt — und etliche gingen auf das Konto des Incumbents, darunter Kassenberichte, die sein eigener Bestand als Rechnungen abgelegt hatte. Die Migration wurde auf dem Disagreement-Log entschieden, nicht auf der Schlagzeilen-Übereinstimmungsrate.

Batch statt Sync, und ein lokaler Pfad in Reserve. Post ist nicht zeitkritisch, also werden ungecachte PDFs in asynchrone Batch-Jobs zum halben Seitenpreis gebündelt — Minuten Latenz, gelegentlich eine Stunde —, mit automatischem Rückfall auf synchrone Aufrufe, wenn Batching nicht verfügbar ist. Für Dokumente, die das Haus wohl gar nicht verlassen sollten, wurde ein vollständig lokaler zweistufiger Pfad gebenchmarkt und als einsatzbereite Option zurückgelegt: Docling parst akzeptabel in einer halben bis wenigen Minuten pro Dokument auf CPU, während die GPU-gebundenen Alternativen (Marker, MinerU) über eine halbe Stunde für ein einzelnes PDF brauchten.

Was gebrochen ist

Der Migrations-Benchmark sollte eine saubere Genauigkeits-Tabelle liefern; er lieferte die Antwort stattdessen durch Scheitern. Der spezialisierte OCR-Dienst gab rohe beschriftete Boxen zurück, die überhaupt nicht auf das Ziel-Schema abbildeten — jede Position kam ohne eine eigene Normalisierungsschicht obendrauf unabgeglichen zurück. In der Produktion bedeutete das ein Backfill, das 10.842 Positionen aus ~1.800 Dokumenten neu extrahierte, die der alte Dienst als Text erfasst, aber nie strukturiert hatte, plus ~70 Schreibvarianten von Händlernamen zum Abgleichen. Das allgemeine LLM war brauchbar, aber bei schlechten Scans nicht fehlerfrei — ein Datum ein Jahr falsch gelesen, ein Anbieter zu OCR-Rauschen verstümmelt. Und die Schema-Garantie der Erfassung ist ehrlich-aber-unvollkommen: Die Validierung treibt den Fallback an der Lesegrenze, aber das schließlich geschriebene Dict durchläuft eine leichtere Coercion-Schicht, sodass die Garantie an der Schreibgrenze schwächer ist.

Der Erfassungs-Benchmark von 2026 brach auf lehrreichere Weise. Das dokumenten-native Modell gab auf etwa der Hälfte des Korpus ein leeres {} zurück; die Ursache war ein Schema, in dem jedes Feld Optional war — was der Structured-Output-Modus des Modells als Erlaubnis liest, nichts zurückzugeben. Die Kernfelder auf Pflichtfelder umzustellen behob es — ein Vertragsdetail, das keine Dokumentation nennt. Der Prompt härtete sich dann eine beobachtete Fehllesung nach der anderen: Auf einem Kassenbon gab das Modell das gegebene Bargeld statt des tatsächlich zu zahlenden Betrags zurück; auf B2B-Rechnungen setzte es den Käufer ins Absenderfeld statt des Ausstellers auf dem Briefkopf. Jede Regel im Prompt führt auf eine konkrete Zeile im Disagreement-Log zurück.

Auch die Referenzdaten brachen. Das als Ground Truth genutzte Archiv enthielt falsch benannte Dateien — ein Supermarkt-Bon, abgelegt als Artikelbericht —, und die Benchmark-CSV zerbrach an einem nicht maskierten Komma in einem Dateinamen. Selbst der eigene Bestand des Incumbents enthielt Fehlklassifizierungen, sodass rohe Übereinstimmung den Herausforderer dafür bestrafte, recht zu haben. Die operativen Fußnoten: Batch-Jobs antworteten mit HTTP 402, bis das Billing in der Provider-Konsole aktiviert war, und das Batch-Ergebnis kommt als Streaming-Response, die erst gelesen werden muss, bevor die Nutzlast existiert.

Das Ergebnis

Im Einsatz seit 2023 über mehrere Versionen, mit dem Wechsel auf Landing AI Ende 2025 und der Umstellung der Erfassungs-Leseschicht auf Mistral OCR Mitte 2026. Die Extraktions-Engine läuft über ~3.500 Rechnungen und ~15.700 Positionen, die meisten kostenlos lokal geparst und nur die schwierigen paar Hundert an das bezahlte Modell geschickt, zu jeweils rund 0,14 €; die Erfassung liest inzwischen für $0.002 pro Seite im Batch — für einen Monat Post Cents statt Euros.

Zwei Lasten fielen weg. Die Posteingangs-Erfassung ersetzte 5–10 Stunden im Monat Öffnen, Sortieren und Ablegen durch strukturierte, fristenüberwachte Datensätze. Die schwerere sind die täglichen Geschäftsdokumente: etwa fünfzehn am Tag, die zuvor von Hand in Tabellen getippt werden mussten. Gegen echte Beispiele geprüft — ein Tagesabschluss, ein Artikel-Verkaufsbericht, eine mehrzeilige Großhandelsrechnung — sind drei bis fünf Minuten sorgfältiger Eingabe pro Stück eher konservativ, denn eine lange Rechnung, deren Positionen gegen den Artikelkatalog abgeglichen werden müssen, dauert länger. Fünfzehn am Tag sind in der Größenordnung einer Stunde täglich, fünf bis sechs Stunden pro Woche. Bewertet zum deutschen gesetzlichen Mindestlohn plus den rund 30 % Arbeitgeber-Nebenkosten — etwa 18 € pro Stunde — sind das in der Größenordnung von 400–470 € im Monat, nahe 5.000 € im Jahr, an reiner Dateneingabe. Auslagern ist pro Stunde günstiger, aber die Dokumente sind deutsch, und jede extrahierte Zahl muss von einer deutschsprachigen Person nachvalidiert werden, sodass der Validierungs-Overhead den Großteil der Ersparnis auffrisst. Die Pipeline entfernt die Aufgabe, statt sie zu verlagern.

Der größere Gewinn sind aber nicht die Stunden — es ist die Entscheidung, die sie blockierten. Verkäufe, die alle sechs Monate durchgearbeitet wurden, weil die manuelle Eingabe untragbar war, werden jetzt abgeglichen, während die Dokumente verarbeitet werden, sodass innerhalb von Tagen statt zwei Quartalen später sichtbar ist, ob ein neu eingeführter Artikel ein Verkaufsschlager oder Ladenhüter ist. Für ein kleines Unternehmen, das entscheidet, was es führt, ist das der Unterschied zwischen Steuern und Raten.

Die ehrlichen Lücken aus der vorherigen Fassung dieser Studie — Extraktionsgenauigkeit in der Praxis hoch, aber ungemessen, und das Ganze von Hand auf einer Maschine betrieben — haben das Jahr nicht überlebt. Beide wurden zu Arbeitspaketen: Ein Benchmark-Prüfstand mit von Hand gelabeltem Ground-Truth-Korpus schloss die erste, ein Watch-Modus mit Autostart, Datei-Logging und einer Kosten-CLI die zweite. Die Lücken, die an ihre Stelle traten, sind genauso ehrlich: Sensible Dokumente gehen weiterhin an ein Cloud-Modell (der lokale Pfad ist gebenchmarkt, nicht verdrahtet), und das neue Erfassungsmodell hat am Korpus gezeigt, dass es auch die Dokumenttypen der Buchhaltungs-Engine lesen könnte — diese Konsolidierung ist vermessen und entworfen, aber noch nicht gebaut.