Datenerfassung hätte schon mehrfach gelöst sein sollen
– und ist es doch nicht
Die Tabellenkalkulation sollte die manuelle Datenerfassung überflüssig machen. Dann kam OCR. Dann ERP-Integrationen. Dann Robotic Process Automation. Das Papier kam weiterhin. Jede Technologie hat tatsächlich etwas verändert – aber der Engpass verschwand nicht; er verlagerte sich. Wer versteht, wohin er sich verlagert hat, versteht auch, warum sich KI-Extraktion von allem unterscheidet, was davor kam.
Das Problem, das immer noch nicht gelöst wird
Jede Organisation, die mit externen Dokumenten arbeitet — Rechnungen, Quittungen, Verträge, Kontoauszüge, Laborberichte, Frachtpapiere — steht vor demselben Problem: Daten existieren in Papier- oder Bildform und müssen in einem System existieren. Die Dokumente kommen in Formaten an, die der Absender bestimmt, nicht der Empfänger. Diese Informationen zuverlässig, genau und in großem Umfang in das empfangende System zu bringen, ist das, was Datenerfassung in der Praxis bedeutet.
Die Geschichte der Datenerfassung folgt einem Muster: Jede Ära brachte eine Technologie hervor, die echte Verbesserungen gegenüber dem Vorherigen bot, und jede schuf einen neuen Engpass, anstatt den alten zu beseitigen. Die Art der Arbeit änderte sich. Das Arbeitsvolumen nicht.
Die Epochen
1950er – 1970er: Die Lochkarten-Ära
Bevor Computer interaktiv waren, war Datenerfassung ein physischer Fertigungsprozess. Quelldokumente — Bestellungen, Hauptbuchaufzeichnungen, Lohnunterlagen — wurden Spalte für Spalte in IBM-Lochkarten umgewandelt. Jede der 80 Spalten einer Karte enthielt ein einzelnes Zeichen, kodiert durch das Stanzen von ein bis drei Löchern in dieser Spalte. Ein Lochkartenstanzer arbeitete an einer Maschine, die einer Schreibmaschine ähnelte, und rückte die Karte mit jedem Tastendruck um eine Spalte vor. Die Karte war die Daten.
Genauigkeit war wichtiger als Geschwindigkeit, weil Fehler nicht sofort sichtbar waren. Ein Prüfdurchgang — das erneute Stanzen der Karte auf einer separaten Maschine, die Abweichungen markierte — war Standardpraxis. Danach wurden Kartenstapel an das Rechenzentrum übergeben, über Nacht verarbeitet, und die Ergebnisse wurden am nächsten Morgen gedruckt. Wenn eine Karte falsch gestanzt wurde, dauerte die Korrektur und Wiedereinreichung einen ganzen Tag.
Der Engpass waren menschliche Hände und Batch-Latenz. Die Arbeit war qualifiziert: Lochkartenstanzer waren zertifiziert, getestet und in großen spezialisierten Abteilungen beschäftigt. Große Organisationen unterhielten ganze Etagen von Lochkartenstanzern als Infrastruktur — nicht als Notlösung, sondern als anerkannte Produktionsfunktion.
1980er–1990er Jahre: Tabellenkalkulationen ändern das Ziel, nicht die Eingabe
VisiCalc kam 1979 auf den Markt. Lotus 1-2-3 folgte 1983. Mitte der 1980er Jahre lief Excel auf dem Macintosh. Diese Tools veränderten, was mit den Daten nach der Eingabe geschah – Berechnungen, die zuvor einen Batch-Lauf erforderten, liefen nun sofort auf dem Desktop. Zum ersten Mal konnte eine einzelne Person einen Datensatz ohne Programmierstab erstellen, pflegen und analysieren.
Was Tabellenkalkulationen nicht änderten, war der Weg der Daten in das System. Jede Zelle wurde weiterhin von einer Person getippt, die ein Quelldokument las. Der Engpass verlagerte sich von der Batch-Verarbeitungszeit hin zur menschlichen Tippgeschwindigkeit und -genauigkeit. Die Datenerfassung wurde demokratisiert – jeder mit einer Tastatur war ein Datenerfassungsoperator –, aber die grundlegende Tätigkeit, das Lesen eines Dokuments und das Eintippen von Werten in Zellen, war identisch mit dem, was Lochkartenstanzer auf anderer Hardware getan hatten.
Die Ära der Tabellenkalkulation brachte auch eine neue Fehlerquelle: Formelfehler, die in korrekt aussehenden Zellen verborgen waren. Die Daten konnten korrekt übertragen, aber nachgelagert falsch verwendet werden. Das Genauigkeitsproblem spaltete sich in zwei Teile: Übertragungsgenauigkeit und Formelgenauigkeit. Beide erforderten eine menschliche Prüfung, aber nun war der Prüfer oft dieselbe Person, die die Daten eingegeben hatte – eine schwächere Kontrolle als die unabhängige Verifikation der Lochkarten-Ära.
Späte 1990er–2000er Jahre: Die erste OCR-Welle
Die optische Zeichenerkennung reifte in dieser Zeit. Flachbettscanner wurden zur Büroausstattung. Produkte wie ABBYY FineReader konnten gescannte Dokumente mit angemessener Genauigkeit bei sauberen gedruckten Quellen in maschinenlesbaren Text umwandeln. Das Versprechen war real: Wenn man ein Dokument scannen konnte, konnte man den Schritt des Abtippens komplett überspringen.
OCR funktionierte gut bei standardisierten Formularen – Steuerdokumente, die nach konsistenten staatlichen Vorlagen gedruckt wurden, Kontoauszüge derselben Bank jeden Monat, Versicherungsformulare, die sich seit Jahren nicht geändert hatten. Die Zeichenerkennung war gut genug; die Layouterkennung war das Problem. Bei allem ohne feste, vorhersehbare Struktur produzierte OCR einen Textstrom, der weiterhin eine Person erforderte, die die relevanten Werte las, lokalisierte und in das Zielsystem eintippte. Die Zeichenerkennung sparte das Tippen; sie sparte nicht das Verständnis.
Der Engpass verlagerte sich von der Tippgeschwindigkeit zum Korrekturaufwand. Die OCR-Ausgabe für ein nicht standardisiertes Dokument war oft schwieriger zu handhaben als eine leere Zelle – man musste nun Fehler in vorhandenem Text finden und beheben, statt einfach korrekt zu tippen. Für Dokumenttypen mit ausreichendem Volumen und Layout-Konsistenz funktionierte vorlagenbasierte OCR mit Validierungsregeln. Bei gemischten Quellen war es oft schneller, neu zu tippen als zu korrigieren. Unsere Aufschlüsselung der KI-OCR-Genauigkeit im Vergleich zur traditionellen OCR zeigt, wo diese Lücke entsteht.
2000er–2010er Jahre: Digitale Dokumente und das Integrationsproblem
Als ERP-Systeme zur Standard-Infrastruktur von Unternehmen wurden und Lieferanten begannen, PDFs per Software statt per Papierdruck zu erzeugen, entstand eine berechtigte Erwartung: Digital-zu-digital sollte nahtlos funktionieren. Das Quelldokument war bereits eine Datei. Das Zielsystem war bereits digital. Das Transkriptionsproblem war damit sicherlich gelöst.
Das Integrationsproblem ersetzte das Transkriptionsproblem. Jedes ERP hatte sein eigenes Importformat. Jeder Lieferant hatte seine eigene PDF-Vorlage. EDI (elektronischer Datenaustausch) standardisierte Transaktionen zwischen großen Handelspartnern – aber nur für Paare von Organisationen mit dedizierten Integrationsvereinbarungen und IT-Ressourcen, um diese zu pflegen. Der lange Schwanz kleinerer Lieferanten, einmaliger Anbieter und Dokumenttypen außerhalb des EDI-Standards erforderte weiterhin menschliche Verarbeitung.
In der Zwischenzeit bedeutete PDF als ein für den Druck optimiertes Format, dass selbst digitale Dokumente oft Parsing-Arbeit erforderten. Die Arbeit verlagerte sich von Schreibkräften zu IT-Teams, die Integrationen aufbauten und pflegten – wobei der unstrukturierte Rest – Rechnungen von Lieferanten, die die Integrationskosten nicht rechtfertigten, Kontoauszüge kleinerer Banken, Dokumente in nicht standardisierten Formaten – weiterhin manuell bearbeitet wurde.
2010er Jahre: Regelbasierte Automatisierung
Robotic-Process-Automation-Tools näherten sich dem Problem der Datenerfassung, indem sie automatisierten, was Menschen taten: einen Bildschirm lesen, Felder anklicken, Werte eingeben. Ein Bot konnte eine Rechnung in Sekunden statt Minuten verarbeiten. Für hochvolumige, repetitive Workflows mit einem stabilen Quellformat lieferte RPA echte Produktivitätsgewinne – nicht inkrementell, sondern eine Reduzierung der Verarbeitungszeit pro Dokument um eine Größenordnung.
Die Fragilität war der Preis. RPA-Bots arbeiteten nach Regeln: Finde das Feld „Rechnungsnummer“ in Region X des Dokuments, extrahiere den Wert, füge ihn in Feld Y des Systems ein. Wenn sich das Layout des Quelldokuments änderte – ein neuer Lieferant, eine neu gestaltete PDF-Vorlage, ein anderes Buchhaltungssystem auf der Senderseite – brach die Regel und der Bot funktionierte nicht mehr. Die Überwachung auf Fehler und die Aktualisierung von Regeln bei Layoutänderungen wurden zu einem kontinuierlichen operativen Aufwand.
Organisationen mit einigen wenigen stabilen, hochvolumigen Workflows konnten diese Wartungskosten absorbieren – die Einsparungen pro Dokument rechtfertigten eine dedizierte Bot-Wartungsfunktion. Organisationen mit vielfältigen, variablen Dokumentquellen konnten das nicht. Der Engpass verlagerte sich von der menschlichen Datenerfassung zur Regelentwicklung und Bot-Wartung. Die Datenerfassungsmitarbeiter wurden de facto zu Bot-Entwicklern.
Was sich in den 2020er-Jahren wirklich geändert hat
Jede frühere Technologie funktionierte durch Musterabgleich mit bekannten Vorlagen oder vordefinierten Regeln. OCR erkannte Zeichen. RPA passte Feldpositionen an. EDI ordnete bekannte Transaktionscodes zu. Alle erforderten, dass das Quelllayout im Voraus bekannt war – genau deshalb scheiterten sie, sobald sich das Layout änderte.
KI-Extraktion funktioniert anders: Sie liest ein Dokument semantisch, so wie es ein Mensch tut, und versteht die Bedeutung von Feldern unabhängig von Bezeichnung oder Position. "INVOICE NO.", "INV#", "Bill Reference" und "Ref:" auf vier Dokumenten von vier Lieferanten bedeuten alle dasselbe – und ein Sprachmodell weiß das, ohne es erklärt zu bekommen. Die von Ihnen definierte Spalte (Invoice Number) ist eine Anweisung, das Konzept zu finden, und kein Schlüsselwort, das mit einer bestimmten Zeichenfolge oder Region abgeglichen wird.
Dadurch entfällt die Layout-Abhängigkeit, die jeden früheren Ansatz anfällig machte. Eine Rechnung eines neuen Lieferanten ist keine neue Regel, die man schreiben müsste; sie ist nur ein weiteres Dokument, das mit denselben Spalten verarbeitet wird. Die Spaltendefinitionen, die Sie für den ersten Lieferanten erstellt haben, funktionieren auch beim fünfzigsten – egal wie unterschiedlich die Dokumente formatiert sind. Für einen genaueren Blick auf den Mechanismus lesen Sie unsere Erklärung zu wie KI Daten ohne Vorlagen extrahiert.
Der Engpass, nach Epoche
Endlich gelesen, ist die Geschichte der Datenerfassung eine Abfolge von verlagerten Engpässen: Jede Lösung einer Epoche wurde zur Wartungslast der nächsten.
| Epoche | Primärer Ansatz | Wo menschliche Arbeit steckte | Was es ausbremste |
|---|---|---|---|
| 1950er–1970er | Lochkartenstanzen | Physisches Stanzen von Karten, Verifikationsdurchläufe | Batch-Latenz; jeder Fehler erforderte die Einreichung am nächsten Tag |
| 1980er–1990er | Tabellenkalkulationseingabe | Eintippen von Quelldokumentwerten in Zellen | Menschliche Tippfehler; Formelfehler; keine Automatisierung der Übertragung |
| Späte 1990er–2000er | OCR + Scannen | Korrekturdurchläufe der OCR-Ausgabe | Layoutvariation; nicht standardisierte Dokumente waren langsamer zu korrigieren als neu zu tippen |
| 2000er–2010er | ERP-Integrationen / EDI | IT-Teams bauten und pflegten Integrationen | Langer Schwanz von Nicht-EDI-Lieferanten; Integrationskosten schlossen kleinere Volumina aus |
| 2010er | RPA-Bots | Regeln erstellen, überwachen, bei Layoutänderungen aktualisieren | Layout-Zerbrechlichkeit; jede Quelländerung erforderte Regelwartung |
| 2020er | KI-Extraktion | Definition des Ausgabeschemas (Spaltennamen) | Präzision der Spaltennamen; ungewöhnliche Dokumentstrukturen; Bildqualität |
Wie die Arbeit heute aussieht
KI-Extraktion beseitigt die Datenerfassung nicht – sie verändert, worin diese Arbeit besteht. Die Kernfrage verschiebt sich von „Wie bekomme ich diesen Wert aus diesem Dokument?" zu „Welche Werte brauche ich, konsistent, über alle Dokumente hinweg?". Das ist eine andere Fähigkeit als schnelles, genaues Tippen. Es ähnelt eher dem Schema-Design.
- Spaltendefinition ersetzt das Lesen von Dokumenten. Sie legen einmal fest, was Sie wollen –
Invoice Number,Vendor Name,Amount Due (number only),Issue Date (YYYY-MM-DD)– und diese Definition gilt für jedes Dokument in jedem nachfolgenden Batch. Das Lesen und Auffinden von Feldern wird dem Modell übertragen. - Formatanforderungen fließen in den Spaltennamen ein. „Amount (number only, no currency symbol)" ist gleichzeitig ein Spaltenname und eine Formatierungsanweisung. Was zuvor einen Nachbearbeitungsschritt erforderte, wird jetzt zum Zeitpunkt der Extraktion erledigt.
- Die Verifizierung verschiebt sich von der Zeichenebene auf die Zeilenebene. Statt zu prüfen, ob jeder Tastendruck mit der Quelle übereinstimmt, prüfen Sie, ob jede extrahierte Zeile sinnvoll ist – ob die Beträge plausibel sind, ob die Daten im richtigen Bereich liegen, ob der Lieferantenname einem bekannten Anbieter entspricht. Anomalieerkennung statt Korrekturlesen.
- Volumen wird zur Nebensache. Für fünfzig Rechnungen ist dieselbe Spalteneinrichtung nötig wie für eine. Die Arbeit, die zuvor linear mit der Dokumentanzahl skalierte, skaliert nun mit der Anzahl unterschiedlicher Dokument-Schemas – die typischerweise viel kleiner ist als die Dokumentanzahl.
Auch die Fehlerbilder sind andere. KI-Extraktion schlägt fehl, wenn Spaltennamen mehrdeutig sind, wenn Dokumente bis zur Unkenntlichkeit beschädigt sind oder wenn ein Feld in einem Quelldokument wirklich nicht existiert. Das sind Spezifikationsfehler – lösbar durch die Verfeinerung der Spaltendefinition – und keine Fehler der Tippgeschwindigkeit, die entweder schnellere Operatoren oder mehr davon erfordert hätten.
Der Spaltendefinitions-Ansatz funktioniert bei Rechnungen, Quittungen, Kontoauszügen, Laborberichten und Versanddokumenten – bei jedem Dokumenttyp, bei dem Sie wissen, welche Felder Sie benötigen, bevor Sie ihn verarbeiten.
KI-Extraktion ausprobierenHäufig gestellte Fragen
Wenn KI-Extraktion zuverlässig ist, warum ist manuelle Datenerfassung immer noch üblich?
Verzögerte Einführung und die Tatsache, dass „zuverlässig" kontextabhängig ist. In Bereichen mit hohem Risiko, wo eine falsche Zahl rechtliche oder finanzielle Folgen hat, erfordert jeder automatisierte Ansatz einen Verifizierungsschritt – was Menschen im Prozess hält, auch wenn die Aufgabe eher Anomalieerkennung als vollständige Transkription ist. Es gibt auch echte Einrichtungskosten bei der erstmaligen Definition Ihres Spaltenschemas; Organisationen mit geringem Dokumentvolumen sehen möglicherweise nicht genug Durchsatz, um dies zu rechtfertigen. Manuelle Erfassung bleibt üblich, aus demselben Grund, aus dem die Einführung von OCR und RPA unvollständig war: Der Ansatz funktioniert für einige Workflows besser als für andere.
Was ist mit den Lochkartenstanzer-Personal passiert? Wiederholt sich diese Verdrängung?
Lochkartenstanzer wurden weitgehend verdrängt, als interaktive Datenverarbeitung die Stapelverarbeitung von Karten obsolet machte – diese spezifische Rolle verschwand praktisch. Aber Datenerfassung als Berufskategorie wuchs eher, als dass sie schrumpfte: Die Zahl der Menschen, die Daten in Tabellenkalkulationen und Formulare eingaben, übertraf die Zahl der Lochkartenstanzer, die vor ihnen kamen. Die Arbeit änderte ihre Form. Ob KI-Extraktion dieselbe Ausweitung auf eine andere Art von Arbeit (Schema-Design, Qualitätssicherung, Ausnahmebehandlung) erzeugt oder eine echte Reduzierung der Arbeitsnachfrage, hängt davon ab, wie das Dokumentvolumen skaliert – was wirklich ungewiss ist und je nach Branche variiert.
Funktioniert KI-Extraktion bei handschriftlichen Dokumenten?
Bei lesbarer Handschrift, ja – derselbe semantische Ansatz gilt. Eine handschriftliche Rechnung mit „TOTAL DUE: $847.50" in der Handschrift einer Person ist ein erkennbares Feld, unabhängig von der Schriftart. Die Genauigkeit sinkt bei schlechter Handschrift, gemischter Druck- und Schreibschrift oder Dokumenten, bei denen handschriftliche Werte als Korrekturen über gedruckte Originale gelegt sind. Bei handschriftlichen Dokumenten, bei denen Genauigkeit entscheidend ist, bleibt ein Verifizierungsschritt unabhängig von der Extraktionsmethode Standardpraxis.
RPA sollte das lösen. Warum war das nicht genug?
RPA löste das Problem für Dokumenttypen mit stabilen, konsistenten Layouts – und in diesen Fällen funktionierte es gut und tut das weiterhin. Die Einschränkung war, dass die meisten realen Dokument-Workflows Layout-Variationen haben: mehrere Lieferanten, mehrere Banken, Dokumente aus verschiedenen Ländern oder Softwareversionen. RPA erforderte eine Regel pro Layout, und die Pflege dieser Regeln bei sich ändernden Layouts war ein fortlaufender Kostenpunkt. KI-Extraktion hat keine Regel-pro-Layout-Anforderung: Dieselbe Spaltendefinition funktioniert über alle Layouts hinweg ohne Quellkonfiguration.
Was bedeutet „semantisches Verständnis" in der Praxis?
„Total Amount Due", „Grand Total", „Amount Payable" und „Balance Due" sind unterschiedliche Zeichenfolgen, die an verschiedenen Positionen in verschiedenen Dokumenten erscheinen – aber sie repräsentieren dasselbe Konzept. Ein Modell mit semantischem Verständnis identifiziert das Feld anhand seiner Bedeutung und nicht anhand seiner Beschriftung oder Position. Dies gilt auch für Werte außerhalb von Tabellenpositionen: Ein Gesamtbetrag in einem Fußzeilenabsatz wird als Gesamtsumme erkannt, auch wenn er nicht in einer Spalte mit der Bezeichnung „Total" steht. Es ist dieselbe Schlussfolgerung, die ein menschlicher Leser zieht, wenn er ein unbekanntes Dokumentformat zum ersten Mal verarbeitet – erweitert auf jedes Dokument in einem Batch.
Benötigt KI-Extraktion Vorlagen oder Trainingsdaten?
Nein. Jede frühere Ära in dieser Geschichte erforderte, dass das Dokumentformat im Voraus definiert wurde – sei es als Lochkarten-Layout, als OCR-Vorlagenzone, als EDI-Zuordnung oder als RPA-Regel. KI-Extraktion überspringt diesen Schritt: Sie benennen die Spalten, die Sie möchten, und das Modell liest jedes Dokument, um diese Werte zu finden. Es müssen keine Beispiele gesammelt, keine Vorlage pro Lieferant erstellt und nichts neu aufgebaut werden, wenn ein Anbieter sein Formular neu gestaltet.