Warum Datenextraktion nur
die halbe Miete ist

Was die Dokumentenextraktion wirklich liefert – und was nicht

Das Versprechen klingt einfach: Eine 40-zeilige Rechnung kommt als PDF herein. Sie laden sie hoch. Die KI liest jede Kostenposition – Beschreibung, Menge, Einzelpreis, Zeilensumme – und gibt eine Tabelle mit bereits beschrifteten Spalten aus. Im Marketing-Jargon heißt das „End-to-End-Automatisierung". Im Rechnungswesen ist es der Startschuss.

Denn was die Tabelle nach der Extraktion tatsächlich enthält, sind Rohwerte, so wie sie auf der Seite standen. Die Spalte „Menge" enthält Zahlen. Die Spalte „Einzelpreis" enthält Zahlen. Die Spalte „Zeilensumme" enthält Zahlen. Aber niemand – weder die KI noch die Extraktionsengine – hat überprüft, ob Menge × Einzelpreis tatsächlich der auf der Rechnung ausgewiesenen Zeilensumme entspricht. Niemand hat alle zwanzig Zeilensummen addiert und mit der Zwischensumme auf der letzten Seite verglichen. Niemand hat geprüft, ob der auf die Zwischensumme angewandte Steuersatz den vom Lieferanten ausgewiesenen Steuerbetrag ergibt, oder die Rechnung als „prüfbedürftig" markiert, wenn die Zahlen nicht aufgehen.

Das Extraktionstool hat Ihnen Daten geliefert. Es hat Ihnen keine geprüften Daten geliefert. Und die Lücke zwischen diesen beiden Dingen – zwischen „die Zahlen sind in Excel" und „die Zahlen sind korrekt und bereit für die Hauptbuchhaltung" – ist der Ort, an dem die wahren Stunden verschwinden.

Die Tabellenkalkulationsformel, die heimlich mehr kostet als manuelle Dateneingabe

Tools zur Extraktion von Rechnungsdaten haben den Schritt „Zahlen eintippen" von 3 Minuten pro Seite auf etwa 5–10 Sekunden verkürzt. Das ist eine echte Verbesserung. Aber nehmen Sie eine Stoppuhr für den gesamten Workflow – vom PDF-Eingang bis „bereit zur Verbuchung" – und die Zeitverteilung verschiebt sich auf eine Weise, die die meisten Tool-Vergleiche nicht abbilden.

Ein typischer Rechnungsverarbeitungs-Workflow nach der KI-Extraktion umfasst mindestens vier Kategorien von Formelarbeit. Jede einzelne ist für sich genommen klein – eine Spalte hier, eine SUMME dort – aber gemeinsam bilden sie ein repetitives Tabellen-Fließband, das niemand im Budget hat:

• Prüfung der Zeilensummen. Für jede Rechnungszeile benötigen Sie in Spalte E =C2*D2 – Menge mal Einzelpreis – und einen Vergleich mit der gedruckten Zeilensumme in Spalte F. Eine Rechnung mit 15 Positionen bedeutet 15 Multiplikations- und 15 Vergleichsformeln. Bei 200 Rechnungen pro Monat sind das 6.000 Formelzellen, die erstellt, gezogen und stichprobenartig geprüft werden müssen.
• Abstimmung der Zwischensumme. Nach Prüfung der einzelnen Zeilen summieren Sie die berechneten Zeilensummen und vergleichen sie mit der gedruckten Zwischensumme. Dann wenden Sie den Steuersatz an (der je nach Zuständigkeitsbereich oder Position variieren kann – manche Artikel sind steuerpflichtig, andere nicht) und vergleichen ihn mit dem ausgewiesenen Steuerbetrag. Anschließend addieren Sie Zwischensumme und Steuer und vergleichen das Ergebnis mit dem Rechnungsendbetrag. Bei einer mehrseitigen Rechnung mit unterschiedlichen Steuersätzen ist das keine einfache SUMME-Formel, sondern eine Kette voneinander abhängiger Berechnungen, die fehlschlägt, wenn ein vorgelagerter Wert falsch ist.
• Bedingte Kennzeichnungen. Übersteigt der Rechnungsbetrag den Bestellwert? Ist die Zahlung innerhalb von 7 Tagen fällig (Kennzeichnung für dringende Genehmigung)? Befindet sich der Lieferant auf der Liste der bevorzugten Anbieter? Jede dieser Prüfungen ist eine bedingte Formel – =WENN(F2>G2;"ÜBER BUDGET";"") – die jemand schreibt, formatiert und über jede Zeile zieht.
• Standardisierungsformeln. Daten kommen in jedem erdenklichen Format: 15.06.2026, 15-Jun-2026, 20260615. Währungsbeträge mischen Dezimalkommas und -punkte je nach Herkunftsland des Lieferanten. Jemand schreibt =DATWERT()-Wrapper und =WECHSELN()-Ketten, um alles zu normalisieren, bevor es in das Buchhaltungssystem übernommen werden kann.

