OCR vs. Dokumentenextraktion — warum Zeichen noch keine Daten sind
OCR macht aus einer gescannten Seite Text. Dokumentenextraktion macht daraus Felder, die Sie verwenden können — invoice_number, total, line_items — jedes zurückverknüpft mit der Stelle, von der es stammt. Wenn Sie jemals OCR ausgeführt und danach trotzdem alles von Hand in eine Tabelle abgetippt haben, dann ist genau das der entscheidende Unterschied — und so erkennen Sie, welches Werkzeug Ihr Arbeitsablauf wirklich braucht.
- comparison
- ocr
Wenn Sie jemals einen Stapel Rechnungen eingescannt, sie durch ein
OCR-Werkzeug geschickt und sich danach trotzdem dabei wiedergefunden
haben, wie Sie Zahlen von Hand in eine Tabelle übertragen, dann haben
Sie die Lücke, um die es in diesem Beitrag geht, bereits gespürt. OCR hat
seine Aufgabe erledigt — es hat aus dem Bild einer Seite Text gemacht.
Aber Text ist noch keine Daten. Zu wissen, dass die Zeichen 1,250.00
irgendwo auf der Seite vorkommen, sagt Ihnen nicht, dass das der
fällige Gesamtbetrag ist und nicht die Zwischensumme, die Steuer
oder der Saldo des Vormonats.
Diese letzte Meile — von »Hier sind die Wörter auf der Seite« hin zu »Hier sind die Gesamtsumme, der Lieferant und jeder Einzelposten, benannt und einsatzbereit« — ist die Dokumentenextraktion. Dieser Beitrag erklärt den Unterschied in einfachen Worten, zeigt, wo jedes der beiden hingehört, und hilft Ihnen zu erkennen, welches Ihr Arbeitsablauf tatsächlich braucht.
Was OCR wirklich leistet
OCR — optische Zeichenerkennung — hat eine einzige Aufgabe: ein Bild von Text anzusehen und den Text auszugeben. Füttern Sie es mit einem gescannten Beleg, und Sie bekommen ein Transkript zurück — den Händlernamen, die Einzelposten, die Gesamtsumme, das Datum — als fortlaufende Folge von Zeichen, ungefähr in Leserichtung.
Für einige Zwecke ist das wirklich nützlich:
- Ein gescanntes PDF durchsuchbar machen. OCR ist das, was Ihnen erlaubt, ein abfotografiertes Dokument per Ctrl-F zu durchsuchen.
- Barrierefreiheit. Screenreader brauchen die Textebene, die OCR erzeugt.
- Volltextarchive. Wenn Sie nur ein Dokument später anhand seines Inhalts wiederfinden müssen, reicht OCR aus.
Was OCR nicht leistet, ist, das Dokument zu verstehen. Es weiß nicht, welche Zahl die Gesamtsumme ist und welche die Steuer. Es weiß nicht, dass die drei Zeilen in der Mitte Einzelposten sind und die Zeile ganz unten eine Summe ist. Es weiß nicht, dass »Acme Corp« der Lieferant und »Jane Smith« die Ansprechperson ist. Es liefert Ihnen einfach die Zeichen und überlässt Ihnen die Bedeutung.
Was die Dokumentenextraktion hinzufügt
Die Dokumentenextraktion beginnt dort, wo OCR endet. Sie nimmt den Inhalt der Seite und gibt benannte, typisierte Felder zurück — ein strukturiertes Objekt, das Sie direkt in eine Tabelle, eine Datenbank oder ein anderes System übernehmen können:
{
"invoice_number": "INV-2026-0412",
"issue_date": "2026-05-30",
"vendor": "Acme Corp",
"total_due": 1250.00,
"currency": "USD",
"line_items": [
{ "description": "Design work", "quantity": 10, "unit_price": 100.00 },
{ "description": "Hosting", "quantity": 1, "unit_price": 250.00 }
]
}
Drei Dinge haben sich zwischen dem OCR-Transkript und diesem hier verändert:
- Die Werte sind benannt.
total_dueist die Gesamtsumme, nicht bloß eine Zahl, die zufällig auf der Seite steht. Sie müssen nicht herausfinden, was was ist — die Extraktion hat es getan. - Die Struktur bleibt erhalten. Einzelposten kommen als Liste von Zeilen zurück, nicht als platt gewalztes Durcheinander. Das, wovon es eines gibt (die Rechnungsnummer), ist getrennt von dem, wovon es viele gibt (die Einzelposten).
- Typen sind normalisiert.
1250.00ist eine Zahl, nicht die Zeichenkette"$1,250.00".2026-05-30ist ein sortierbares Datum, in welchem Format das Dokument es auch immer gedruckt hat. Sie können rechnen und filtern, ohne vorher etwas aufräumen zu müssen.
Das ist der ganze Unterschied in einem Wort: OCR gibt Ihnen Zeichen, die Extraktion gibt Ihnen Daten.
Der Vergleich, Seite an Seite
| OCR | Dokumentenextraktion | |
|---|---|---|
| Ausgabe | Fortlaufender Text | Benannte, typisierte Felder (JSON / CSV / Excel) |
| Versteht das Dokument? | Nein — transkribiert nur | Ja — kennt Gesamtsumme vs. Zwischensumme vs. Steuer |
| Struktur | Flacher Text, Leserichtung | Erhält Listen, Tabellen, Verschachtelung |
| Typen | Alles ist eine Zeichenkette | Zahlen, Daten, Booleans normalisiert |
| Neues Layout | Funktioniert (es liest ja nur) | Funktioniert ohne Vorlage pro Lieferant |
| Gut für | Suche, Archiv, Barrierefreiheit | Daten in Werkzeuge und Abläufe einspeisen |
| Müssen Sie noch abtippen? | Meistens ja | Nein |
Die Zeile, die für die meisten Teams am meisten zählt, ist die letzte. Wenn Ihr Ziel ist, mit den Zahlen etwas zu tun — sie abzugleichen, aufzusummieren, in Ihr Buchhaltungssystem zu übertragen — dann lässt OCR Sie mit dem Abtippschritt allein. Die Extraktion nimmt ihn weg.
»Aber ich habe doch schon OCR — reicht das nicht?«
Das ist die häufigste Frage, und die ehrliche Antwort lautet: Es kommt ganz darauf an, was Sie als Nächstes tun.
Wenn Sie Dokumente immer nur finden und lesen müssen, reicht OCR — fügen Sie keine Komplexität hinzu, die Sie nicht nutzen werden. Aber wenn ein Mensch die OCR-Ausgabe liest und die Werte irgendwo anders einträgt, dann ist genau dieser Tippschritt das, wofür die Extraktion da ist. Das Erkennungszeichen ist einfach: Kopieren Sie Zahlen von einem Bildschirm auf einen anderen? Wenn ja, tun Sie von Hand, was die Extraktion automatisch erledigt.
Eine verwandte Falle ist, die Extraktion selbst auf OCR mit regulären Ausdrücken aufzubauen — »finde die Zeile, die mit TOTAL beginnt, und nimm die Zahl danach«. Das funktioniert beim ersten Lieferanten und bricht beim zweiten zusammen, weil die nächste Rechnung stattdessen »Amount Due« schreibt, die Summe an eine andere Stelle setzt oder die Tabelle über zwei Seiten laufen lässt. Jedes neue Layout ist eine neue Regel. Diese Tretmühle ist der Grund, warum vorlagen- und regex-basierte Ansätze über eine Handvoll Dokumentformate hinaus nicht skalieren.
Wo moderne Dokumentenextraktion anders ist
Die ältere Generation von Extraktionswerkzeugen brauchte eine Vorlage pro Layout — Sie zeichneten Kästchen auf ein Musterdokument: »die Rechnungsnummer steht immer hier, die Gesamtsumme immer dort«. Das funktioniert nur, wenn jedes Dokument gleich aussieht, was so gut wie nie zutrifft, sobald Sie mehr als einen Lieferanten, eine Bank oder eine Gegenpartei haben.
Layout-bewusste Extraktion liest das Dokument so, wie ein Mensch es tut — indem sie versteht, was die Felder bedeuten, nicht wo sie auf der Seite stehen. Ein neues Rechnungslayout funktioniert beim ersten Versuch, ganz ohne einzurichtende Vorlage. Ein Kontoauszug, dessen Tabelle sich über zwölf Seiten erstreckt, kommt als eine saubere Liste zurück. Ein Zolldokument, das zwei Sprachen mischt, behält jeden Wert in seiner ursprünglichen Schrift. Derselbe Ansatz deckt Belege, Verträge, Ausweise, Lebensläufe und Laborberichte ab — verschiedene Dokumente, dieselbe Idee: Sie beschreiben, was Sie wollen, und die Engine findet es.
Wenn Sie die praktische Variante von »beschreiben, was Sie wollen« suchen, haben wir einen ganzen Beitrag dazu geschrieben: So beschreiben Sie ein gutes Extraktionsschema.
Und wie überprüft man das Ergebnis?
Es gibt eine berechtigte Sorge beim Übergang von rohem OCR zu strukturierten Feldern: Wenn ein Werkzeug das Dokument interpretiert, statt es nur zu transkribieren, wie prüfen Sie dann, ob die Interpretation stimmt?
Die Antwort ist Nachvollziehbarkeit. Jeder Wert, den Ztract extrahiert,
ist an seine genaue Position auf der Quellseite verankert. Klicken Sie
auf total_due in der Ausgabe, und die passende Stelle leuchtet auf dem
Originaldokument auf — eine Zahl zu überprüfen ist damit ein kurzer
Blick, keine Suche. Sie überfliegen die Felder, die schief
aussehen, korrigieren jedes mit einem Klick
(Korrekturen sind kostenlos — nur die Extraktion zählt auf Ihre Seiten
an), und fertig. Sie erhalten die Geschwindigkeit der
Automatisierung, ohne die Prüfbarkeit zu verlieren, die das eigene Lesen
der Quelle bietet.
Was brauchen Sie also?
Eine schnelle Entscheidungshilfe:
- Sie müssen gescannte Dokumente durchsuchen oder archivieren → OCR reicht.
- Sie müssen das Dokument für Screenreader zugänglich machen → OCR reicht.
- Ein Mensch liest Dokumente und trägt die Werte in eine Tabelle, ein ERP oder eine Datenbank ein → Sie brauchen Dokumentenextraktion.
- Sie haben OCR plus Regex ausprobiert und es bricht jedes Mal zusammen, wenn sich ein Layout ändert → Sie brauchen layout-bewusste Extraktion, nicht mehr Regeln.
- Sie brauchen jeden extrahierten Wert bis zur Quelle nachvollziehbar → Sie brauchen Extraktion mit Nachvollziehbarkeit, wie sie die Nebeneinander-Ansicht bietet.
Die meisten Teams, die bei Ztract landen, haben mit OCR angefangen, sind an die Abtippmauer gestoßen und haben gemerkt, dass das fehlende Stück keine bessere Zeichenerkennung war — sondern das Überführen dieser Zeichen in benannte Daten.
Probieren Sie den Unterschied an Ihrem eigenen Dokument aus
Am schnellsten spüren Sie die Lücke, wenn Sie ein Dokument, mit dem Sie tatsächlich arbeiten, durch die Extraktion schicken und sich die strukturierte Ausgabe ansehen — benannte Felder, echte Zahlen, Einzelposten als Zeilen — statt einer Textwand. Neue Konten erhalten 30 kostenlose Seiten, ohne Kreditkarte, was reichlich genügt, um ein paar Ihrer unübersichtlichsten Layouts zu testen.
Und falls Sie einen Arbeitsablauf haben, bei dem Sie nicht sicher sind, ob OCR oder Extraktion das richtige Werkzeug ist, erzählen Sie es uns — wir helfen Ihnen lieber, den richtigen Ansatz zu wählen, als Ihnen den falschen zu verkaufen.