Dateneingabe – angeblich schon mehrfach gelöst
worden

Das Problem, das immer noch nicht gelöst ist

Jede Organisation, die mit externen Dokumenten arbeitet – Rechnungen, Quittungen, Verträge, Kontoauszüge, Laborberichte, Versandpapiere – steht vor dem gleichen Problem: Daten liegen in Papier- oder Bildform vor und müssen in ein System überführt werden. Die Dokumente kommen in Formaten, die vom Absender bestimmt werden, nicht vom Empfänger. Diese Informationen zuverlässig, genau und in großem Umfang in das empfangende System zu bekommen – das ist die praktische Realität der Datenerfassung.

Bemerkenswert an der Geschichte der Datenerfassung ist, dass jede Ära eine Technologie hervorbrachte, die echte Verbesserungen gegenüber dem Vorherigen bot – und dennoch einen neuen Engpass schuf, anstatt den bestehenden zu beseitigen. Die Art der Arbeit änderte sich. Das Arbeitsvolumen tat es nicht.

Die Ären

1950er – 1970er: Die Lochkarten-Ära

Bevor Computer interaktiv waren, war die Datenerfassung ein physischer Fertigungsprozess. Quelldokumente – Bestellungen, Hauptbuchaufzeichnungen, Gehaltsabrechnungen – wurden mit einer Geschwindigkeit von einem Zeichen pro Loch in IBM-Lochkarten umgewandelt. Ein Locher bediente eine Maschine, die einer Schreibmaschine ähnelte, und stanzte Löcher in 80-spaltige Karten. Die Karte war die Daten.

Genauigkeit war wichtiger als Geschwindigkeit, da Fehler nicht sofort sichtbar waren. Ein Prüfdurchlauf – erneutes Stanzen der Karte auf einer separaten Maschine, die Abweichungen markierte – war Standard. Danach wurden Kartenstapel an das Rechenzentrum übergeben, über Nacht verarbeitet und die Ausgabe am nächsten Morgen gedruckt. Bei einer falsch gestanzten Karte dauerte die Korrektur und erneute Einreichung einen ganzen Tag.

Der Engpass waren menschliche Hände und die Batch-Latenz. Die Arbeit war anspruchsvoll: Lochkartenstanzer waren zertifiziert, geprüft und in großen, spezialisierten Abteilungen beschäftigt. Große Organisationen unterhielten ganze Etagen mit Lochkartenstanzern als Infrastruktur – nicht als Notlösung, sondern als anerkannte Produktionsfunktion.

1980er – 1990er: Tabellenkalkulationen ändern das Ziel, nicht die Eingabe

VisiCalc kam 1979 auf den Markt. Lotus 1-2-3 folgte 1983. Mitte der 1980er lief Excel auf dem Macintosh. Diese Werkzeuge veränderten, was mit den Daten nach der Eingabe geschah – Berechnungen, die zuvor einen Batch-Lauf erforderten, erfolgten nun sofort auf dem Desktop. Zum ersten Mal konnte eine einzelne Person einen Datensatz ohne Programmierstab aufbauen, pflegen und analysieren.

Was Tabellenkalkulationen nicht änderten, war, wie die Daten in das System gelangten. Jede Zelle wurde immer noch von einer Person eingegeben, die ein Quelldokument las. Der Engpass verlagerte sich von der Batch-Verarbeitungszeit auf die menschliche Tippgeschwindigkeit und -genauigkeit. Die Dateneingabe wurde demokratisiert – jeder mit einer Tastatur war ein Datenerfasser – 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 mit sich: Formelfehler, die in korrekt aussehenden Zellen versteckt waren. Die Daten wurden zwar genau übertragen, aber nachgelagert falsch verwendet. Das Problem der Genauigkeit spaltete sich in zwei Teile: Übertragungsgenauigkeit und Formelgenauigkeit. Beide erforderten eine menschliche Überprüfung, aber nun war der Prüfer oft dieselbe Person, die die Daten eingegeben hatte – eine schwächere Kontrolle als die unabhängige Verifikation aus der Lochkarten-Ära.

