Dokumenten-Pipeline

Das geschäftliche Problem

Ein kleines Unternehmen und der Haushalt dahinter erzeugen zwei Papierströme. Der erste ist eingehende Post — Rechnungen, Behördenbriefe, Mahnungen, Steuerpost —, 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 (der Cache-Key für OCR und Extraktion), mit Tesseract ge-OCRt, dann von einem LLM 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 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.

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.

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.

Das Ergebnis

Im Einsatz seit 2023 über mehrere Versionen, mit dem Wechsel auf Landing AI Ende 2025. 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 €.

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: Die Extraktionsgenauigkeit ist in der Praxis hoch, aber ungemessen (noch keine Evaluierungsschicht), und das Ganze läuft von Hand auf einer Maschine statt nach Zeitplan mit Observability — die nächsten Schritte, falls es jemals den Laptop verlassen muss.