PDF als Datenquelle: Was beim Import wirklich passiert

Es gibt eine Kategorie von Projekten, die im Angebot nach einem Detail klingt und in der Umsetzung die Hälfte des Aufwands verschlingt: Daten einlesen, die als PDF vorliegen.

Betriebswirtschaftliche Auswertungen, Kontoauszüge, Lieferantenrechnungen, Prüfberichte — sie alle kommen als PDF, weil sie aus einem System stammen, das Papier nachbildet. Wer sie auswerten will, muss sie zurückverwandeln. Das ist lösbar, aber selten so einfach, wie es in der Aufwandsschätzung aussieht.

Drei Sorten PDF, drei Schwierigkeitsgrade

Textbasierte PDFs enthalten die Zeichen als Text, mit Position auf der Seite. Das ist der gute Fall: Die Zeichen sind da, sie müssen nur wieder zu Zeilen und Spalten zusammengesetzt werden.

Gescannte PDFs enthalten ein Bild. Hier braucht es Texterkennung, und damit kommt eine Fehlerquelle hinzu, die man nie ganz beseitigt. Eine 8, die als 3 gelesen wird, ist in einer Zahlenkolonne besonders unangenehm, weil sie plausibel bleibt.

Hybride PDFs sind textbasiert, enthalten aber Tabellen als Grafik oder umgekehrt. Sie sehen aus wie der einfache Fall und verhalten sich wie der schwierige — die häufigste Ursache für Schätzungen, die um den Faktor drei danebenliegen.

Der erste Schritt in jedem solchen Projekt ist deshalb kein Code, sondern eine Sichtung: zwanzig echte Dateien aus verschiedenen Jahren und, wenn möglich, aus verschiedenen Vorsystemen. Nicht die fünf schönen, die als Muster geschickt wurden.

Die Textextraktion ist der leichte Teil

Werkzeuge, die Text mit Koordinaten aus einem PDF holen, gibt es seit Jahren und sie funktionieren. Das eigentliche Problem beginnt danach, und es ist ein fachliches, kein technisches.

Ein PDF hat keine Tabellen. Es hat Zeichen an Positionen. Dass drei Zahlen untereinander eine Spalte bilden, ist eine Interpretation — eine, die der Mensch mühelos leistet und der Rechner nur mit Regeln.

Typische Stolpersteine:

• Spalten ohne Trennlinien. Die Zuordnung erfolgt über x-Koordinaten-Cluster. Verschiebt ein Vorsystem im Folgejahr eine Spalte um vier Millimeter, kippt die Zuordnung.
• Umbrochene Bezeichnungen. „Aufwendungen für bezogene Leistungen” steht auf zwei Zeilen, der Betrag nur auf der ersten. Wer zeilenweise liest, bekommt einen Eintrag ohne Bezeichnung und eine Bezeichnung ohne Betrag.
• Zwischensummen und Gesamtsummen stehen mitten im Fluss und sehen aus wie Positionen. Wer sie mitzählt, verdoppelt Teile der Auswertung.
• Vorzeichenkonventionen. Minusbeträge erscheinen mal mit vorangestelltem Minus, mal in Klammern, mal mit nachgestelltem „S” oder „H”. Innerhalb desselben Dokuments.
• Seitenumbrüche mitten in einer Position, mit wiederholtem Tabellenkopf, der nicht als Position gelesen werden darf.

Keiner dieser Punkte ist schwierig für sich. Zusammen ergeben sie eine Regelmenge, die man nicht rät, sondern an echten Dateien entwickelt.

Warum Sprachmodelle hier verlockend und riskant sind

Es liegt nahe, die Seite einfach einem multimodalen Modell zu geben und um eine Tabelle zu bitten. Das funktioniert erstaunlich gut — und ist für buchhalterische Daten in dieser Form trotzdem nicht ausreichend.

