KI-Dateneingabe ohne Code:
Dokumentdaten extrahieren ohne Modelltraining

Der alte Weg: Warum Dokumentenextraktion früher Entwickler und Trainingsdaten erforderte

Um zu verstehen, was „kein Training“ bedeutet, hilft es zu wissen, was Training früher kostete. Vor Vision-Language-Modellen basierte die Dokumentenextraktion auf einem zweistufigen Stack: OCR zur Umwandlung von Bildern in Text und Machine-Learning-Klassifikatoren zur Zuordnung von Text zu Feldern. Die OCR-Ebene übernahm die Zeichenerkennung. Die ML-Ebene kümmerte sich um alles andere – und das war der teure Teil.

Das Training eines traditionellen ML-Modells für die Dokumentenextraktion erforderte annotierte Beispiele: Hunderte von Dokumenten, in denen ein Mensch manuell markiert hatte, welcher Text die Rechnungsnummer, welcher das Datum und welcher die Gesamtsumme war. UiPaths eigene Dokumentation gibt 20 bis 50 annotierte Stichproben pro regulärem Feld an – eine Rechnungsvorlage mit 10 Feldern erfordert also 200 bis 500 annotierte Dokumente, bevor das Modell produktionsreife Genauigkeit erreicht. Für Spaltenfelder wie Positionszeilen steigt die Anforderung auf 50 bis 200 Dokumente pro Spalte. Und das für ein einziges Dokumentenlayout. Ein neuer Lieferant mit einem anderen Rechnungsformat bedeutet neue Trainingsdaten oder eine geringere Genauigkeit durch ein Modell, das auf mehrere Layouts ausgelegt ist, für die es nicht optimiert wurde.

Der Zeitplan: 2 bis 4 Wochen zum Sammeln und Annotieren von Trainingsbeispielen, weitere 1 bis 2 Wochen für Modelltraining und -bewertung sowie ein fortlaufender Wartungszyklus, bei dem neue Dokumentenlayouts ein erneutes Training auslösen. Das Team benötigte: einen Datenannotator mit Domänenkenntnissen, einen Machine-Learning-Ingenieur zur Konfiguration der Trainingspipeline und einen Entwickler zur Integration des resultierenden Modells in ein Produktionssystem. Gesamtzeit bis zur ersten nutzbaren Extraktion: in der Regel 3 bis 6 Wochen. Gesamtkosten: gemessen am Ingenieursgehalt, nicht am Software-Abonnement.

Dies ist die Welt, die „KI-Dokumentenextraktion“ für jeden bedeutete, der sie vor 2023 evaluierte – und der Grund, warum die Annahme „dafür braucht man Entwickler“ fortbesteht. Die Annahme ist veraltet, nicht unbegründet.

Der Wandel: Wie KI Dokumente heute ohne Training liest

Die Technologie, die die Wirtschaftlichkeit der Dokumentenextraktion verändert hat, ist das Vision Language Model (VLM) – eine KI-Klasse, die Dokumente wie ein Mensch verarbeitet: durch Betrachten der gesamten Seite und Verstehen der Bedeutung jeder Information, nicht durch Musterabgleich aus beschrifteten Beispielen.

Ein VLM lernt nicht aus Ihren Rechnungen. Es wurde mit Millionen von Dokumenten vortrainiert – Rechnungen, Quittungen, Kontoauszüge, Verträge, Formulare, Berichte – über verschiedene Layouts, Sprachen und Qualitätsstufen hinweg. Während des Vortrainings lernte das Modell, visuelle Muster mit semantischen Rollen zu verknüpfen: Eine fette Zahl unten rechts neben dem Wort „Gesamtbetrag“ ist der Rechnungsbetrag. Ein Datum oben auf der Seite im Format „Rechnungsdatum: TT.MM.JJJJ“ ist das Rechnungsdatum. Eine Spalte mit der Bezeichnung „Menge“ neben „Einzelpreis“ bedeutet die Stückzahl – und die Zahl danach multipliziert mit dem Einzelpreis ist der Zeilenbetrag. Das Modell lernte diese Zusammenhänge, indem es sie millionenfach in Millionen von Dokumenten sah, nicht indem ihm gesagt wurde, wonach es auf Ihrer speziellen Rechnung suchen soll.

