Warum Ihre Rechnungspositions-Mathematik
nach der Extraktion falsch ist
Ihr Rechnungsextraktor hat Lieferantenname, Rechnungsnummer und Gesamtsumme korrekt erfasst. Doch bei der Stichprobenprüfung der Positionen stimmt etwas nicht: Zeile 3 zeigt Menge 4, Einzelpreis 150,00 €, Positionsbetrag 300,00 € – 300 € zu wenig. Dabei sieht jedes einzelne Feld sauber aus. Die KI hat nichts falsch gelesen. Sie hat etwas falsch zugeordnet.
Wichtige Erkenntnisse
- Ihr KI-Rechnungsextraktor meldet 99 % Feldkonfidenz, und dennoch stimmt die Mathematik von Menge × Preis nicht – weil feldbezogene Konfidenzwerte die Lesbarkeit messen, nicht ob ein Einzelpreis zu Zeile 2 oder Zeile 3 gehört.
- Menge × Preis-Abweichungen folgen nur vier Mustern – und die Größe und Richtung der Abweichung zeigt, ob die KI Zeilen vertauscht, einen Mengeneinheiten-Faktor übersehen oder Vor-Rabatt- mit Nach-Rabatt-Beträgen verwechselt hat.
- Eine einzige Formelspalte – =RUNDEN(Menge×Einzelpreis;2) – erkennt alle vier Muster, und die fünf Minuten, die Sie für ihre Einrichtung brauchen, verraten Ihnen mehr über die Extraktionsqualität als jeder Konfidenzwert.
Dies ist der unscheinbarste Fehlermodus bei der KI-gestützten Rechnungsextraktion. Die KI erreicht bei einzelnen Feldern eine Genauigkeit von über 98 % – sie liest Mengen, Einzelpreise und Zeilensummen als Einzelwerte korrekt. Die feldübergreifende Konsistenz ist jedoch eine grundlegend andere Herausforderung. Ein Bildverarbeitungsmodell, das „150,00 €“ mit hoher Sicherheit von einer Seite lesen kann, weiß nicht automatisch, ob diese 150,00 € zum Einzelpreis von Zeile 2, zur Zeilensumme von Zeile 3 oder zur Zwischensumme des Abschnitts gehören. Wenn diese Beziehungen brechen, stimmt die zeilenweise Mathematik nicht mehr, und der Fehler bleibt für feldbezogene Konfidenzwerte unsichtbar.
Eine Studie aus dem Jahr 2025 zu Docling und LlamaExtractor bestätigt die Lücke: Konsistenzprüfungen (Einzelposten + Steuer = Gesamtsumme) scheiterten bei 20 % der Rechnungen – hauptsächlich bei solchen mit komplexen Mehrsteuerszenarien oder nicht standardgemäßer Formatierung (arXiv 2510.15727v1). Wenn Sie in Ihrer Ausgabe Unstimmigkeiten zwischen Menge × Preis sehen, fallen Ihre Rechnungen wahrscheinlich in eines von vier unterschiedlichen Mustern.
Ursache 1: Die KI hat die Menge aus Zeile 1 mit dem Preis aus Zeile 2 verknüpft
Dichte Tabellen mit Einzelposten sind die häufigste Quelle für zeilenübergreifende Zuordnungsfehler. Wenn eine Rechnung 15+ Einzelposten ohne sichtbare Zeilentrenner aufweist – nur gestapelte Textzeilen – muss das räumliche Denken der KI entscheiden, wo genau eine Zeile endet und die nächste beginnt. Eine Verschiebung um wenige Pixel kann dazu führen, dass das Modell die Menge von Zeile N mit dem Einzelpreis von Zeile N+1 assoziiert.
Symptom: Einzelne Posten weisen falsche Berechnungen auf, aber die Summe aller Berechnungen von Menge × Preis entspricht der Rechnungszwischensumme. Dies zeigt, dass alle Werte korrekt sind – sie sind nur den falschen Nachbarn zugeordnet.
Zeilenübergreifende Lesevorgänge treten am häufigsten in drei Szenarien auf:
- Keine sichtbaren Zeilenränder: Rechnungen, die nur durch Leerraum getrennte Zeilen verwenden. Die KI schätzt, wo die Grenzen verlaufen, und liegt manchmal falsch.
- Mehrzeilige Beschreibungen: Eine Produktbeschreibung, die auf zwei Zeilen umbricht, verschiebt nachfolgende Zeilen nach unten. Die KI kann den Fortsetzungstext als neue Zeile interpretieren und verschiebt so alle folgenden Paare.
- Verbundene Zellen in der Tabellenkopfzeile: Eine Kopfzeile mit verbundenen Spaltenbeschriftungen kann die Spaltenanzahl-Erkennung der KI verwirren und dazu führen, dass die gesamte Tabellenstruktur von Anfang an falsch ausgerichtet wird. Siehe wie verbundene Zellen die Tabellenextraktion stören für eine detailliertere Aufschlüsselung.
So erkennen Sie es: Führen Sie eine Validierungsformel auf Zeilenebene durch (detailliert im Framework-Abschnitt unten). Zeilenübergreifende Lesevorgänge erzeugen einen charakteristischen Fingerabdruck – einige Zeilen überschätzen die Summe, andere unterschätzen sie, und die Fehler heben sich auf Zwischensummenebene auf.
Ursache 2: Verwechslung der Maßeinheit – „12“ ist nicht immer 12 Stück
Eine Menge von „12“ in einer Rechnungszeile ist ohne Angabe der Maßeinheit mehrdeutig. Handelt es sich um 12 Stück? 12 Dutzend (144 Einheiten)? 12 Kilogramm? 12 laufende Meter zu 3,75 € pro Meter? Die Zahl an sich ist klar, aber die KI kann 12 nicht mit einem Einzelpreis multiplizieren, wenn sie nicht weiß, wofür „12“ steht.
Verwechslungen der Maßeinheit (UOM) führen zu zwei unterschiedlichen Fehlermustern:
- Maßeinheit in einer separaten Spalte: Manche Rechnungen haben eine Spalte „UOM“ (ST, DZN, KG, M) zwischen den Feldern für Menge und Einzelpreis. Wenn die KI diese Spalte nicht erfasst oder zuordnet, behandelt sie „12 DZN“ (144 Einheiten × Preis) als „12 ST“ (12 Einheiten × Preis), was zu einem Zeilenbetrag führt, der 1/12 des korrekten Werts beträgt.
- Maßeinheit in der Beschreibung: Viele Rechnungen schreiben „12 × KARTON“ oder „12 @ KARTONPREIS“ in das Beschreibungsfeld. Die KI übernimmt „12“ in die Mengenspalte, hat aber keinen Mechanismus, um zu verstehen, dass dieses „12“ „12 Kartons zu je 6 Einheiten“ bedeutet. Der resultierende Gesamtbetrag (Menge × Preis) weicht dann um den Karton-Multiplikator ab.
Dieser Fehler ist tückisch, weil die Zahlen intern konsistent wirken. Menge = 12, Einzelpreis = 45,00 €, Zeilenbetrag = 540,00 € – die Rechnung geht auf. Wenn die Rechnung aber tatsächlich „12 Dutzend zu 45,00 € pro Dutzend“ besagt und die KI es als 12 Stück interpretiert hat, weicht der Betrag um den Faktor 12 ab. Die KI hat plausible Zahlen extrahiert, die zufällig den Realitätscheck nicht bestehen.
Probleme bei der Extraktion von Maßeinheiten verschärfen sich, wenn das Quelldokument fehlende Dezimalpunkte oder mehrdeutige Währungssymbole aufweist – ein fehlendes Dezimalkomma im Einzelpreis verstärkt jede Fehlinterpretation der Maßeinheit.
So erkennen Sie es: Gleichen Sie den Zeilenbetrag mit einer Preisliste oder historischen Durchschnittswerten für denselben Artikel ab. Ein Einzelpreis von 45,00 € für einen Artikel, der historisch 7,50 € pro Einheit kostet, ist ein Warnsignal – die KI hat die Maßeinheit möglicherweise als „ST“ gelesen, obwohl sie tatsächlich „KARTON (6 ST)“ war. Bei Rechnungen ohne historische Daten markieren Sie jede Zeile, bei der Menge × Einzelpreis eine runde Zahl ergibt, die von den erwarteten Preisspannen abweicht.
Ursache 3: Verwechslung von Brutto- und Nettobeträgen pro Position
Rechnungen verwenden unterschiedliche Darstellungsweisen für Positionssummen. Manche zeigen den Bruttobetrag (vor Rabatt) pro Zeile und ziehen Rabatte erst in der Fußzeile ab. Andere berechnen den Nettobetrag (nach Rabatt) direkt in der Zeile und fassen die Rabatte separat zusammen. KI-Erkennungsmodelle können oft nicht erkennen, welche Konvention eine Rechnung verwendet – besonders wenn die Spaltenüberschrift nur „Betrag" lautet.
Beispiel: Eine Position zeigt „Menge 10, Einzelpreis 50,00 €, Betrag 475,00 €". Rechnerisch stimmt 10 × 47,50 €, aber der Einzelpreis beträgt 50,00 €. Was ist passiert? Die Rechnung gewährt einen positionsbezogenen Rabatt von 5 % (2,50 €/Stück) und zeigt den Nettobetrag pro Zeile, während der Brutto-Einzelpreis angegeben wird. Die KI hat beide Werte korrekt extrahiert – sie gehören nur zu unterschiedlichen Stufen der Rabattberechnung.
Drei Rabattkonventionen führen regelmäßig zu Extraktionsproblemen:
- Positionsrabatt, Zeile zeigt Brutto: Die Zeile zeigt Menge × Vollpreis. Der Rabatt wird in der Fußzeile abgezogen. Die KI extrahiert den Positionsbetrag unverändert, und Menge × Preis stimmt überein. Kein Konflikt – der Rabattbetrag ist auf Positionsebene jedoch unsichtbar.
- Positionsrabatt, Zeile zeigt Netto: Die Zeile zeigt Menge × (Vollpreis − Rabatt). Die Spalte „Einzelpreis" zeigt weiterhin 50,00 €, aber der Positionsbetrag spiegelt den rabattierten Wert wider. Menge × 50,00 € ≠ Positionssumme, obwohl jedes Feld korrekt gelesen wird.
- Gemischte Konvention auf derselben Rechnung: Manche Positionen haben Rabatte, andere nicht. Die KI wendet eine einheitliche Interpretation auf alle Zeilen an, sodass einige übereinstimmen und andere nicht.
So erkennen Sie es: Typisch für diesen Fehler ist, dass Menge × Einzelpreis den Positionsbetrag durchgängig um einen festen Prozentsatz übersteigt. Wenn Sie bei rabattierten Positionen das Muster „Betrag = Menge × Preis × 0,95" sehen, während nicht rabattierte Zeilen stimmen, verwendet die Rechnung die Netto-darstellung pro Zeile. Markieren Sie diese Fälle und klären Sie die Rabattbedingungen mit dem Lieferanten, anstatt von einem Extraktionsfehler auszugehen.
Ursache 4: Gemischte Brutto- und Nettobeträge in einer Rechnung
In Rechnungen aus Mehrwertsteuerländern werden oft Brutto- und Nettopreise auf demselben Dokument gemischt. Manche Positionen enthalten die Steuer bereits im angezeigten Betrag (üblich bei Konsumgütern oder B2C-Verkäufen). Andere zeigen den Nettobetrag, und die Umsatzsteuer wird erst in der Fußzeile berechnet (Standard bei B2B). Ein KI-Modell, das alle Positionen einheitlich interpretiert, erzeugt bei den gemischten Zeilen eine Diskrepanz.
Viele Rechnungen kennzeichnen einzelne Zeilen nicht explizit als „inkl. MwSt." oder „exkl. MwSt." Die Unterscheidung ergibt sich aus Kundentyp, Produktkategorie oder Rechtsraum – eine Nuance, die selbst Buchhaltungssoftware wie Xero und AutoEntry mit speziellen Umschaltern handhabt, gerade weil sie nicht trivial ist.
Drei reale Szenarien führen zu diesem Fehler:
- Rechnungen mit gemischten Leistungen: Eine einzelne Hotelrechnung listet Zimmerkosten (regulärer Steuersatz) neben Servicegebühren (steuerfrei) und Parken (ermäßigter Satz). Je nach Buchhaltungssystem des Anbieters wird jede Zeile brutto oder netto dargestellt, was ein inkonsistentes Extraktionsziel ergibt.
- Internationale Rechnungen: Ein US-Lieferant stellt einem britischen Kunden eine Rechnung. Die Beträge sind in USD (ohne MwSt.) ausgewiesen, aber die Fußzeile enthält einen Hinweis auf Reverse-Charge. Eine KI, die hauptsächlich mit inländischen Rechnungsmustern trainiert wurde, interpretiert die steuerfreien Beträge möglicherweise anders.
- Gutschriften und Korrekturen: Korrekturzeilen, die sich auf ursprüngliche Brutto- oder Nettobeträge beziehen, erzeugen eine Diskrepanz, wenn die KI eine einheitliche Steuerinterpretation auf alle Zeilen anwendet.
Die arXiv-Studie zur Rechnungsextraktion ergab, dass Konsistenzfehler „bei Rechnungen mit komplexen Mehrsteuerszenarien konzentriert" waren – genau diese gemischten Brutto/Netto-Dokumente führen zu Menge × Preis ≠ Positionssumme, obwohl kein einzelnes Feld falsch ist.
So erkennen Sie es: Prüfen Sie, ob die Fehlerrate mit bestimmten Steuercodes oder Produktkategorien auf derselben Rechnung korreliert. Wenn Zeilen mit Steuercode „S" (Regelsatz) alle stimmen, aber Zeilen mit Code „Z" (Nullsteuersatz) eine konstante Abweichung in Höhe des Steuerprozentsatzes aufweisen, wendet die KI die falsche Brutto/Netto-Annahme auf die nullbesteuerten Artikel an.
Die Lösung: Ein 3-stufiges Validierungs-Framework für konsistente Positionsdaten
Jede der vier oben genannten Ursachen hinterlässt einen anderen Fingerabdruck in den extrahierten Daten. Ein systematisches Validierungs-Framework erfasst alle – und macht sichtbar, was feldbezogene Konfidenzwerte nicht können.
Stufe 1: Formelbasierte Zeilenvalidierung
Der schnellste Allrounder ist eine Formelspalte:
=RUNDEN(Menge*Einzelpreis;2)Vergleichen Sie mit dem extrahierten Positionsbetrag. Markieren Sie Zeilen, bei denen die Abweichung 0,01 € übersteigt, mit einer bedingten Formatierung:
=ABS(RUNDEN(A2*B2;2)-C2)>0,01Richtung und Ausmaß der Abweichung verraten welche Ursache vorliegt:
- Fehler heben sich zeilenübergreifend auf → Ursache 1 (zeilenübergreifendes Lesen). Alle Werte sind vorhanden, nur falsch zugeordnet.
- Konstanter Faktor als Abweichung (z. B. immer um 0,5, 6 oder 12 daneben) → Ursache 2 (Mengeneinheiten-Verwechslung). Der Faktor ist der Umrechnungsmultiplikator.
- Konstante prozentuale Abweichung → Ursache 3 (Rabatt-Verwechslung). Der Prozentsatz entspricht dem Rabattsatz.
- Abweichungen an bestimmte Steuercodes gebunden → Ursache 4 (Steuerinklusivität-Verwechslung). Der Abweichungsprozentsatz entspricht dem geltenden Mehrwertsteuersatz.
Stufe 2: Feldbeziehungs-Hinweise für die KI
Helfen Sie der KI bei der Extraktionskonfiguration, Feldbeziehungen zu verstehen, indem Sie explizit angeben, was zusammengehört. Die Benutzerdefinierte Spaltenextraktion von ImageToTable.ai arbeitet semantisch – Sie geben die gewünschten Spalten an, und die KI lokalisiert jeden Wert, indem sie dessen Bedeutung versteht. So verbessern Sie die spaltenübergreifende Zuordnung:
- Verwenden Sie beschreibende Spaltennamen: „Einzelpreis (pro Stück)“ und „Positionsbetrag (Menge × Einzelpreis)“ helfen der KI, Werte pro Einheit von Werten pro Zeile zu unterscheiden.
- Definieren Sie eine berechnete Spalte als Gegenprobe: Erstellen Sie
Positionsbetrag-Prüfung (Menge × Einzelpreis)– die KI extrahiert die Werte, führt die Berechnung durch und deckt Unstimmigkeiten bereits während der Extraktion auf, nicht erst nach dem Export. - Legen Sie Formatregeln für Zahlenfelder fest: Geben Sie an, dass Mengen ganze Zahlen sind (außer bei vorhandener Dezimalstelle) und Einzelpreise immer zwei Dezimalstellen haben. Das schränkt mehrdeutige Interpretationen ein.
Ebene 3: Gezielte Stichprobenprüfung
Selbst mit Formelprüfungen schlüpfen Fehler durch – besonders wenn Menge × Preis zufällig einem plausiblen, aber falschen Zeilenbetrag entspricht. Gezielte Stichprobenprüfung schließt diese Lücke. Pro Batch manuell prüfen: alle von Ebene 1 markierten Zeilen, 10 % der bestandenen Zeilen (um zufällig korrekte Summen zu erwischen) und eine Rechnung pro Lieferant (systematische Formatierungsbesonderheiten). So werden über 95 % der Rechenfehler erfasst, während weniger als 15 % der Daten manuell geprüft werden müssen.
Wann eskaliert werden sollte: Die 5-%-Schwelle
Wenn Ihr Validierungsframework mehr als 5 % der Positionen eines Batches markiert, liegt wahrscheinlich ein systemisches Problem vor – ein durchgängiges Muster von feldübergreifenden Abweichungen, das sich durch keine noch so große Anpassung der Validierungsformeln auf Positionsebene beheben lässt.
Drei Szenarien rechtfertigen eine Eskalation:
- Konzentration auf einen Lieferanten: 70 %+ der markierten Zeilen stammen von einem Lieferanten. Dessen Layout ist mit Ihrem aktuellen Ansatz nicht kompatibel. Bereiten Sie diese Rechnungen vorab auf oder leiten Sie sie an eine andere Pipeline weiter.
- Komplexität durch mehrere Steuersätze: Rechnungen mit 3+ Steuersätzen oder gemischten inklusiven/exklusiven Beträgen. Selbst die besten Modelle versagen hier in 20 % der Fälle (laut arXiv-Studie). Zur manuellen Prüfung an einen steuerspezialisierten Kreditorenbuchhalter weiterleiten, statt die Extraktion zu optimieren.
- Schlechte Quelldokumente: Wenn Markierungen gleichzeitig in allen vier Mustern auftreten, liegt die Ursache in schlechter OCR und nicht in Beziehungsverwechslungen. Zuerst die Quellqualität verbessern – siehe Korrekturen bei Dezimal- und Währungsextraktion.
Die Schwelle schützt Ihr Team vor einer Endlosschleife der Optimierung. Wenn die Extraktion bei unabhängigen Feldern 98 %+ und bei feldübergreifender Konsistenz 95 %+ erreicht, ist das für die meisten Kreditoren-Workflows funktional – die verbleibenden 5 % sind über Ausnahmebehandlung günstiger zu handhaben als vollständig zu eliminieren.
FAQ
Bedeutet eine Abweichung zwischen Menge × Preis immer einen Extraktionsfehler?
Nein. Manche Rechnungen weisen tatsächlich Positionsbeträge aus, die nicht Menge × Einzelpreis entsprechen – etwa wegen Mengenrabatten auf Positionsebene, Aktionspreisen oder Paketangeboten, bei denen der Einzelpreis in der Zeile ein Durchschnitt und nicht der Stückpreis ist. Prüfen Sie stets die Originalrechnung, bevor Sie eine Abweichung als Extraktionsfehler werten.
Kann ich dem Gesamtbetrag vertrauen, wenn die Positionen rechnerisch abweichen?
Nicht automatisch. Bei Ursache 1 (zeilenübergreifendes Lesen) heben sich die Fehler auf, und der Gesamtbetrag kann dennoch stimmen. Bei den Ursachen 2–4 ist der Gesamtbetrag jedoch wahrscheinlich falsch, da die zugrunde liegenden Positionsbeträge in die Zwischen- und Endsummen einfließen. Klären Sie daher immer zuerst die Abweichungen auf Positionsebene, bevor Sie die extrahierten Summen zur Zahlung verwenden.
Warum meldet mein KI-Tool 99 % Konfidenz bei Feldern, die falsch zugeordnet sind?
Weil Konfidenzwerte die Lesbarkeit einzelner Felder messen, nicht die logische Konsistenz zwischen Feldern. Ein Bilderkennungsmodell kann zu 99 % sicher sein, dass „150,00 €“ an einer bestimmten Position auf der Seite steht – und diese Sicherheit ändert sich nicht, ob die 150,00 € nun ein Einzelpreis oder ein Positionsbetrag sind. Die feldübergreifende Validierung ist ein separater Schritt, den kein Konfidenzwert ersetzt.
Wie gehe ich mit unterschiedlichen Mengeneinheiten verschiedener Lieferanten um?
Standardisieren Sie Ihre Extraktionsausgabe, indem Sie Ihrer Extraktionsvorlage eine separate Spalte „ME“ hinzufügen. Fügen Sie eine klare Formatanweisung hinzu: „Extrahieren Sie die Mengeneinheit (ST, DZN, KG, FT, CASE, BOX) aus derselben Zeile und geben Sie sie als separate Spalte aus.“ So wird die Mengeneinheit in Ihrer Ausgabe sichtbar, und Sie können Umrechnungsregeln in Ihrer Tabelle hinterlegen, anstatt darauf zu vertrauen, dass die KI Einheiten automatisch interpretiert.
Die Position ist die Wahrheitseinheit in der Kreditorenbuchhaltung
Die Extraktion auf Kopfebene – Lieferantenname, Rechnungsnummer, Gesamtbetrag – ist inzwischen standardmäßig genau. Die Grenze, an der die Qualität noch spürbar schwankt, liegt auf Positionsebene, wo Feldbeziehungen ebenso wichtig sind wie Feldwerte. Die KI liest einzelne Zahlen korrekt, aber die Zuordnung zu den richtigen Spalten und Zeilen hängt davon ab, ob das Modell die Dokumentbedeutung versteht. Dieses semantische Verständnis verbessert sich rasant, ist aber noch nicht auf dem Niveau, dass eine feldübergreifende Validierung entfallen kann. Das Framework – Formelspalte + Beziehungshinweise + gezielte Stichproben – ist der geeignete Prozess für jeden Extraktionsworkflow, der in Zahlung oder Abstimmung mündet.
Richten Sie die Formelspalte bei Ihrem nächsten Batch ein. Die fünf Minuten, die Sie brauchen, um =RUNDEN(Menge*Einzelpreis;2) und eine bedingte Formatierung hinzuzufügen, verraten Ihnen mehr über Ihre Extraktionsqualität als jeder Konfidenzwert.