Späte 1990er – 2000er: Die erste OCR-Welle

Die optische Zeichenerkennung reifte in dieser Zeit heran. 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 erneuten Abtippens ganz überspringen.

OCR funktionierte gut bei standardisierten Formularen – Steuerdokumente, die nach einheitlichen Regierungsvorlagen gedruckt wurden, Kontoauszüge von derselben Bank jeden Monat, Versicherungsformulare, die sich seit Jahren nicht geändert hatten. Die Zeichenerkennung war gut genug; das Problem war die Layouterkennung. Bei allem ohne feste, vorhersagbare Struktur produzierte OCR einen Textstrom, der immer noch eine Person erforderte, die die relevanten Werte las, lokalisierte und in das Zielsystem eingab. 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 bearbeiten als eine leere Zelle – man musste nun Fehler in vorhandenem Text finden und korrigieren, anstatt einfach genau zu tippen. Für Dokumenttypen mit ausreichendem Volumen und Layoutkonsistenz funktionierte die vorlagenbasierte OCR mit Validierungsregeln. Bei gemischten Quellen war es oft immer noch schneller, neu zu tippen, als zu korrigieren.

2000er – 2010er: Digitale Dokumente und das Integrationsproblem

Als ERP-Systeme zur Standard-Infrastruktur in Unternehmen wurden und Lieferanten begannen, PDFs direkt aus der Software statt vom Papier zu generieren, entstand eine berechtigte Erwartung: Digital-zu-Digital sollte nahtlos funktionieren. Das Quelldokument war bereits eine Datei. Das Zielsystem war bereits digital. Das Transkriptionsproblem schien gelöst.

Das Transkriptionsproblem wurde durch das Integrationsproblem abgelöst. 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 für deren Pflege. Die lange Liste kleinerer Lieferanten, einmaliger Anbieter und Dokumenttypen außerhalb des EDI-Standards erforderte weiterhin manuelle Bearbeitung.

Da PDF als Format für den Druck und nicht für die Datenextraktion optimiert war, mussten selbst digitale Dokumente oft aufwändig geparst werden. Die Arbeit verlagerte sich von Schreibkräften auf IT-Teams, die Integrationen aufbauten und pflegten – während der unstrukturierte Rest (Rechnungen von Lieferanten, die den Integrationsaufwand nicht rechtfertigten, Kontoauszüge kleinerer Banken, Dokumente in nicht standardisierten Formaten) weiterhin manuell bearbeitet wurde.

2010er: Regelbasierte Automatisierung

Robotic-Process-Automation-Tools gingen das Problem der Dateneingabe an, indem sie das menschliche Vorgehen automatisierten: Bildschirm lesen, Felder anklicken, Werte eintippen. Ein Bot konnte eine Rechnung in Sekunden statt Minuten verarbeiten. Für hochvolumige, repetitive Arbeitsabläufe mit einem stabilen Quellformat lieferte RPA echte Produktivitätssteigerungen – nicht nur inkrementell, sondern eine Reduzierung der Bearbeitungszeit 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. Änderte sich das Layout des Quelldokuments – ein neuer Lieferant, eine neu gestaltete PDF-Vorlage, ein anderes Buchhaltungssystem auf 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 wenigen stabilen, hochvolumigen Workflows konnten diese Wartungskosten absorbieren – die Einsparungen pro Dokument rechtfertigten eine dedizierte Bot-Wartungsfunktion. Organisationen mit vielfältigen, variablen Dokumentenquellen konnten das nicht. Der Engpass verlagerte sich von der manuellen Dateneingabe zur Regelentwicklung und Bot-Wartung. Die Datenerfasser wurden faktisch zu Bot-Entwicklern.

