Lokales vs. globales Maximum: Warum etablierte Anbieter an LLM-nativen Lösungen scheitern

Das System funktioniert – aber es kommt nicht weiter

Wer seit Jahren mit einem etablierten System für Rechnungseingang arbeitet, kennt das Gefühl: Die Software ist eingerichtet, die wichtigsten Lieferanten sind angelegt, die Templates sind trainiert. 60%, vielleicht 70% der Standardrechnungen laufen automatisch durch.

Aber dann kommen die übrigen 30–40%. Neue Lieferanten, ungewöhnliche Layouts, handschriftliche Ergänzungen, Gutschriften im Freitextformat, Rechnungen aus dem Ausland mit anderem Aufbau. Für jeden dieser Fälle muss jemand ein neues Template anlegen, Felder mappen, Regeln definieren. Das dauert Stunden bis Tage – pro Lieferant.

Irgendwann stellt sich die Frage: Liegt das an uns – oder an der Technologie?

Was ist ein lokales Maximum?

Der Begriff kommt aus der Optimierungstheorie. Stellen wir uns einen Wanderer vor, der mit verbundenen Augen eine Berglandschaft durchquert. Er kann nur den Boden direkt unter seinen Füßen spüren und geht immer bergauf. Irgendwann erreicht er einen Gipfel – es geht in alle Richtungen bergab.

Hat er den höchsten Punkt erreicht? Möglicherweise nicht. Vielleicht steht er auf einem Hügel von 500 Metern – während der eigentliche Gipfel bei 2.000 Metern liegt. Dazwischen: ein Tal, das er nur überqueren kann, wenn er zunächst wieder absteigt.

Genau das passiert gerade in der Belegverarbeitung: Etablierte Anbieter haben über Jahre hinweg das Beste aus ihrem technologischen Ansatz herausgeholt – dem lokalen Maximum. Aber das globale Maximum liegt auf einem völlig anderen Fundament: Large Language Models, die Dokumente nicht anhand von Positionen auf der Seite lesen, sondern wie ein Mensch – durch Verstehen.

Wie template-basierte Systeme funktionieren

Die meisten etablierten Anbieter für Rechnungseingang – ABBYY, Basware, Kofax, ReadSoft und andere – basieren auf dem gleichen Grundprinzip: Für jeden Dokumenttyp wird ein Template angelegt. Dieses Template definiert, wo auf der Seite welche Information steht: Rechnungsnummer oben rechts, Betrag unten links, Lieferantenname im Kopf.

Das funktioniert gut – solange die Rechnung exakt dem erwarteten Layout entspricht. Bei bekannten Lieferanten mit stabilen Formaten erreichen diese Systeme hohe Erkennungsraten. Das war jahrelang das Beste, was technisch möglich war.

Aber der Ansatz hat eine strukturelle Grenze: Er skaliert nicht über Formate hinweg. Jeder neue Lieferant, jede Layout-Änderung, jede Sprache braucht ein neues Template oder eine Anpassung des bestehenden. Das ist kein Bug – das ist die Architektur.

Was LLM-native Verarbeitung anders macht

Large Language Models lesen Dokumente nicht durch Positionen auf der Seite, sondern durch Sprachverständnis. Sie erkennen, dass „Gesamtbetrag“, „Total amount“, „Summe netto zzgl. USt“ und „Montant TTC“ das Gleiche meinen – ohne dass jemand ein Template dafür anlegt.

Keine Templates nötig

Neue Lieferanten, neue Länder, neue Layouts – das System versteht das Dokument ab dem ersten Beleg, ohne dass jemand Felder mappen muss.

Kontextverständnis statt Positionserkennung

Ein LLM versteht, dass eine Gutschrift den Betrag umkehrt, dass „Skonto 2% bei Zahlung innerhalb 10 Tagen“ eine Zahlungsbedingung ist, und dass eine handschriftliche Notiz am Rand einen Freigabevermerk darstellt.

Buchungslogik statt nur Extraktion

Template-Systeme extrahieren Felder. LLMs können darüber hinaus Kontierungsvorschläge machen, Sachkonten zuordnen und steuerliche Implikationen erkennen – weil sie den Inhalt verstehen, nicht nur die Position.

Lernen aus Korrekturen

Wenn ein Mensch eine Extraktion korrigiert, verbessert sich das System für alle ähnlichen Fälle – nicht nur für dieses eine Template bei diesem einen Lieferanten.

Warum etablierte Anbieter nicht einfach umsteigen

Die naheliegende Frage: Warum bauen ABBYY, Kofax und Co. nicht einfach LLMs in ihre Produkte ein?

