Docling im Test: Taugt der freie Dokumentenkonverter für die Verwaltung?

Docling ist der Konverter, auf den in Verwaltungsprojekten gerade am häufigsten verwiesen wird: quelloffen, von IBM, MIT-Lizenz, läuft offline, macht aus PDF strukturiertes Markdown. Die Frage ist, ob er den bisherigen Weg aus pdftotext und Tesseract ablöst. Die Antwort: teilweise, und man muss wissen, wo.

Aufbau des Tests

113 Dateien, 368 Seiten, davon 90 Seiten ohne Textebene (echte Scans). Mischung aus Tabellen, Bescheiden, Rechnungen, Mahnungen und rohen Scans, alles deutschsprachig. Für 10 Tabellen wurden vorab manuell 284 Referenzzeilen festgelegt, für 31 Belege die Sollwerte der zu extrahierenden Felder. Hardware: Notebook mit Apple M4 und 32 GB. Docling 2.129.0.

Laufzeit

Lauf	Umfang	s/Seite
Docling mit systemeigenem OCR (Apple Vision)	368 Seiten	1,37
Docling, nur Scan-Seiten	90 Seiten	1,80
Docling mit EasyOCR	90 Seiten	3,48
Docling mit RapidOCR	90 Seiten	3,78
Docling Vision-Pipeline (granite-docling)	29 Seiten	9,65
Tesseract 200 dpi deutsch	90 Seiten	1,38
pdftotext mit Layout	278 Text-Seiten	0,005

Kein einziger Abbruch, keine leere Ausgabe. GPU-Beschleunigung brachte gegenüber der CPU nur 2 Prozent, das Verfahren ist also nicht rechenlastig. Für Text-PDFs bleibt pdftotext um den Faktor 270 schneller, und daran ändert keine Modellwahl etwas.

Tabellen: der entscheidende Vergleich

Verfahren	erkannte Referenzzeilen von 284	Quote
pdftotext und Tesseract (bisheriger Weg)	265	93,3 %
Docling, Standardeinstellung	249	87,7 %
Docling mit Voll-OCR	254	89,4 %
Docling ohne Tabellenmodell	241	84,9 %
Docling Vision-Pipeline	45	15,8 %

Das Ergebnis überrascht und ist der wichtigste Befund des Tests. Docling gewinnt genau dort, wo Tesseract ganz versagt, etwa bei einer schlecht gescannten Forderungsaufstellung (8 von 8 Zeilen gegenüber 5 von 8). Es verliert bei sauber gedruckten Auszügen und Abrechnungen, weil das Tabellenmodell einzelne Zellen stumm verschluckt: In einem Bausparauszug fehlten 5 von 12 Beträgen, ohne Fehlermeldung.

Drei Befunde, die jeder Einsatz kennen muss

1. Kopf- und Fußzeilen gehen verloren. Docling ordnet Seitenkopf und Seitenfuß der Kategorie „Furniture" zu und exportiert sie standardmäßig nicht. Damit verschwinden Aktenzeichen, Steuernummer, Datum und Seitenzahl, also genau die Felder, die eine Verwaltung zur Zuordnung braucht. Im Korpus betraf das 25 Kennnummern. Abhilfe: aus dem JSON mit beiden Inhaltsebenen exportieren (included_content_layers={BODY, FURNITURE}). Das kostet 6 Prozent mehr Token und hebt die Extraktionsgenauigkeit von 87,7 auf 91,8 Prozent. Die Kommandozeile kann das nicht, man braucht die Programmierschnittstelle.

2. Stumme Zellverluste werden vom Sprachmodell kaschiert. Wenn das Tabellenmodell eine Zeile verliert, meldet niemand etwas. Ein nachgeschaltetes Sprachmodell ergänzt die Lücke aus dem Muster der übrigen Zeilen, plausibel und falsch. Gegenmittel: eine Saldo-Prüfung (Anfangsbestand plus Einzelzeilen ergibt Endbestand) und bei Abweichung ein zweiter Lauf mit Voll-OCR. Ohne diese Prüfung ist Docling für Abrechnungen nicht einsetzbar.

3. Zwei Schalter, die man setzen muss. Ohne --image-export-mode placeholder landen alle Bilder als Base64 im Markdown; zwei Logos erzeugten 20 kB Ballast. Und die Sprachcodes unterscheiden sich je OCR-Backend; bei falschem Code fällt Docling stillschweigend auf ein anderes Backend zurück, ohne Warnung.

Extraktionsgenauigkeit im Zusammenspiel

31 Belege, Sollwerte manuell festgelegt, Extraktion durch ein großes Sprachmodell:

Eingabe ins Sprachmodell	Felder exakt
Docling-Markdown mit Kopfzeilen	91,8 %
Rohtext aus pdftotext	91,8 %
Docling-Markdown ohne Kopfzeilen	87,7 %
PDF direkt an die Plattform übergeben	82,7 %

Docling und schlichter Rohtext liegen gleichauf. Der Gewinn von Docling liegt nicht in der Genauigkeit, sondern darin, dass es für Scans ohne Textebene überhaupt etwas liefert, wo pdftotext leer ausgeht.

Lokale Ketten fallen deutlich ab: ein 14-Milliarden-Modell auf dem Notebook erreichte 73,3 Prozent und brauchte 53 Minuten für 31 Belege, bei Kontoauszügen brach es am Token-Limit ab.

Empfehlung

Fall	Werkzeug
PDF mit Textebene	pdftotext -layout, 270-mal schneller, gleiche Genauigkeit
Scan ohne Textebene	Docling mit passendem OCR-Backend
Tabellen in Abrechnungen	Docling plus Saldo-Prüfung, bei Abweichung Zweitlauf
Handschriftliche Formulare	weder noch, dort braucht es ein Vision-Sprachmodell, siehe Antragsstrecke
Betrieb auf Linux-Servern	Docling mit RapidOCR
Vision-Pipeline von Docling	derzeit nicht einsetzbar

Für die Verwaltung ist Docling damit relevant, aber nicht als Universallösung: Es ist der Baustein, der Scans lesbar macht, bevor ein Modell sie sieht. Es ersetzt nicht die Prüfschicht und spart keine Token.

Offen

Der Test wurde nach der dritten Stufe beendet. Ungetestet blieben die größeren Vision-Presets und eine Extraktionskette mit einem zweiten großen Sprachmodell. Sobald das nachgeholt ist, steht es hier.