Was sich in den 2020ern tatsächlich änderte

Jede frühere Technologie funktionierte durch Musterabgleich mit bekannten Vorlagen oder vordefinierten Regeln. OCR fand Zeichen. RPA matchte Feldpositionen. EDI bildete bekannte Transaktionscodes ab. Alle erforderten, dass das Quelllayout im Voraus bekannt war – weshalb sie alle versagten, wenn sich das Layout änderte.

KI-Extraktion funktioniert anders: Sie liest ein Dokument semantisch, wie ein Mensch, und versteht die Feldbedeutung unabhängig von Bezeichnung oder Position. „RECHNUNGSNR.“, „INV#“, „Rechnungsreferenz“ und „Ref:“ in vier Dokumenten von vier Lieferanten bedeuten alle dasselbe – und ein Sprachmodell weiß das, ohne dass man es ihm sagt. Der von Ihnen definierte Spaltenname (Rechnungsnummer) ist eine Anweisung, das Konzept zu finden, kein Schlüsselwort, das mit einer bestimmten Zeichenfolge oder Region übereinstimmen muss.

Dies beseitigt die Layout-Abhängigkeit, die jeden früheren Ansatz anfällig machte. Eine neue Rechnung eines Lieferanten ist keine neue Regel, die man schreiben muss – es ist nur ein weiteres Dokument, das mit demselben Spaltensatz verarbeitet wird. Die Spaltendefinitionen, die Sie für den ersten Lieferanten erstellt haben, funktionieren auch beim fünfzigsten, unabhängig davon, wie unterschiedlich deren Dokumente formatiert sind.

Der Engpass, nach Ära

Wie die Arbeit heute aussieht

KI-Extraktion eliminiert die Dateneingabe nicht – sie verändert, worin diese Arbeit besteht. Die Kernfrage verschiebt sich von „Wie extrahiere ich diesen Wert aus diesem Dokument?" zu „Welche Werte benötige ich konsistent über alle Dokumente hinweg?". Das ist eine andere Fähigkeit als schnelles, genaues Tippen. Es ähnelt eher dem Schema-Design.

• Spaltendefinition ersetzt Dokumentenlesen. Sie legen einmal fest, was Sie brauchen — Rechnungsnummer, Lieferantenname, Fälliger Betrag (nur Zahl), Ausstellungsdatum (JJJJ-MM-TT) — und diese Definition gilt für jedes Dokument in jedem weiteren Batch. Das Lesen und Finden der Felder wird an das Modell delegiert.
• Formatvorgaben kommen in den Spaltennamen. „Betrag (nur Zahl, ohne Währungssymbol)" ist gleichzeitig Spaltenname und Formatierungsanweisung. Was früher einen Nachbearbeitungsschritt erforderte, wird jetzt beim Extrahieren erledigt.
• Prüfung verlagert sich von Zeichen- auf Zeilenebene. Statt zu kontrollieren, 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 Lieferanten entspricht. Anomalieerkennung statt Korrekturlesen.
• Menge wird zur Nebensache. Fünfzig Rechnungen benötigen denselben Spaltenaufbau wie eine. Der Aufwand, der zuvor linear mit der Dokumentenanzahl stieg, skaliert jetzt mit der Anzahl unterschiedlicher Dokumentenschemata — und die ist in der Regel deutlich kleiner als die Dokumentenanzahl.

Auch die Fehlerbilder sind anders. KI-Extraktion scheitert, wenn Spaltennamen mehrdeutig sind, wenn Dokumente bis zur Unkenntlichkeit beschädigt sind oder wenn ein Feld in einem Quelldokument tatsächlich nicht existiert. Das sind Spezifikationsfehler — lösbar durch Verfeinerung der Spaltendefinition — und keine Fehler der Tippgeschwindigkeit, die entweder schnellere oder mehr Bearbeiter erfordert hätten.

Häufig gestellte Fragen