Einige tun das bereits – als Ergänzung. Aber es gibt einen fundamentalen Unterschied zwischen „KI draufschrauben“ und „KI als Fundament bauen“.

Architekturschulden

Die gesamte Produktarchitektur – Datenmodelle, APIs, Workflows, Preismodelle – ist um Templates herum gebaut. Ein LLM als Schicht darüber zu legen, ändert das Fundament nicht. Es macht das Gebäude nur komplexer.

Geschäftsmodell-Konflikt

Viele etablierte Anbieter verdienen an Template-Erstellung, Beratung und Implementierungsprojekten. Ein System, das ohne Templates funktioniert, kannibalisiert das eigene Geschäftsmodell.

Bestandskunden-Dilemma

Tausende Kunden haben jahrelang Templates gepflegt und Workflows darauf aufgebaut. Ein radikaler Technologiewechsel würde diese Investition entwerten – und damit die Kundenbasis gefährden.

Es gibt einen einfachen Test: Wenn man alle KI-Funktionen aus dem Produkt entfernt – funktioniert es dann noch? Bei ABBYY oder Kofax lautet die Antwort: ja, das Kernprodukt basiert weiterhin auf Templates. Bei einem LLM-nativen System lautet die Antwort: nein, ohne das Sprachmodell gibt es kein Produkt. Das ist der Unterschied zwischen „KI draufgeschraubt“ und „KI als Fundament“.

Das ist kein Vorwurf an diese Anbieter. Es ist ein bekanntes Muster in der Technologiegeschichte: Clayton Christensens „Innovator’s Dilemma“. Etablierte Unternehmen scheitern an disruptiven Technologien, weil sie rational auf bestehende Kunden hören – und genau diese Kunden wollen inkrementelle Verbesserungen an Templates, keinen riskanten Architekturwechsel.

Der konkrete Unterschied in Zahlen

Kriterium	Template-basiert	LLM-nativ
Neuer Lieferant	Template anlegen (Stunden/Tage)	Sofort verarbeitet
Layout-Änderung	Template-Anpassung nötig	Automatisch erkannt
Fremdsprachen	Eigene Templates pro Sprache	Nativ mehrsprachig
Freitext/Notizen	Wird ignoriert	Wird verstanden und ausgewertet
Kontierung	Regelbasiert (starr)	Kontextbasiert (adaptiv)
Wartungsaufwand	Steigt mit Lieferantenanzahl	Sinkt mit Belegvolumen

Der letzte Punkt ist der entscheidende: Bei template-basierten Systemen steigt der Wartungsaufwand linear mit der Anzahl der Lieferanten. Bei LLM-nativen Systemen sinkt er – weil jede Korrektur und jedes Feedback das System für alle ähnlichen Fälle verbessert, statt nur ein einzelnes Template zu reparieren.

Die ehrlichen Stärken der Etablierten

Wir wollen hier fair bleiben. Etablierte Anbieter haben reale Vorteile, die neue LLM-native Player erst noch aufbauen müssen:

Jahrelange Produktionsreife

Ein System, das seit 10 Jahren bei hunderten Kunden im Einsatz ist, hat die meisten Stabilitätsprobleme hinter sich. Das ist ein echtes Argument – nicht jedes neue Tool überlebt den ersten Winter in der Produktion.

Bestehende Integrationen

SAP-Konnektoren, DATEV-Anbindung, BMD-Schnittstellen – diese Integrationen sind über Jahre gereift und decken viele Sonderfälle ab. Ein neuer Anbieter muss beweisen, dass seine Integrationen genauso zuverlässig funktionieren.

Compliance-Track-Record

GoBD-Konformität, DSGVO-Dokumentation, Audit-Trails – für geprüfte Unternehmen zählt nicht nur die Technik, sondern auch der Nachweis. Etablierte Anbieter können auf Jahre an Zertifizierungen und Prüfberichte verweisen.

Determinismus und keine Halluzinationen

Ein Template liefert bei jedem Durchlauf das gleiche Ergebnis. LLMs können „halluzinieren“ – also Informationen erzeugen, die im Dokument nicht stehen. Das ist ein berechtigter Einwand, der durch strukturierte Ausgabeformate, Validierungsschichten und Konfidenzwerte lösbar ist – aber eben aktiv gelöst werden muss.

Diese Vorteile sind real. Aber sie sind Vorteile der Reife – nicht der Technologie. Und in einer Phase, in der sich die Technologie fundamental verändert, kann Reife zum Rückstand werden.