Der Grund ist derselbe wie bei jeder KI-Ausgabe: Das Modell erzeugt eine plausible Tabelle. Ob die Zahl in Zeile 14 der Zahl im Dokument entspricht, ist eine andere Frage. Bei tausend Zeilen fallen zwei falsche nicht auf — bis sie in einer Auswertung landen, auf die sich jemand beruft.

Brauchbar wird der Ansatz mit zwei Ergänzungen:

Gegenprobe über die Summen. Fast jede kaufmännische Auswertung enthält Zwischen- und Gesamtsummen. Wenn die Summe der eingelesenen Positionen nicht der ausgewiesenen Gesamtsumme entspricht, ist der Import fehlerhaft — ohne dass man wissen muss, welche Zeile es war. Diese Prüfung kostet wenige Zeilen Code und fängt den Großteil der Fehler.

Vertrauensbereich statt Alles-oder-nichts. Dokumente, deren Struktur die Regeln sauber erkennen, laufen automatisch durch. Dokumente, bei denen die Summenprobe scheitert oder die Struktur unbekannt ist, landen in einer Prüfliste. Ein Mensch sieht sie sich an — und aus jeder Korrektur wird eine neue Regel.

Der Anteil, der durch die Prüfliste muss, sinkt in den ersten Wochen deutlich und pendelt sich dann ein. Ihn auf null zu bringen, ist kein sinnvolles Ziel; er auf einem bekannten Niveau zu halten schon.

Was in die Datenbank gehört — und was daneben

Eine Entscheidung, die später viel Ärger spart: Das Original bleibt. Die Datenbank speichert nicht nur die extrahierten Werte, sondern auch die Ursprungsdatei, die Seite, die Zeilenposition und die Version der Regeln, mit der eingelesen wurde.

Das klingt nach Speicherverschwendung und ist eine Versicherung. Wenn in achtzehn Monaten jemand fragt, warum eine Zahl so im System steht, gibt es zwei mögliche Antworten. Die eine lautet: „Wir wissen es nicht, der Import ist seitdem dreimal geändert worden.” Die andere zeigt die Originalseite mit der markierten Zeile.

Konkret speichern wir je Position:

Feld	Zweck
Wert und Bezeichnung	Die eigentliche Nutzlast
Quelldatei und Prüfsumme	Eindeutige Zuordnung zum Original
Seite und Position	Rücksprung in das Dokument
Regelversion	Nachvollziehbarkeit bei geändertem Import
Prüfstatus	Automatisch übernommen oder manuell bestätigt

Der Aufwand dafür ist gering, solange man es von Anfang an so anlegt. Nachträglich einzubauen ist teuer, weil die Altdaten diese Angaben nicht haben.

Der Import ist nie fertig

Das ist die Erkenntnis, die am schwersten in Projektpläne passt. Vorsysteme ändern ihre Ausgabe, Kanzleien wechseln die Software, ein Jahreswechsel bringt neue Kontenrahmen.

Ein Import, der als einmalig gebautes Modul geplant wird, ist nach zwei Jahren ein Sanierungsfall. Ein Import, der als betreute Strecke geplant wird — mit Prüfliste, Protokoll und einem Menschen, der monatlich zehn Minuten hineinsieht —, bleibt über Jahre benutzbar.

Deshalb steht in unseren Angeboten für solche Vorhaben immer eine Position, die Auftraggeber zunächst irritiert: laufende Pflege der Importregeln. Sie kostet wenig und ist der Unterschied zwischen einem System, das lebt, und einem, das langsam unbrauchbar wird.

Kurz gefasst

Wer PDFs einliest, baut keine Extraktionsfunktion, sondern eine Strecke mit vier Bestandteilen: Erkennung, Prüfung gegen die im Dokument enthaltenen Summen, Rückverfolgbarkeit zum Original und eine Prüfliste für die Fälle, die nicht sauber durchlaufen. Fehlt einer davon, funktioniert der Import in der Vorführung — und im Alltag nur so lange, wie sich nichts ändert.