No-Code KI-Dateneingabe:
Dokumentendaten extrahieren, ohne ein Modell zu trainieren

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

Um zu verstehen, was „kein Training“ bedeutet, hilft es zu wissen, was Training früher gekostet hat. Vor den visuellen Sprachmodellen basierte die Dokumentenextraktion auf einem zweistufigen System: OCR zur Umwandlung von Bildern in Text und maschinelle Lernklassifikatoren 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, das Datum und die Gesamtsumme war. UiPaths eigene Dokumentation gibt 20 bis 50 annotierte Muster pro Standardfeld an – für eine Rechnungsvorlage mit 10 Feldern sind also 200 bis 500 annotierte Dokumente erforderlich, bevor das Modell produktionsreife Genauigkeit erreicht. Bei Spaltenfeldern wie Positionszeilen steigt die Anforderung auf 50 bis 200 Dokumente pro Spalte. Und das gilt für ein einziges Dokumentenlayout. Ein neuer Lieferant mit einem anderen Rechnungsformat bedeutet neue Trainingsdaten – oder man nimmt eine geringere Genauigkeit eines Modells in Kauf, das für verschiedene Layouts nicht optimiert wurde.

Der Zeitrahmen: 2 bis 4 Wochen für das Sammeln und Annotieren von Trainingsbeispielen, weitere 1 bis 2 Wochen für Modelltraining und -bewertung sowie ein fortlaufender Wartungszyklus, bei dem neue Dokumentlayouts ein erneutes Training auslösen. Das benötigte Team: ein Datenannotator mit Dokumentenkenntnissen, ein Machine-Learning-Ingenieur für die Konfiguration der Trainingspipeline und ein Entwickler für die Integration des resultierenden Modells in ein Produktivsystem. Gesamtzeit bis zur ersten nutzbaren Extraktion: in der Regel 3 bis 6 Wochen. Gesamtkosten: gemessen am Ingenieursgehalt, nicht an einer Softwarelizenz.

Das war die Welt, die „KI-Dokumentenextraktion“ für jeden bedeutete, der sie vor 2023 evaluierte – und es ist der Grund, warum die Annahme „dafür braucht es 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 so verarbeitet wie ein Mensch: durch Betrachten der gesamten Seite und Verstehen der Bedeutung jeder Information, nicht durch Abgleich mit Mustern aus beschrifteten Beispielen.

Ein VLM lernt nicht von 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 fettgedruckte Zahl unten rechts auf einem Dokument neben dem Wort „Gesamtbetrag“ ist der fällige Betrag. 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 dahinter multipliziert mit dem Einzelpreis ist der Positionsbetrag. Das Modell lernte diese Zusammenhänge, indem es sie millionenfach auf Millionen von Dokumenten sah, nicht indem man ihm sagte, wonach es auf Ihrer spezifischen Rechnung suchen soll.

Das ist die tatsächliche Bedeutung von „Null Training“. Das Modell versteht bereits Rechnungen, Quittungen, Kontoauszüge, Bestellungen, Verträge und Dutzende weiterer Dokumenttypen – nicht weil Sie es trainiert haben, sondern weil es im großen Stil auf visuelles Dokumentenverständnis vortrainiert wurde. Wenn Sie Ihre erste Rechnung hochladen, lernt das Modell nicht. Es wendet sein vorhandenes Wissen auf ein Dokument an, das es noch nie gesehen hat. Derselbe Mechanismus funktioniert bei einem Foto einer zerknitterten Quittung, aufgenommen mit 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.

Dieser Unterschied 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, der Trainingspipelines erstellt, und einen Fachexperten, der Stichproben annotiert, bevor das Tool etwas Nützliches liefert. Da VLMs semantisch extrahieren, ist die einzige erforderliche Eingabe das, was Sie extrahiert haben möchten – und das wissen Sie bereits.