Warum „etabliert“ gerade das falsche Kaufkriterium ist

In normalen Technologiezyklen ist es sinnvoll, auf etablierte Anbieter zu setzen. Reife Software, bewährte Prozesse, bekannte Risiken – das ist die sichere Wahl. Aber wir befinden uns nicht in einem normalen Zyklus.

Generative KI entwickelt sich in einem Tempo, das in der Enterprise-Software beispiellos ist. Alle sechs bis zwölf Monate erscheinen neue Modellgenerationen, die die vorherigen in Genauigkeit, Geschwindigkeit und Kosteneffizienz übertreffen. Unternehmen, die LLMs als Kern ihrer Architektur gebaut haben, können jede dieser Generationen direkt nutzen – weil ihr System dafür ausgelegt ist.

Etablierte Anbieter können das nicht. Ihre Architekturen sind auf Templates, Regelwerke und klassische OCR ausgelegt. KI-Features werden als Erweiterung draufgesetzt, nicht als Fundament eingebaut. Das bedeutet: Jede neue LLM-Generation erfordert bei ihnen Monate an Integrationsarbeit – wenn sie überhaupt aufgegriffen wird. Das Ergebnis ist ein wachsender Abstand.

Der Abstand wächst, er schrumpft nicht

Wer heute einen template-basierten Anbieter wählt, weil er „etabliert“ ist, kauft sich in eine Architektur ein, die mit jeder neuen Modellgeneration weiter zurückfällt. LLM-native Anbieter dagegen werden mit jedem Modell-Update schneller, günstiger und genauer – ohne dass sich am Produkt selbst viel ändern muss. Die Schere geht auf, nicht zu.

Das ist der entscheidende Punkt: In stabilen Märkten ist Erfahrung ein Vorteil. In einem Markt, der sich gerade grundlegend verschiebt, ist Geschwindigkeit wichtiger als Erfahrung. Und die Geschwindigkeit liegt bei den Unternehmen, die von Anfang an auf LLMs gesetzt haben – weil sie nicht umbauen müssen, sondern einfach weiterfahren.

Die Kosten des Bleibens

Wechselkosten werden oft überschätzt, Bleibekosten unterschätzt. Wer bei einem template-basierten System bleibt, zahlt weiterhin:

2–8h

Pro neuem Lieferant

Template-Erstellung, Feld-Mapping, Testläufe, Korrekturen. Bei 50 neuen Lieferanten pro Jahr summiert sich das.

30–40%

Manuell nachbearbeitet

Belege, die kein Template haben oder falsch erkannt werden. Jeder davon braucht menschliche Prüfung und Korrektur.

Steigend

Template-Wartung

Lieferanten ändern ihr Layout, Rechnungen werden digitaler, neue Formate kommen dazu. Die Template-Bibliothek wächst, der Aufwand auch.

Die unsichtbare Kostenposition

Die teuerste Zeile in der Rechnung eines template-basierten Systems steht nirgendwo: die Belege, die gar nicht erst automatisiert werden, weil sich das Template nicht lohnt. Bei Lieferanten mit wenigen Rechnungen pro Jahr bleibt alles manuell – und genau diese Lieferanten machen oft den Großteil der Lieferantenbasis aus.

Fazit

Template-basierte Systeme waren das globale Maximum ihrer Ära. Sie haben Finanzteams zum ersten Mal ermöglicht, Belegverarbeitung in großem Stil zu automatisieren. Das war ein echter Fortschritt.

Aber die Technologie hat sich weiterentwickelt. Large Language Models ermöglichen einen Ansatz, der strukturell anders funktioniert: keine Templates, kein Feld-Mapping, kein lineares Skalierungsproblem. Das verändert nicht nur die Erkennungsrate – es verändert die Architektur der Lösung.

Die Frage für Finanzteams ist nicht, ob das bestehende System „funktioniert“ – das tut es wahrscheinlich. Die Frage ist: Steht es auf dem richtigen Gipfel? Oder gibt es jenseits des Tals einen höheren?

LLM-native Systeme erreichen bereits über 80% vollautomatische Belegverarbeitung über alle Formate hinweg. Zum Vergleich: Der Branchendurchschnitt liegt bei 33%, selbst Top-Performer mit template-basierten Systemen kommen auf rund 50% (Ardent Partners, 2025). Dazu ein Monatsabschluss im Top-Quartil unter fünf Tagen (APQC: 4,8 Tage) und bis zu 80% Kostenreduktion pro Beleg. Das sind keine Zukunftsvisionen – andere Finanzteams erreichen diese Werte bereits.