Kann KI Ihre gescannten Dokumente lesen?

Jede Demo nutzt ein sauberes PDF. Ihr Aktenschrank enthält keine sauberen PDFs — er enthält Scans in der Auflösung, die der Bürokopierer voreingestellt hat, mit dem Handy fotografierte Rechnungen, Verträge mit Unterschrift quer über die letzte Seite und Tabellen, die jemand in ein Word-Dokument eingefügt hat. Ob KI das lesen kann, ist keine Frage des Modells. Es ist eine Frage der Datei — und die Antwort steht als harte Zahl in der Dokumentation der Anbieter.

Die nützliche Frage lautet nicht „kann KI Dokumente lesen". Sie lautet welche Ihrer Dokumente — und das lässt sich beantworten, bevor Sie Geld ausgeben.

Dokumentenverarbeitung hat veröffentlichte Untergrenzen. Text unterhalb einer bestimmten Pixelhöhe wird nicht erkannt. Handschrift wird in weit weniger Sprachen unterstützt als Druck. Vertikaler Text wird von einem großen Anbieter gar nicht unterstützt. Ein passwortgeschütztes PDF wird überall abgewiesen. Das sind keine Randfälle, sondern dokumentierte Grenzen — und die meisten hängen daran, wie die Datei entstanden ist, nicht was darin steht.

Die Untergrenze, die niemand erwähnt: Text hat eine Mindesthöhe

Zwei Anbieter veröffentlichen denselben praktischen Schwellenwert. Es ist die nützlichste Zahl in diesem Text.

Amazon Textract: „The minimum height for text to be detected is 15 pixels. At 150 DPI, this would be the same as 8 point font."

Azure Document Intelligence: „The minimum height of the text to be extracted is 12 pixels for a 1024 x 768-pixel image. This dimension corresponds to about 8-point text at 150 dots per inch."

Beide landen bei rund 8 pt bei 150 dpi. Darunter verschlechtert sich die Erkennung nicht allmählich — der Text wird schlicht nicht erfasst.

Das ist relevant, weil Bürogeräte häufig 150 dpi voreingestellt haben und ein großer Teil des Geschäftspapiers Bedingungen, Fußnoten und Referenznummern in 7 oder 8 pt setzt. Der Rechnungstext wird sauber erkannt, die Zahlungsreferenz darunter nicht. Wenn Sie sich je gefragt haben, warum die Extraktion fast alles richtig macht: meist ist das der Grund.

Die Abhilfe ist eine Scanner-Einstellung, kein anderes Modell. 300 dpi bringt 8-pt-Text deutlich über die Grenze.

Was die Anbieter tatsächlich akzeptieren

Gelesen in der Dokumentation der Anbieter am 20. August 2026.

Zwei dieser Zeilen sind eher Fallen als Grenzen.

Textracts synchrone API akzeptiert eine Seite. Nicht ein Dokument — eine Seite. Mehrseitige PDFs erfordern den asynchronen Weg, eine andere Integration. Teams bauen regelmäßig gegen den einfacheren Endpunkt und entdecken die Grenze bei der ersten echten Rechnung.

Azures kostenlose Stufe verarbeitet die ersten zwei Seiten. Kein Fehler, keine Warnung — sie analysiert zwei Seiten und antwortet. Ein zehnseitiger Vertrag, dort getestet, sieht aus, als hätte es funktioniert.

Ihr PDF wird still zu Bildern, und dort versteckt sich der Preis

Wie ein PDF verarbeitet wird, entscheidet über die Rechnung — und ist der am wenigsten verstandene Teil der Dokumentenverarbeitung. Anthropic dokumentiert beide Wege ausdrücklich. Reine Textextraktion „cannot analyze images, charts, or visual layouts within PDFs" und „uses approximately 1,000 tokens for a 3-page PDF." Volle visuelle Verarbeitung „processes each page as both text and image" und „uses approximately 7,000 tokens for a 3-page PDF."

Das Siebenfache an Tokens für dieselben drei Seiten. OpenAI beschreibt dasselbe Verhalten: Bei bildfähigen Modellen „the API extracts both text and page images and sends both to the model," was „can increase token usage."

Die Variante, die Ihr Rechnungslayout versteht, kostet also ein Vielfaches der Variante, die nur den Text liest. Wer auf Basis von Text-Tokens kalkuliert und dann die visuelle Verarbeitung einschaltet, um Tabellen in den Griff zu bekommen, wird von der Rechnung überrascht.

Verwandter Ausfall: Anthropic hält fest, dass „dense PDFs (many small-font pages, complex tables, or heavy graphics) can fill the context window before reaching the page limit." Ihr 400-Seiten-Dokument scheitert auf Seite 90, weit innerhalb der dokumentierten 600. Das Seitenlimit ist eine Obergrenze, keine Zusage.