Keine dieser Arbeiten ist Extraktion. Die KI hat die richtigen Zahlen bereits extrahiert. Aber die Zahlen sind erst nutzbar, wenn diese Berechnungen durchgeführt wurden – und in den meisten Unternehmen ist der Berechnungsaufwand unsichtbar. Er findet in Excel statt, in 15-Minuten-Schüben zwischen Meetings, von Mitarbeitern, in deren Stellenbeschreibung nicht „Tabellenkalkulations-Formeltechniker“ steht. Die Arbeit wird erledigt, aber niemand erfasst, wie lange sie dauert – und niemand fragt, ob sie nötig ist.

Wenn ein Sachbearbeiter in der Kreditorenbuchhaltung eines mittelständischen Unternehmens 200 Rechnungen pro Monat bearbeitet und durchschnittlich 8 Minuten pro Rechnung für Formelarbeit nach der Extraktion aufwendet – Prüfspalten schreiben, Formeln ziehen, Zwischensummen abstimmen –, sind das 26 Stunden pro Monat für Aufgaben, die Daten extrahieren, aber nichts berechnen. Beim BLS-Medianlohn für Buchhalter von 23,33 $/Stunde entstehen Kosten von über 600 $ pro Monat allein für die Formelerstellung. Bei einem Team von drei Sachbearbeitern sind das 1.800 $ pro Monat – 21.600 $ pro Jahr – für Excel-Formeln, die überflüssig wären, wenn die Berechnungen bereits bei der Extraktion erfolgen würden.

Warum die Dokumentenextraktionsbranche die Extraktion als Ziel ansieht

Die dominierenden Werkzeuge auf dem Markt – templatebasierte OCR, maschinelle Lernklassifikatoren, große Bildmodelle – sind alle auf ein einziges technisches Problem ausgerichtet: „Aus einem Dokumentbild strukturierten Text ausgeben.“ Dieses schwierige Problem zu lösen, dauerte Jahrzehnte. Die Teams, die diese Werkzeuge entwickeln, sind verständlicherweise auf das Problem organisiert, das sie zu lösen wissen.

Doch die Definition von „fertig“ aus Ingenieurssicht – „der Text steht in einer Datenbankzeile“ – deckt sich nicht mit der Definition des Buchhalters: „Die Zahlen wurden geprüft, berechnet und sind für das Hauptbuch bereit.“ Das Extraktionsergebnis ist ein Datenartefakt. Das Buchhaltungsergebnis ist ein Finanzartefakt. Die Umwandlung von einem ins andere erfordert Berechnungen – und die Extraktionsbranche hat diese Berechnung weitgehend dem Nutzer überlassen.

Dies ist kein Versagen einzelner Werkzeuge. Es ist eine strukturelle Lücke in der Problemdefinition. Die Softwarebranche betrachtete die Dokumentenverarbeitung und sah: „OCR muss besser werden.“ Sie baute bessere OCR. Dann sah sie: „Formate sind unberechenbar“ und entwickelte layoutunabhängige KI. Jede Iteration machte die Extraktion schneller und genauer – aber jede Iteration machte auch die fehlende Formelarbeit nach der Extraktion deutlicher. Wenn die Extraktion 10 Sekunden dauert und die Formelarbeit immer noch 8 Minuten, ist die Extraktionsgeschwindigkeit nicht mehr die Schlagzeile. Die Formellücke wird zur Schlagzeile.

Der deutlichste Beleg für diese Lücke ist, wie AP-Teams ihre Extraktionswerkzeuge tatsächlich nutzen. Sie extrahieren. Sie exportieren nach Excel. Und dann fügen sie Spalten hinzu – nicht weil die Extraktion Daten übersehen hat, sondern weil das Werkzeug nicht rechnet. Sie fügen die Spalte „Menge × Einzelpreis“ hinzu. Sie fügen die Abweichungsspalte hinzu. Sie fügen die Freigabespalte hinzu. Sie fügen die Spalte mit dem standardisierten Datum hinzu. Die Tabelle, die sie an das Buchhaltungssystem senden, hat doppelt so viele Spalten wie das Extraktionswerkzeug erzeugt hat. Die Hälfte der Spalten sind Extraktionsergebnisse. Die andere Hälfte sind Formeln, die jemand an einem Dienstag um 16:00 Uhr geschrieben hat.