Das bedeutet „Null Training“ tatsächlich. Das Modell versteht bereits Rechnungen, Quittungen, Kontoauszüge, Bestellungen, Verträge und Dutzende anderer Dokumenttypen – nicht weil Sie es trainiert haben, sondern weil es massiv im visuellen Dokumentenverständnis vortrainiert wurde. Wenn Sie Ihre erste Rechnung hochladen, lernt das Modell nicht. Es wendet an, was es bereits weiß, auf ein Dokument, das es noch nie gesehen hat. Derselbe Mechanismus funktioniert bei einem Foto einer zerknitterten Quittung von einer Handykamera, einem gescannten PDF von einem 15 Jahre alten Multifunktionsdrucker und einer digitalen Rechnung aus SAP – unterschiedliche visuelle Qualität, gleiche zugrunde liegende semantische Struktur.

Diese Unterscheidung erklärt, warum No-Code-Tools ab dem ersten Tag ohne Einrichtung funktionieren. Wenn Extraktion ein Layout-Training erfordern würde, bräuchten Sie einen Entwickler für Trainingspipelines und einen Fachexperten zur Annotation von Beispielen, bevor das Tool etwas Nützliches liefert. Da VLMs semantisch extrahieren, ist die einzige benötigte Eingabe was extrahiert werden soll – und das wissen Sie bereits.

Firstsources Forschung zu VLM-basierter Dokumentenverarbeitung ergab, dass traditionelle OCR-Pipelines aufgrund der kaskadierenden Fehler separater OCR → Layoutanalyse → Feldextraktionsschritte Fehlerraten von 15-20 % bei der Informationsextraktion aufweisen. VLMs schließen diese Lücke, indem sie visuelles Layout, Textinhalt und semantische Bedeutung als einen einzigen, einheitlichen Schritt verarbeiten – keine kaskadierenden Fehler, keine Zwischenergebnisse, die sich verschlechtern, keine Vorlagen, die gewartet werden müssen, wenn ein Lieferant seinen Rechnungskopf neu gestaltet.

Für einen tieferen Vergleich der technischen Architekturunterschiede behandelt unsere Einführung in die KI-Dateneingabe, wie sich VLMs auf Mechanismenebene von OCR unterscheiden.

Von Spaltennamen zu strukturierten Daten: Wie No-Code-Extraktion in der Praxis funktioniert

Wenn Sie kein Modell trainieren oder Integrationscode schreiben müssen, was tun Sie dann? Der Workflow basiert auf einer einzigen Designentscheidung: Statt der Eingabe (Vorlagen, Zonen, Regeln) beschreiben Sie die Ausgabe. So sieht das aus.

Der Kernmechanismus ist die benutzerdefinierte Spaltenextraktion: Sie geben die gewünschten Feldnamen in ein Textfeld ein – „Rechnungsnummer“, „Lieferantenname“, „Bestellnummer“, „Gesamtsumme“, „Fälligkeitsdatum“ – und die KI lokalisiert jeden Wert an beliebiger Stelle im Dokument, indem sie dessen semantische Bedeutung versteht, nicht seine Position. Die eingegebenen Spaltennamen werden zu den exakten Überschriften Ihrer endgültigen Tabelle. Sie beschreiben die Datenstruktur, die Sie erhalten möchten, nicht das Dokument, das Sie eingeben.