Unterhalb von etwa 8 pt bei 150 dpi verschlechtert sich die Erkennung nicht allmählich. Der Text wird schlicht nicht erfasst.

Sprache und Handschrift sind enger als Druck

Druck und Handschrift sind nicht dieselbe Fähigkeit, und der Abstand ist groß.

Amazon Textract unterstützt Druck in Englisch, Französisch, Deutsch, Italienisch, Portugiesisch und Spanisch. Handschrifterkennung ist „only supported in English." Für ein deutsches Unternehmen heißt das: ein handschriftlicher Lieferschein liegt außerhalb der dokumentierten Fähigkeit, während dasselbe Dokument gedruckt darin liegt.

Textract hält zudem fest, dass „vertical text (text written vertically, as is common in languages like Japanese and Chinese)" nicht unterstützt wird.

Azure geht anders vor: Das Read-Modell klassifiziert jede Zeile als handschriftlich oder nicht und liefert ein isHandwritten-Feld mit Konfidenzwert. Das ist operativ nützlicher — Sie können Zeilen mit niedriger Konfidenz an einen Menschen weiterleiten, statt ihnen stillschweigend zu vertrauen.

Mistral OCR meldet starke Leistung über 40+ Sprachen, wobei Tabellenformatierung und Blockextraktion an bestimmte Modellversionen gebunden sind.

Vier Fallen, die nichts mit Qualität zu tun haben

Passwortgeschützte PDFs werden abgewiesen. Textract: „PDFs cannot be password protected." Azure: „If your PDFs are password-locked, you must remove the lock before submission." Anthropic verlangt Standard-PDFs ohne Passwort oder Verschlüsselung. Kontoauszüge und Lohnunterlagen kommen häufig geschützt an.

Eingebettete Bilder in Office-Dateien sind unsichtbar. Azure hält für Word, Excel, PowerPoint und HTML fest, dass „embedded or linked images aren't supported." Eine als Bild in ein Word-Dokument eingefügte Rechnung enthält nichts Extrahierbares. Die Datei wird erfolgreich verarbeitet und liefert den umgebenden Text.

Office-Dateien werden in Zeichen gezählt, nicht in Seiten. Azure rechnet „up to 3,000 characters = 1 page unit" für Word und HTML, jedes Excel-Arbeitsblatt und jede Folie als eine Seite. Ein Kostenmodell auf Seitenbasis geht für Office-Dokumente daneben.

Drehung ist unproblematisch, Ausrichtung nicht. Textract „supports all in-plane document rotations, for example 45-degree in-plane rotation" — ein schiefer Scan stört nicht. Vertikaler Text schon. Schieflage und Schreibrichtung sind verschiedene Fehler.

Ordnen Sie Ihren Stapel ein, bevor Sie Geld ausgeben

Zwanzig Minuten mit einer repräsentativen Stichprobe beantworten das meiste.

1. Wie ist die Datei entstanden? Aus Software exportiert, von Papier gescannt oder fotografiert. Exporte tragen eine echte Textebene. Scans und Fotos nicht — und für sie gilt alles oben Genannte.

2. Messen Sie den kleinsten Text, den Sie brauchen. Nicht den Fließtext — die Referenznummern, die Bedingungen, die Summen. Laufen Ihre Scans mit 150 dpi und liegt dieser Text unter 8 pt, korrigieren Sie den Scanner, bevor Sie Modelle bewerten.

3. Prüfen Sie die vier Fallen. Passwortschutz? Rechnungen als Bild in Word-Dokumenten? Handschrift in einer anderen Sprache als Englisch? Vertikaler Text?

4. Zählen Sie Seiten pro Dokument und wählen Sie den passenden API-Weg. Mehr als eine Seite schließt Textracts synchronen Endpunkt aus. Mehr als zwei Seiten macht einen Test auf Azures kostenloser Stufe wertlos.

Wenn die Dokumente nicht funktionieren

Manchmal lautet die ehrliche Antwort, dass dieser Workflow noch nicht so weit ist. Dafür gibt es drei echte Reaktionen.

Die Quelle korrigieren. Eine Scanner-Einstellung ist der günstigste Eingriff in diesem ganzen Text. Der Wechsel von 150 auf 300 dpi löst einen großen Teil der Extraktionsfehler ohne Softwarekosten.

Den Eingang verlegen. Kann ein Lieferant statt eines Scans ein natives PDF oder eine strukturierte Datei senden, verschwindet das Problem, statt gelöst zu werden. Das ist meist eine E-Mail, kein Projekt.