Die Berechnungslücke in der Praxis: wenn Ihre Rechnungssumme nicht stimmt

Warum Formeln nach der Extraktion nicht nur mühsam, sondern strukturell riskant sind, zeigt der häufigste Abstimmungsfehler in der Kreditorenbuchhaltung: die abweichende Rechnungssumme.

Ein Lieferant sendet eine Rechnung mit zwölf Positionen. Das Extraktionstool erfasst jedes Feld korrekt: zwölf Beschreibungen, zwölf Mengen, zwölf Einzelpreise, zwölf Positionssummen, eine Zwischensumme, ein Steuerbetrag, eine Rechnungssumme. Alle Zahlen stimmen mit dem Originaldokument überein. Wenn Sie jedoch die zwölf extrahierten Positionssummen addieren, ergibt sich ein Betrag von 3.847 €. Die gedruckte Zwischensumme auf der Rechnung beträgt 3.812 €. Die Differenz beträgt 35 €.

Der Fehler liegt nicht in der Extraktion. Er liegt in der Rechnung des Lieferanten – eine Position wurde falsch bepreist, ein Rabatt inkonsistent angewendet oder eine Rundungsentscheidung führte zu einer Abweichung. Das Extraktionstool hat jedoch keinen Mechanismus, dies zu erkennen. Es hat die Zahlen des Lieferanten originalgetreu übernommen, ohne sie zu überprüfen. Die Erkennung findet in Excel statt, wenn jemand =SUMME(F2:F13) schreibt und mit Zelle F15 vergleicht. Wenn niemand diese Formel schreibt – oder wenn die Formel korrekt ist, aber nur auf die erste Seite einer mehrseitigen Rechnung angewendet wird – bleibt die Abweichung von 35 € bestehen. Sie gelangt in das Hauptbuch. Drei Monate später wird sie zu einem Abstimmungsposten, bei dem die Suche nach der Originalrechnung und die Überprüfung der Positionsarithmetik mehr Arbeitskosten verursacht als die 35 € selbst.

Dieses Szenario ist nicht selten. Es ist der Standardzustand eines jeden Extraktionsworkflows, der keine Berechnung beinhaltet. Jede Rechnung wird zu einer Matheaufgabe, die jemand manuell in einer Tabellenkalkulation aufstellen und lösen muss. Bei geringen Mengen ist die Mathematik beherrschbar. Bei 200 Rechnungen pro Monat wird die Mathematik zu einer Vollzeitaufgabe, für die niemand offiziell eingeteilt ist. Bei 500 Rechnungen pro Monat wird die Mathematik zu einem Risiko – denn Fehler, die zu 95 % erkannt werden, werden in den anderen 5 % nicht erkannt, und die 5 %, die durchrutschen, sind diejenigen, die zählen.

Berechnungsschritt von Excel zurück in die Extraktion verlagern

Liegt das Problem darin, dass die Extraktion Rohwerte liefert und die Berechnung erst später in einem separaten Tool erfolgt, ist die logische Lösung, beide Schritte zusammenzulegen. Statt „erst extrahieren, dann in Excel berechnen“ läuft die Berechnung direkt im Moment der Extraktion – während die KI das Dokument liest und die Ergebnistabelle schreibt.

Dies ist der Mechanismus hinter dem, was ImageToTable.ai Berechnete Spalten nennt. Wenn Sie die Spalten definieren, die aus einem Dokument extrahiert werden sollen, müssen Sie sich nicht auf Felder beschränken, die auf der Seite vorhanden sind. Sie können Spalten definieren, deren Werte durch Berechnung aus anderen extrahierten Feldern abgeleitet werden. Die KI liest das Dokument, extrahiert die Quellwerte, führt die Berechnung durch und schreibt das Ergebnis direkt in die Ausgabe – alles in einem Durchgang. Keine separate Tabelle. Keine Formelleiste. Kein Ziehen von Zellen.

Für eine Rechnung ergeben sich sofort praktische Anwendungen:

• Prüfung der Zeilensumme. Definieren Sie eine berechnete Spalte Berechnete Zeilensumme (Menge × Einzelpreis). Für jede Rechnungsposition multipliziert die KI die Menge mit dem Einzelpreis und gibt das Ergebnis aus. Vergleichen Sie es mit der gedruckten Zeilensummenspalte – jede Abweichung ist in der Ausgabe sichtbar, nicht in einer Formel, die Sie vergessen haben zu schreiben.
• Abstimmung der Zwischensumme. Definieren Sie eine berechnete Spalte, die alle extrahierten Zeilensummen summiert und das Ergebnis mit der gedruckten Zwischensumme vergleicht. Die Ausgabe ist keine rohe Zahl – es ist ein Abgleich: „Summe der Zeilen: 3.847 €. Gedruckte Zwischensumme: 3.812 €. Abweichung: 35 €.“ Die Berechnung, die früher eine Kette von Excel-Formeln erforderte, ist direkt in die Extraktion integriert.
• Steuerprüfung. Definieren Sie eine berechnete Spalte Erwartete Steuer (Zwischensumme × 0,0825) mit einem festen Steuersatzparameter. Vergleichen Sie mit dem gedruckten Steuerbetrag. Hat der Lieferant den falschen Satz angewendet, wird die Abweichung erkannt, bevor die Daten jemals Excel erreichen.
• Budgetkennzeichen. Definieren Sie eine berechnete Spalte, die prüft, ob der Rechnungsbetrag einen Referenzwert überschreitet: Budgetprüfung (Rechnungsbetrag > Bestellwert). Die Ausgabe ist „Über Budget“ oder „OK“ – ein bedingtes Kennzeichen, das während der Extraktion erzeugt wird, nicht nachträglich hinzugefügt.

Berechnete Spalten machen die Überprüfung nicht überflüssig. Sie machen das Berechnen zum Zweck der Überprüfung überflüssig. Die KI erledigt die Arithmetik. Der Kreditorenbuchhalter prüft das Ergebnis. Der Unterschied ist wichtig, denn Berechnung ist stupide Arbeit – fehleranfällig bei manueller Ausführung in großem Umfang – und Prüfung ist Beurteilungsarbeit, die Menschen besser können. Die Verlagerung der Berechnung vorgelagert bedeutet, dass der Mensch seine 8 Minuten pro Rechnung für den Teil aufwendet, den Maschinen nicht können: zu entscheiden, was die Abweichung bedeutet und welche Maßnahmen zu ergreifen sind.

Diese Funktion gibt es in zwei Formen. Für den schnellen Gebrauch können Sie die Berechnung direkt in den Spaltennamen schreiben – Zeilensumme (Menge × Einzelpreis) – und die KI leitet die Logik aus der natürlichen Sprache ab. Für komplexere, mehrstufige Ableitungen können angemeldete Benutzer die Berechnung in einem strukturierten JSON-Regelformat definieren, wobei die Spaltennamen sauber bleiben, während die Berechnungslogik präzise ausgedrückt wird. Beide Ansätze führen zum gleichen Ergebnis: eine Spalte in Ihrer Ausgabetabelle, deren Werte während der Extraktion berechnet wurden, nicht nachträglich hinzugefügt. Für Teams, die Rechnungen in großen Mengen verarbeiten, verwandelt die Stapelverarbeitung von Rechnungsdaten mit berechneten Spalten das, was früher Stunden an Nachbearbeitungsformelarbeit war, in etwas, das abgeschlossen ist, bevor der Upload beendet ist.

Häufig gestellte Fragen

Wie viel Zeit kostet die Formelarbeit nach der Extraktion tatsächlich?

Für ein mittelständisches AP-Team mit 200 Rechnungen pro Monat verschlingt die Nachbearbeitung – Zeilenprüfung, Zwischensummen-Abgleich, bedingte Kennzeichnungen, Datumsnormierung – rund 25–30 Stunden monatlich, basierend auf durchschnittlich 8 Minuten Formelarbeit pro Rechnung. Diese Formelarbeit findet nach der Extraktion statt, die pro Seite nur Sekunden dauert. Die Formeln hingegen kosten Minuten pro Rechnung. Je schneller die Extraktion wird, desto größer – und nicht kleiner – wird die relative Lücke durch die Formelarbeit.

Kann ich nicht einfach Excel-Vorlagen zur Automatisierung dieser Formeln verwenden?