Dies ist die grundlegende Umkehrung, die No-Code-Extraktion ermöglicht. Vorlagenbasierte Tools verlangen, dass Sie das Dokument markieren: „Zeichnen Sie ein Kästchen um die Rechnungsnummer hier, zeichnen Sie ein Kästchen um das Datum dort.“ Sie konfigurieren das Tool, um ein Layout zu verstehen. Die spaltenbasierte Extraktion fordert Sie auf, zu beschreiben, was Sie wollen: „Gib mir die Rechnungsnummer, das Datum und die Gesamtsumme.“ Die KI übernimmt die Zuordnung – über jedes Layout, von jedem Lieferanten, in jedem Format.

Über die direkte Extraktion gedruckter Felder hinaus unterstützt die No-Code-KI zwei weitere Modi, die erweitern, was Sie tun können, ohne eine Formel zu berühren oder ein Skript zu schreiben:

Berechnete Spalten führen Berechnungen während der Extraktion durch und geben das Ergebnis aus – nicht Rohdaten, die Sie später verarbeiten müssen. Ein Auftrag listet Menge und Einzelpreis auf, druckt aber nicht den Zeilenbetrag. Definieren Sie eine Spalte namens Zeilenbetrag (Menge × Einzelpreis) und die KI extrahiert beide Quellwerte, multipliziert sie und schreibt das Ergebnis in einem Durchgang in Ihre Tabelle. Keine Excel-Formeln nach der Extraktion. Derselbe Mechanismus behandelt zeilenübergreifende Aggregation (Summieren aller Artikel in einem Abschnitt), bedingte Logik (Markieren von Abweichungen zwischen berechneten und gedruckten Summen) und feste Parameterreferenzen (Anwenden eines Steuersatzes, der nicht im Dokument steht).

Abgeleitete Spalten lassen die KI eine Einschätzung darüber treffen, welche Kategorie, welcher Tag oder welches Label auf ein Dokument zutrifft – und füllen dies in Ihre Tabelle. Eine Quittung eines Restaurants sagt nicht „Kategorie: Verpflegung“. Aber Sie benötigen Ausgabenkategorien für die Buchhaltung. Definieren Sie eine Spalte namens Kategorie (Optionen: Verpflegung/Transport/Büro/Sonstiges). Die KI liest jede Quittung – eine Mittagsquittung, eine Tankstellenquittung, eine Büromaterialquittung – und bestimmt die richtige Kategorie. Extraktion und Klassifizierung erfolgen gleichzeitig über einen gesamten Stapel. Abgeleitete Spalten funktionieren bei jedem Dokumenttyp gleich: Markieren von Eilaufträgen aus Lieferscheinen, Erkennen von Währungen aus internationalen Rechnungen, Identifizieren von Dokumentuntertypen aus Versicherungszertifikaten.

Diese drei Modi – direkte Extraktion, Berechnung und Ableitung – laufen auf eine einzige betriebliche Realität hinaus: Sie geben ein, was Sie wollen, laden hoch, was Sie haben, und erhalten eine strukturierte Tabelle. Keine Trainingsdaten. Kein Vorlageneditor. Kein Code.

Die Stapelverarbeitung erweitert dies auf Mengen. Laden Sie 50 Rechnungen von 15 verschiedenen Lieferanten hoch. Geben Sie Ihre Spaltennamen einmal ein. Die KI verarbeitet alle 50, identifiziert jedes Feld in jeder Layoutvariante und exportiert eine einzige Tabelle mit 50 Zeilen – eine pro Dokument –, in der jedes Feld in der richtigen Spalte landet. Was einen Nachmittag manueller Eingabe dauerte, dauert jetzt ein paar Minuten zum Hochladen und Prüfen.

Das Google Sheets-Add-on: Codefreie Extraktion direkt in Ihrer Tabelle

Senkt der webbasierte Workflow die Hürde von „Sie brauchen einen Entwickler" auf „Sie brauchen einen Browser", senkt das Google Sheets-Add-on sie noch weiter: auf „Sie müssen das Tool, in dem Sie bereits arbeiten, nicht verlassen."