Die Forschung von Firstsource zu VLM-basierter Dokumentenverarbeitung zeigt, dass traditionelle OCR-Pipelines bei der Informationsextraktion Fehlerraten von 15–20 % aufweisen – verursacht durch das kaskadierende Versagen der einzelnen Schritte OCR → Layoutanalyse → Felderzuordnung. VLMs schließen diese Lücke, indem sie visuelles Layout, Textinhalt und semantische Bedeutung in einem einzigen, einheitlichen Schritt verarbeiten – keine kaskadierenden Fehler, keine sich verschlechternden Zwischenergebnisse, keine zu wartenden Vorlagen, 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: So funktioniert No-Code-Extraktion in der Praxis

Wenn Sie kein Modell trainieren oder Integrationscode schreiben müssen, was tun Sie dann? Der Workflow basiert auf einer einzigen Designentscheidung: Statt die Eingabe zu konfigurieren (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 Texteingabefeld ein – „Rechnungsnummer“, „Lieferantenname“, „Bestellnummer“, „Gesamtbetrag“, „Fälligkeitsdatum“ – und die KI findet jeden Wert überall im Dokument, indem sie dessen semantische Bedeutung versteht, nicht dessen Position. Die von Ihnen 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 hier ein Kästchen um die Rechnungsnummer, zeichnen Sie dort ein Kästchen um das Datum.“ Sie konfigurieren das Tool, um ein bestimmtes Layout zu verstehen. Die spaltenbasierte Extraktion fordert Sie auf, zu beschreiben, was Sie möchten: „Geben Sie mir die Rechnungsnummer, das Datum und die Gesamtsumme.“ Die KI übernimmt die Zuordnung – über jedes Layout, von jedem Anbieter, in jedem Format.

Über die direkte Extraktion gedruckter Felder hinaus unterstützt die No-Code-KI zwei weitere Modi, die Ihre Möglichkeiten erweitern, 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 – keine Rohdaten, die Sie später verarbeiten müssen. Ein Auftrag listet Menge und Einzelpreis auf, druckt aber nicht die Positionssumme. Definieren Sie eine Spalte namens Positionssumme (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 Posten in einem Abschnitt), bedingte Logik (Markieren von Abweichungen zwischen berechneten und gedruckten Summen) und feste Parameterreferenzen (Anwenden eines Steuersatzes, der gar nicht auf dem Dokument steht).

Abgeleitete Spalten lassen die KI entscheiden, welche Kategorie, welcher Tag oder welches Label auf ein Dokument zutrifft – und tragen das in Ihre Tabelle ein. Eine Restaurantquittung enthält nicht "Kategorie: Verpflegung". Aber für die Buchhaltung brauchen Sie Ausgabenkategorien. 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: Eilaufträge aus Lieferscheinen markieren, Währung aus internationalen Rechnungen erkennen, Dokumentuntertypen aus Versicherungszertifikaten identifizieren.

Diese drei Modi – direkte Extraktion, Berechnung und Ableitung – laufen auf eine einzige operative 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 skaliert dies auf große Mengen. Laden Sie 50 Rechnungen von 15 verschiedenen Lieferanten hoch. Geben Sie Ihre Spaltennamen einmal ein. Die KI verarbeitet alle 50, identifiziert jedes Feld über alle Layoutvarianten hinweg 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, erledigt sich in wenigen Minuten 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 Google-Sheets-Add-on ImageToTable.ai ist eine Seitenleiste, die direkt 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, richtige Spalten, kein Kopieren und Einfügen. Der gesamte Arbeitsablauf findet in Sheets statt: Rechnungsdaten extrahieren, Belegdetails erfassen oder Kontoauszugstransaktionen einlesen – direkt in Ihre aktuelle Tabelle, ohne Werkzeugwechsel, Dateidownload oder Neuformatierung der Ausgabe.

Das ist entscheidend, weil es den letzten Reibungspunkt in einem No-Code-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, zusammen mit Ihren bestehenden Formeln, Diagrammen und Verweisen. Für ein Team, das Lieferantenrechnungen in einer gemeinsamen Kreditorentabelle verarbeitet, bedeutet das, dass der Extraktionsschritt keine neue Datei erzeugt, die verwaltet werden muss – er fügt Zeilen zu der Datei hinzu, die alle bereits geöffnet haben.

Das Add-on arbeitet im Konto-Modus: 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 erstellen einen teilbaren Link und senden ihn an Kunden, Lieferanten oder Teammitglieder. Diese öffnen ihn, geben einen kurzen Bestätigungscode ein und laden Dokumente direkt hoch – ohne Registrierung, Anmeldung oder Einarbeitung. 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 bereits 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 profitiert am meisten – und wer braucht vielleicht mehr

Codefreie KI-Extraktion ist nicht für alle gleich nützlich. Sie ist auf ein bestimmtes Profil optimiert, und zu wissen, ob Sie in dieses Profil passen, ist hilfreicher als eine Funktionsliste.

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

Kleinunternehmer, die ihre Buchhaltung selbst erledigen, profitieren überdurchschnittlich von No-Code-Extraktion. Ihnen fehlt das Volumen für einen eigenen Kreditorenbuchhalter und das Budget für einen Entwickler für individuelle 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 für manuelle Dateneingabe draufging.

Jeder, der einen Dokumentensammelprozess betreibt – das Einholen unterschriebener Formulare von Kunden, das Sammeln von Ausgabenbelegen von Mitarbeitern, das Erhalten von Inspektionsberichten von Außendienstmitarbeitern – profitiert von der Kombination aus Sammellink und No-Code-Extraktion. Die Sammelseite macht es überflüssig, dass Teilnehmer etwas installieren oder Konten erstellen müssen. Die Extraktionsseite macht es überflüssig, dass der Sammler jede Einreichung manuell übertragen muss. 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, reicht No-Code. Lösen die Daten programmatisch nachgelagerte Geschäftslogik aus, benötigen Sie eine API. Unser Vergleich von API vs. No-Code-Architekturen führt durch die vier Fragen, die bestimmen, welcher Pfad zu Ihrem Team passt.

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

Was KI-Extraktion ohne Training (noch) nicht kann

Die Grenzen der codefreien 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 proprietäres internes Formular, das von einem Unternehmen entworfen, nirgendwo sonst verwendet und auf eine eigenwillige Weise formatiert wurde – das Modell hat noch nie etwas Vergleichbares gesehen. Es wird dennoch versuchen, Daten zu extrahieren, und einige Felder könnten korrekt sein (Daten, Beträge, Namen – Dinge, die bekannten Mustern ähneln), aber die Genauigkeit wird deutlich geringer sein als bei Standarddokumenttypen. Wenn Ihr Workflow auf einem benutzerdefinierten Dokumentformat ohne branchenweites Äquivalent basiert, sollten Sie damit rechnen, mehr Felder pro Dokument zu ü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 weiterhin 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 signifikanten 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 für die KI 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 Textbeschriftung eine Bedeutung zuweist, ist nicht auswertbar. Dokumente, die Text und Grafiken mischen – ein Bericht mit sowohl einer Datentabelle als auch 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 eines verblassten Thermo-Belegs, 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. Konfidenz-Scoring – bei dem das Tool unsichere Felder zur manuellen Überprüfung markiert – mildert dies, beseitigt es jedoch nicht.

Die ehrliche Verteilung: No-Code-KI verarbeitet die 80 % der Dokumente, die sauber, lesbar und strukturell klar sind, mit hoher Genauigkeit. Sie bewältigt die nächsten 15 % – mäßige 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 – benötigen weiterhin menschliche Aufmerksamkeit. Eine detaillierte Aufschlüsselung der Faktoren, die die Extraktionsgenauigkeit bei verschiedenen Dokumenttypen beeinflussen, finden Sie in unserem Praxishandbuch zur Genauigkeit, das die relevanten Variablen behandelt.

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 vom Setup ins Vortraining verlagert. Das Modell hat die harte Arbeit, zu lernen, wie eine Rechnung aussieht, bereits erledigt, bevor Sie das Tool überhaupt geöffnet haben. Was Ihnen bleibt, ist zu beschreiben, was Sie aus Ihren Dokumenten extrahieren möchten – und wenn Sie diejenige Person sind, die sie täglich verarbeitet, wissen Sie das bereits.