Vorgefertigte Excel-Vorlagen reduzieren zwar den Einrichtungsaufwand pro Batch, ersetzen aber nicht die manuellen Schritte. Die Vorlage muss weiterhin auf jeden Extraktionsdurchlauf angewendet werden – Daten importieren, sicherstellen, dass die Spaltenausrichtung stimmt, und überprüfen, ob die Formeln auf die richtigen Zeilen verweisen. Vorlagen helfen beim Schreiben von Formeln, nicht bei der Validierung. Eine SUMME-Formel, die die Zeilen 2 bis 13 erfasst, funktioniert einwandfrei, bis eine Rechnung 14 Positionen hat und Zeile 14 stillschweigend ausgeschlossen wird. Vorlagen reduzieren den Arbeitsaufwand für Formeln, ersetzen aber nicht die Notwendigkeit einer Formelprüfung – und die Prüfung ist es, die die meiste Zeit in Anspruch nimmt.

Funktionieren die berechneten Spalten von ImageToTable.ai auch mit handschriftlichen Rechnungen?

Ja – berechnete Spalten arbeiten mit den Werten, die die KI aus dem Dokument extrahiert, unabhängig davon, ob die Quelle gedruckt oder handschriftlich ist. Wenn die KI Menge und Einzelpreis aus einer handschriftlichen Rechnung lesen kann, kann sie diese bei der Extraktion genauso multiplizieren wie bei einer gedruckten Rechnung. Die Genauigkeit der Berechnung hängt von der Genauigkeit der zugrunde liegenden Extraktion ab; wird eine handschriftliche Zahl falsch gelesen, übernimmt das berechnete Ergebnis diesen Fehler. Die Handschrifterkennung der KI variiert je nach Leserlichkeit – klar geschriebene Zahlen auf Standardformularen werden zuverlässig extrahiert; dichte, verschnörkelte Schrift auf unstrukturierten Layouts kann eine Überprüfung erfordern.

Welche Arten von Berechnungen können berechnete Spalten durchführen?

Berechnete Spalten unterstützen zeilenweise Arithmetik (Multiplizieren, Dividieren, Addieren, Subtrahieren zwischen Feldern derselben Zeile), zeilenübergreifende Aggregation (Summieren aller Positionsbeträge innerhalb eines Dokuments), bedingte Logik (Ausgabe „Über Budget“, wenn der Rechnungsbetrag einen Schwellenwert überschreitet, sonst „OK“), feste Parameterreferenzen (Einbetten eines Steuersatzes oder Referenzwerts in die Berechnungsregel, ohne dass das Dokument diesen enthalten muss) und mehrstufige Ableitungen (Berechnen einer Zwischensumme aus Positionen, dann Anwenden von Steuern, dann Vergleichen mit dem gedruckten Gesamtbetrag). Für einfache Berechnungen schreiben Sie die Logik direkt in den Spaltennamen. Für komplexe, mehrstufige Berechnungen verwenden Sie das JSON-Regelformat, das angemeldeten Benutzern zur Verfügung steht.

Ersetzt dies die manuelle Rechnungsprüfung?

Nein – und das ist auch nicht das Ziel. Berechnete Spalten ersetzen den Berechnungsschritt, nicht den Prüfschritt. Ein Mensch muss weiterhin das Ergebnis betrachten und entscheiden, was eine Abweichung bedeutet: Ist eine Differenz von 35 € ein akzeptabler Rundungsfehler oder ein Abrechnungsfehler, der eine Gutschrift erfordert? Der Wert berechneter Spalten liegt darin, dass der Mensch schneller zu dieser Entscheidung gelangt, weil die Arithmetik bereits erledigt ist. Statt 5 Minuten mit dem Erstellen von Formeln zu verbringen, um die 35-€-Differenz zu entdecken, sieht der Prüfer sie sofort im Ergebnis und verwendet seine 5 Minuten darauf, zu entscheiden, was zu tun ist.

Was ist, wenn ich eine Berechnung benötige, die Berechnete Spalten nicht unterstützen?

Berechnete Spalten decken die gängigsten Berechnungen nach der Extraktion ab: Arithmetik, Summierung, Vergleich und bedingte Logik. Für hochspezialisierte Berechnungen – versicherungsmathematische Formeln, Multiwährungs-Devisenumrechnungen zu Live-Kursen, Abschreibungspläne – bleiben Excel oder ein dediziertes Finanzsystem das geeignete Werkzeug. Berechnete Spalten sind darauf ausgelegt, die 90 % der Arbeit nach der Extraktion zu bewältigen, die repetitiv und formelhaft ist, nicht jedoch jede Tabellenkalkulationsfunktion zu ersetzen. Bei den meisten Rechnungsverarbeitungs-Workflows macht diese 90 % den Großteil der aufgewendeten Zeit aus.