Das ImageToTable.ai Google Sheets-Add-on ist eine Seitenleiste, die in Ihrer Tabelle lebt. Öffnen Sie sie, laden Sie Bilder oder PDFs hoch, geben Sie Ihre Spaltennamen ein, und die extrahierten Daten werden direkt an das aktive Blatt angehängt – strukturierte Zeilen, korrekte Spalten, kein Kopieren und Einfügen. Der gesamte Workflow findet in Sheets statt: Rechnungsdaten extrahieren, Belegdetails oder Kontoauszugstransaktionen direkt in Ihre Arbeitstabelle, ohne Toolwechsel, Dateidownloads oder Neuformatierung der Ausgabe.

Das ist wichtig, weil es den letzten Reibungspunkt in einem codefreien Workflow beseitigt: den Export-Schritt. In einem webbasierten Tool laden Sie hoch → verarbeiten → laden herunter → öffnen die Datei. Mit dem Sheets-Add-on: hochladen → verarbeiten → die Daten sind bereits in Ihrer Tabelle – in dem Blatt, das Sie gerade verwenden, neben Ihren bestehenden Formeln, Diagrammen und Referenzen. Für ein Team, das Lieferantenrechnungen in eine gemeinsame AP-Tabelle verarbeitet, bedeutet dies, dass der Extraktionsschritt keine neue Datei zum Verwalten erzeugt – er fügt Zeilen zu der Datei hinzu, die alle bereits geöffnet haben.

Das Add-on arbeitet im Kontomodell: Binden Sie Ihren API-Schlüssel einmal ein, und es synchronisiert sich mit Ihrem Web-Dashboard – gleicher Verlauf, gleiche gespeicherte Spaltenvorlagen, gleiche Nutzungsverfolgung. Keine separate Einrichtung. Kein neuer Login. Die Extraktions-Engine ist identisch mit der Webversion; nur die Oberfläche ändert sich.

Das Add-on ermöglicht zudem einen Workflow, den kein reines Web-Tool leisten kann: Collection Link. Sie generieren einen teilbaren Link und senden ihn an Kunden, Lieferanten oder Teammitglieder. Diese öffnen ihn, geben einen kurzen Verifizierungscode ein und laden Dokumente direkt hoch – keine Registrierung, kein Login, kein zu erlernendes Tool. Die Dateien landen automatisch in Ihrer Verarbeitungswarteschlange. In Kombination mit dem Sheets-Add-on entsteht so eine vollständig codefreie Pipeline: Jemand anderes lädt die Dokumente hoch, Sie öffnen Ihre Tabelle, und die extrahierten Daten warten in Ihrer Verarbeitungswarteschlange – bereit, mit einem Klick an Ihr Blatt angehängt zu werden. Für einen tieferen Einblick in diesen Workflow erfahren Sie, wie Teams Mitarbeiter-Spesenbelege in einer gemeinsamen Google-Tabelle sammeln – ohne Einrichtung pro Mitarbeiter.

Wer am meisten profitiert – und wer mehr braucht

No-Code-KI-Extraktion ist nicht für alle gleich nützlich. Sie ist auf ein bestimmtes Profil optimiert – und zu wissen, ob man in dieses Profil passt, ist hilfreicher als eine reine Funktionsliste.

Buchhaltungs- und Abrechnungsteams sind die natürliche Zielgruppe. Sie verarbeiten täglich Dokumente, wissen genau, welche Daten sie aus jedem Dokumenttyp benötigen, und arbeiten ohnehin in Tabellenkalkulationen. Der Umstieg von manueller Erfassung auf No-Code-Extraktion dauert Minuten – denn die Oberfläche fordert sie lediglich auf, das zu tun, was sie ohnehin gedanklich tun („Ich brauche Rechnungsnummer, Datum, Gesamtbetrag aus diesem Stapel Rechnungen“) und automatisiert den physischen Teil (jeden Wert finden und in die richtige Zelle tippen). Die Auswirkungen auf Buchhaltungs-Workflows sind sofort spürbar, weil der Engpass – die manuelle Feldtranskription – genau das ist, was das Tool ersetzt.