Die lesbare Hälfte automatisieren. Native PDFs laufen automatisch, Scans und Handschrift gehen an einen Menschen. Ein Workflow, der 70 % zuverlässig erledigt, schlägt einen, der 100 % unzuverlässig erledigt — und er ist ehrlich darüber, welche Hälfte welche ist.

Was dieser Text nicht leistet

Alle Angaben oben sind veröffentlichte Grenzen mit Abrufdatum 20. August 2026, keine Benchmark-Ergebnisse — und Grenzen ändern sich. Anbieter liefern Modellaktualisierungen aus, die das Dokumentenverhalten ändern, ohne die dokumentierten Grenzen anzupassen.

Bewusst nicht enthalten: Genauigkeitsprozente. Herstellerangaben zur Genauigkeit werden ohne die Dokumentbedingungen veröffentlicht, unter denen sie gemessen wurden — das macht sie für die Vorhersage Ihres eigenen Ergebnisses unbrauchbar, und diese Auslassung zu wiederholen würde den Zweck dieses Textes untergraben. Die Grenzen oben sind harte Zahlen der Anbieter selbst. Eine Genauigkeitsangabe ist das nicht.

Ebenfalls nicht enthalten: die veröffentlichten Grenzen von Google Document AI, die zum Zeitpunkt der Erstellung nicht abrufbar waren.

Häufig gestellte Fragen

Kann KI ein gescanntes Dokument lesen? Häufig ja, aber es hängt am Scan, nicht am Modell. Amazon Textract nennt 15 Pixel als Mindesthöhe für erkennbaren Text und beschreibt das als 8-Punkt-Schrift bei 150 dpi. Azure Document Intelligence nennt 12 Pixel bei einem Bild von 1024 mal 768 und beschreibt denselben praktischen Schwellenwert. Bürogeräte haben häufig 150 dpi voreingestellt, und Geschäftspapier setzt Bedingungen und Referenznummern oft in 7 oder 8 pt — deshalb wird meist der Großteil erfasst, das Kleingedruckte aber nicht. Ein erneuter Scan mit 300 dpi behebt einen großen Teil dieser Fehler.

Kann ChatGPT ein PDF lesen? Ja, und die Art der Verarbeitung wirkt sich auf die Kosten aus. OpenAI dokumentiert, dass bei bildfähigen Modellen sowohl Text als auch Seitenbilder an das Modell gehen, was den Tokenverbrauch erhöht. Anthropic beziffert den Unterschied: Reine Textextraktion benötigt rund 1.000 Tokens für ein dreiseitiges PDF und kann Bilder, Diagramme und visuelle Layouts nicht auswerten, während die volle visuelle Verarbeitung für dieselben drei Seiten rund 7.000 Tokens benötigt.

Warum extrahiert die KI falsche Daten aus meinen Rechnungen? Die häufigsten Ursachen sind physikalisch, nicht inhaltlich. Text unter etwa 8 pt bei 150 dpi wird gar nicht erkannt. Über mehrere Seiten laufende Tabellen und verbundene Zellen brechen die strukturelle Extraktion. Passwortgeschützte PDFs werden von allen großen Anbietern abgewiesen. Und eine als Bild in ein Word-Dokument eingefügte Rechnung enthält nichts Extrahierbares, denn Azure hält fest, dass eingebettete oder verknüpfte Bilder in Office-Dateien nicht unterstützt werden — die Datei wird erfolgreich verarbeitet und liefert nur den umgebenden Text.

Kann KI Handschrift lesen? Deutlich eingeschränkter als Druck. Amazon Textract unterstützt gedruckten Text in Englisch, Französisch, Deutsch, Italienisch, Portugiesisch und Spanisch, hält jedoch fest, dass Handschrifterkennung nur auf Englisch unterstützt wird. Für ein deutsches Unternehmen liegt ein handschriftlicher Lieferschein damit außerhalb der dokumentierten Fähigkeit, während dasselbe Dokument gedruckt darin liegt. Azure liefert stattdessen pro Zeile ein isHandwritten-Feld mit Konfidenzwert, sodass unsichere Zeilen an einen Menschen weitergeleitet werden können.

Quellen

• Amazon Textract, Set Quotas, docs.aws.amazon.com/textract/latest/dg/limits-document.html — abgerufen 20.8.2026
• Microsoft, Read model OCR data extraction, aktualisiert 14.8.2026 — abgerufen 20.8.2026
• Microsoft, Service quotas and limits, aktualisiert 10.7.2026 — abgerufen 20.8.2026
• Anthropic, PDF support, platform.claude.com/docs/en/build-with-claude/pdf-support — abgerufen 20.8.2026
• OpenAI, PDF files, developers.openai.com/api/docs/guides/pdf-files — abgerufen 20.8.2026
• Mistral, Basic OCR, docs.mistral.ai/capabilities/OCR/basic_ocr/ — abgerufen 20.8.2026