Kleinunternehmer, die ihre Buchhaltung selbst erledigen, profitieren überdurchschnittlich von No-Code-Extraktion. Ihnen fehlt sowohl das Volumen für einen eigenen Kreditorenbuchhalter als auch das Budget für einen Entwickler für maßgeschneiderte Automatisierung. 20 bis 50 Rechnungen pro Monat manuell zu verarbeiten ist langsam und fehleranfällig; mit No-Code-KI dauert es unter 10 Minuten. Die Kostenrechnung unterscheidet sich von der eines Unternehmens – es geht nicht darum, ein Team zu ersetzen, sondern darum, jeden Monat einen Nachmittag zurückzugewinnen, der bisher für manuelle Dateneingabe draufging.

Jeder, der einen Dokumentensammelprozess betreibt – unterschriebene Formulare von Kunden sammelt, Spesenbelege von Mitarbeitern einholt oder Inspektionsberichte von Außendienstmitarbeitern erhält – profitiert von der Kombination aus Sammel-Link und No-Code-Extraktion. Die Sammelseite macht es überflüssig, dass Teilnehmer etwas installieren oder Konten anlegen müssen. Die Extraktionsseite macht es überflüssig, dass der Sammler jede Einreichung manuell überträgt. Zusammen verwandeln sie „Dokumente sammeln → Daten eingeben → ablegen“ in „Link teilen → Tabelle prüfen → erledigt.“

Teams, die eine API benötigen, stehen auf der anderen Seite der Architekturgrenze. Wenn extrahierte Daten automatisch in eine Datenbank, ein ERP oder eine andere Anwendung fließen müssen, ohne menschliche Prüfung, ist ein API-First-Ansatz die richtige Wahl. Der Entscheidungsrahmen ist einfach: Landen die Daten in einer Tabelle, die ein Mensch prüft, deckt No-Code das ab. Lösen die Daten programmatisch nachgelagerte Geschäftslogik aus, braucht man eine API. Unser Vergleich von API- und No-Code-Architekturen führt durch die vier Fragen, die bestimmen, welcher Pfad für Ihr Team der richtige ist.

Organisationen mit hochspezialisierten Dokumenten – proprietäre interne Formulare, branchenspezifische regulatorische Einreichungen mit einzigartigen Layout-Konventionen, Dokumente in Nischensprachen mit begrenzten Trainingsdaten – stellen möglicherweise fest, dass die Genauigkeit ohne Training geringer ist als gewünscht. Das ist kein Versagen des Ansatzes, sondern eine Folge der Abdeckung durch das Vortraining. VLMs funktionieren am besten bei Dokumenttypen, von denen sie Millionen von Beispielen gesehen haben. Für einen Dokumenttyp, der nur innerhalb eines Unternehmens existiert, gibt es diese Exposition nicht – und maßgeschneidertes Training (oder ein Tool, das dies unterstützt) wird zur Option.

Was KI-gestützte Extraktion ohne Training (noch) nicht kann

Die Grenzen der No-Code-Extraktion klar zu benennen, unterscheidet eine ehrliche Bewertung von einem Verkaufsgespräch. Hier liegen die Schwächen.

Extrem spezialisierte oder proprietäre Dokumenttypen. Ein VLM, das auf Millionen von Rechnungen, Quittungen und Kontoauszügen trainiert wurde, hat ein tiefes semantisches Verständnis dieser Dokumenttypen. Ein internes, firmeneigenes Formular, das nirgendwo sonst verwendet wird und idiosyncratisch formatiert ist – das Modell hat so etwas noch nie gesehen. Es wird dennoch versuchen, Daten zu extrahieren, und einige Felder (Daten, Beträge, Namen – Dinge, die bekannten Mustern ähneln) könnten korrekt sein, aber die Genauigkeit ist deutlich geringer als bei Standarddokumenten. Wenn Ihr Workflow auf einem benutzerdefinierten Dokumentformat ohne branchenweites Äquivalent basiert, sollten Sie pro Dokument mehr Felder überprüfen.

Komplexe mehrseitige Layouts mit seitenübergreifenden Abhängigkeiten. Eine Tabelle, die sich über drei Seiten erstreckt, mit verbundenen Zellen, geteilten Zeilen und laufenden Summen, die auf Werte einer vorherigen Seite verweisen – das fordert VLMs immer noch heraus. Das Modell verarbeitet Seiten unabhängig voneinander und behält keine laufende Erinnerung daran, dass „diese Position auf Seite 2 begann und sich über den Seitenumbruch auf Seite 3 fortsetzt". Einfache mehrseitige Kontinuität (eine Transaktionstabelle, die sauber von einer Seite zur nächsten übergeht) wird gut bewältigt. Komplexe übergreifende Logik – bei der ein einzelner Datenpunkt von der Aggregation von Werten über nicht zusammenhängende Seiten abhängt – führt in einem erheblichen Prozentsatz der Fälle zu Fehlern und erfordert eine manuelle Überprüfung.

Rein grafische Informationen. Wenn ein Dokument Daten ausschließlich über Diagramme, Schaubilder oder farbcodierte Visualisierungen ohne Textbeschriftungen vermittelt, gibt es nichts zu extrahieren. Die Höhe eines Balkendiagramms lässt sich ohne beschriftete Achse nicht in einen numerischen Wert übersetzen. Eine Farblegende, die Blautönen ohne Textbeschriftungen eine Bedeutung zuweist, ist nicht interpretierbar. Dokumente, die Text und Grafiken mischen – ein Bericht mit einer Datentabelle und einem Diagramm – funktionieren nur für den Tabellenteil.

Stark beeinträchtigte Eingabequalität. Ein sauberer Scan einer gedruckten Rechnung mit 300 DPI erreicht fast 99 % Genauigkeit. Ein Foto einer verblassten Thermoquittung, das bei schlechtem Licht aus einem Winkel aufgenommen wurde – die Genauigkeit sinkt. Das VLM gleicht moderate Qualitätsprobleme (leichte Unschärfe, Neigung, ungleichmäßige Beleuchtung) aus, aber wenn Zeichen für einen menschlichen Leser wirklich mehrdeutig werden, hat auch die KI Schwierigkeiten. Konfidenzwerte – bei denen das Tool unsichere Felder zur manuellen Überprüfung markiert – mildern dies, beseitigen es aber nicht.

Die ehrliche Verteilung: No-Code-KI verarbeitet die 80 % der Dokumente, die sauber, lesbar und strukturell klar sind, mit hoher Genauigkeit. Sie verarbeitet die nächsten 15 % – moderate Qualitätsprobleme, ungewöhnliche Layouts, leichte Handschrift – mit brauchbarer, aber nicht perfekter Genauigkeit. Die letzten 5 % – stark degradierte Scans, überlappende Handschrift, rein grafische Dokumente, proprietäre Formulare ohne Branchenäquivalent – erfordern weiterhin menschliche Aufmerksamkeit. Für eine detaillierte Aufschlüsselung, was die Extraktionsgenauigkeit bei verschiedenen Dokumenttypen beeinflusst, finden Sie in unserem Leitfaden zur praktischen Genauigkeit die relevanten Variablen.

Häufig gestellte Fragen

No-Code-KI-Extraktion verändert, wer Dokumentenautomatisierung nutzen kann – nicht indem sie die Technologie vereinfacht, sondern indem sie die Komplexität von der Einrichtung in das Vortraining verlagert. Das Modell hat die harte Arbeit geleistet, zu lernen, wie eine Rechnung aussieht, bevor Sie das Tool überhaupt geöffnet haben. Was Ihnen bleibt, ist zu beschreiben, was Sie aus Ihren Dokumenten herausholen möchten – was Sie, wenn Sie die Person sind, die sie täglich verarbeitet, bereits wissen.