Zwei Prozent Skonto bei Zahlung binnen zehn Tagen, sonst dreißig Tage netto. Wer diese Frist verstreichen lässt, nimmt für die zwanzig Tage dazwischen einen Kredit zu rund 36 Prozent Jahreszins auf. Die kaufmännische Formel dafür lautet Skontosatz mal 360, geteilt durch die Differenz aus Zahlungsziel und Skontofrist, hier also 2 mal 360 geteilt durch 20. Rechnet man genauer, bezogen auf den Betrag, der nach Abzug tatsächlich zu finanzieren ist, kommt man auf 36,7 Prozent. Beide Varianten stehen so bei controllingportal.de, das Ergebnis für 2/10 netto 30 lässt sich am Skonto-Rechner von sevDesk nachrechnen.
Die Kennzahl, mit der ein KI-Rechnungsprojekt bewertet wird, kennt diesen Betrag nicht. DocuWare definiert die Touchless-Quote in einem eigenen Fachbeitrag als „the percentage of invoices that complete the full cycle (receipt, data extraction, matching, validation, approval, posting) without a person getting involved”. Prozentanteil der Rechnungen. Nicht des Volumens. Medius, ein Anbieter aus derselben Kategorie, lässt Lieferanten im eigenen Touchless-Dashboard nach der Anzahl der Rechnungen sortieren, „by number of invoices”, um Quoten zu vergleichen. Auch dort ist die Zähleinheit der Beleg.
Wir haben den Use Case für automatisierte Rechnungsverarbeitung ausgearbeitet und beraten Unternehmen dazu. Wie schon im Text zur internen Wissensdatenbank rechnet dieser Beitrag einen unserer eigenen Business-Cases nach. Diesmal lautet der Befund nicht, dass der Nutzen woanders liegt. Er liegt genau dort, wo die Kalkulation ihn verspricht. Nur zählt die Kennzahl, die ihn belegen soll, in einer anderen Einheit als das Geld.
Der Business-Case addiert Belege und Euro
Unser Use Case nennt zwei Effekte nebeneinander. Erstens sinken die Bearbeitungskosten je Rechnung von 12 bis 25 Euro auf 3 bis 6 Euro. Zweitens steigt die Skonto-Ausschöpfung von 40 bis 70 Prozent auf 85 bis 95 Prozent, in der Vergleichstabelle in beiden Spalten ausdrücklich als Schätzwert aus Praxisberichten gekennzeichnet. Dazu die Dunkelverarbeitung: 60 bis 80 Prozent der Rechnungen laufen nach der Einlernphase vollautomatisch durch, im Use Case als Anbieterangabe ausgewiesen.
Der erste Wert ist ein Stückpreis. Er skaliert sauber mit der Belegmenge, jede eingesparte Rechnung ist gleich viel wert. Der dritte ebenfalls. Der zweite nicht. Skonto-Ausschöpfung ist kein Stückwert, sondern die Frage, welche Rechnungen rechtzeitig freigegeben wurden. Und Rechnungen sind unterschiedlich groß.
Kostenrahmen, Tool-Auswahl, GoBD und Auftragsverarbeitung behandeln wir im Use Case zur automatisierten Rechnungsverarbeitung. Hier geht es um eine einzige Zeile dieser Tabelle.
Die Betragsgrenze schickt genau die teuren Rechnungen an einen Menschen
Der Use Case beschreibt die dritte Stufe des Prozesses so: Plausible Rechnungen bis zu einem definierten Betragslimit werden automatisch zur Zahlung vorgemerkt, Rechnungen über dem Limit gehen mit einem vorausgefüllten Freigabe-Link an die zuständige Person. Als typischen Startwert für dieses Limit nennen wir 500 Euro.
Das ist eine gute Empfehlung, und sie bleibt es. Der Schwellwert schützt vor genau den Fehlern, die am Monatsabschluss teuer werden. Nur trennt er nicht zufällig.
Eine Beispielrechnung mit ausgeschriebenen Annahmen, keine Marktdaten: zwei Eingangsrechnungen, beide mit 2 Prozent Skonto, die eine über 300 Euro, die andere über 40.000 Euro. Der Skontobetrag beträgt 6 Euro gegen 800 Euro. In der Dunkelverarbeitungsquote zählt jede von beiden als ein Beleg. Die kleine läuft automatisch durch. Die große liegt bei einem Menschen. Unser eigener Use Case rechnet an anderer Stelle mit demselben Muster: 2 Prozent Skonto auf eine 10.000-Euro-Rechnung sind 200 Euro, die durch einen einzigen verspäteten Freigabeschritt verloren gehen.
Eine belastbare Zahl dazu, welcher Anteil der Belege welchen Anteil des Euro-Volumens trägt, haben wir gesucht und nicht gefunden. Für das Argument braucht es sie auch nicht. Es genügt die Richtung: Die Betragsgrenze sortiert nach genau der Größe, an der das Skonto hängt. Je sauberer sie gesetzt ist, desto systematischer liegt das Geld auf der manuellen Seite.
Bearbeitungszeit misst das Tippen, nicht das Warten
Dieselbe Vergleichstabelle nennt zwei Zeiten, und sie haben verschiedene Einheiten. Die Bearbeitungszeit je Rechnung sinkt von 8 bis 15 Minuten auf 1 bis 3 Minuten. Die Durchlaufzeit bis zur Zahlung sinkt von 5 bis 12 Werktagen auf 1 bis 3 Werktage.
Zwischen drei Minuten Bearbeitung und drei Werktagen Durchlauf liegt keine Arbeit. Da liegt Wartezeit. Die Automatisierung verbessert den kleineren der beiden Posten sehr zuverlässig, und die Kennzahl, mit der das Projekt bewertet wird, hat für den größeren keine Spalte.
Wie lange in Deutschland tatsächlich gewartet wird, misst der Creditreform Zahlungsindikator Deutschland Winter 2025/26, veröffentlicht am 3. Februar 2026 auf Basis von rund 3,8 Millionen Rechnungsbelegen aus dem Creditreform Debitorenregister Deutschland. Im zweiten Halbjahr 2025 lag die Verzugsdauer im deutschen B2B-Geschäft bei durchschnittlich 7,50 Tagen, bei einem durchschnittlichen Zahlungsziel von 32,13 Tagen, den großzügigsten Zahlungsfristen seit über sieben Jahren.
Zur Reichweite dieser Zahl gehört eine Einschränkung: Creditreform misst, wann bezahlt wurde, nicht warum. Der Indikator weist interne Freigabeprozesse nicht als Ursache aus, und dieser Text behauptet das auch nicht. Was er zeigt, ist die Größenordnung. Wer im Schnitt 7,5 Tage nach einem Zahlungsziel von gut 32 Tagen zahlt, liegt rund dreißig Tage hinter einer typischen Skontofrist von zehn Tagen. Das Skonto-Fenster wird in diesem Markt nicht knapp verfehlt. Es ist gar nicht erst im Blick.
Die Kennzahl, die den fehlenden Teil abbilden würde, existiert längst, nur in einer anderen Werkzeugkategorie. Process Mining misst die Liegezeit je Prozessschritt statt der Gesamtdurchlaufzeit, und eingelöste Skontofristen tauchen dort regelmäßig als Nutzenposten auf. Was das kostet und ab welcher Größe es sich rechnet, steht im Use Case zum Geschäftsprozess-Mining.
Die Grenze ist die Funktion, nicht der Fehler
Das stärkste Gegenargument kommt von der Anbieterseite, und es ist berechtigt. Die Betragsgrenze ist keine Schwachstelle, sie ist der Zweck der Sache. DocuWare beschreibt dieses Design im selben Beitrag als Normalfall: „Approval is straightforward for invoices that fall within pre-defined thresholds.” Reibung entsteht dort bei „non-standard invoices and policy exceptions”, nicht an der Schwelle selbst. Eine wertgewichtete Automatisierungsquote wäre nach dieser Logik sogar schädlich, weil sie ausgerechnet die teuren Rechnungen aus der menschlichen Kontrolle herausrechnen würde.
Das stimmt, und dieser Text will die Grenze nicht abschaffen. Ein vorausgefüllter Freigabe-Link verkürzt die Liegezeit tatsächlich. Gegenüber einer PDF-Mail an drei Verteiler ist das ein großer Unterschied, und wer das bestreitet, hat den Prozess vorher nicht gesehen.
Der Einwand beantwortet nur eine andere Frage als die gestellte. Er begründet, dass eine Schwelle existieren soll. Er sagt nichts darüber, wie lange Rechnungen dahinter liegen bleiben. Genau diese Zahl fehlt, auch bei uns: Unsere Vergleichstabelle führt die Skonto-Ausschöpfung als Bandbreite und markiert sie in beiden Spalten als Schätzwert. Eine gemessene Wartezeit je Freigabestufe steht dort nicht, weil wir sie nicht haben. Der Einwand trägt also unter einer Bedingung, die im üblichen Projekt nicht erfüllt ist: dass die Freigabe-Warteschlange selbst eine Frist und eine Messung hat.
Die Erkennung schrumpft per Gesetz. Die Freigabe nicht.
Der eine Teil dieses Prozesses wird in den nächsten zwei Jahren von selbst kleiner, der andere nicht.
Laut FAQ des Bundesministeriums der Finanzen zur E-Rechnung gilt die Empfangspflicht für E-Rechnungen im inländischen B2B-Bereich seit dem 1. Januar 2025, ohne Übergangsfrist. Die Ausstellungspflicht ist gestaffelt. Bis Ende 2026 läuft eine Übergangsphase, in der andere Formate noch zulässig sind. Ab dem 1. Januar 2027 müssen Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz E-Rechnungen ausstellen. Unternehmen bis zu dieser Umsatzgrenze dürfen für 2027 noch Papierrechnungen versenden. Ab dem 1. Januar 2028 gilt die Pflicht für alle.
Für die Erkennungsseite bedeutet das, dass sie schrittweise verschwindet. Bei XRechnung und ZUGFeRD liegen die Felder strukturiert vor, OCR entfällt, wie unser Use Case in der ersten Prozessstufe beschreibt. Die Erkennungsrate, an der heute Projekte gemessen und Tools verglichen werden, ist bei diesen Formaten schlicht kein Thema mehr.
Keine dieser Fristen berührt die Freigabe. Der Gesetzgeber regelt das Format, nicht die Frage, wann der Prokurist auf den Link klickt. Wer sein Projekt heute an der Erkennungsrate misst, misst ausgerechnet die Größe, die der Gesetzgeber gerade erledigt. Unser älterer Überblick zu KI in der Buchhaltung sortiert diese Werkzeugebene, also Belegscan, Erkennung und DATEV-Anbindung. Diese Ebene wird gerade billiger. Die Freigabeebene nicht.
Drei Zahlen, die dein Tool heute nicht anzeigt
Keine davon braucht ein neues Werkzeug.
Erstens: der Anteil des Rechnungsvolumens in Euro, der innerhalb der Skontofrist freigegeben wurde. Nicht der Anteil der Belege. Diese eine Umstellung der Zähleinheit macht den Abstand zwischen den beiden Zahlen sichtbar, mit denen dieser Text anfängt. Wenn dein System die Quote nur in Stück ausgibt, exportier die Freigabedaten und rechne sie einmal im Monat von Hand nach. Das ist eine Pivot-Tabelle, kein Projekt.
Zweitens: die Liegezeit je Freigabestufe, nicht die Gesamtdurchlaufzeit. Vier Tage Durchlauf sagen nicht, ob drei davon bei einer einzigen Person lagen, die im Urlaub war. Diese Auflösung brauchst du, weil die Gegenmaßnahme davon abhängt: Ein zweiter Freigeber löst ein anderes Problem als eine geänderte Reihenfolge.
Drittens: eine Eskalationsregel mit Frist statt einer reinen Betragsgrenze. Die Grenze legt fest, wer freigeben muss. Sie legt nicht fest, bis wann. Eine Rechnung, die 48 Stunden vor Ablauf der Skontofrist noch offen ist, muss jemanden erreichen, der nicht der ursprüngliche Freigeber ist.
Die dritte Regel ist die unbequeme. Sie bestimmt, wer im Zweifel ohne den eigentlich Zuständigen entscheidet, und damit ist sie keine Konfigurationsfrage der Buchhaltung mehr, sondern eine Entscheidung der Geschäftsführung über Vertretung und Vollmacht. In bezahlten Kundenprojekten stellt sie sich regelmäßig erst, wenn der Schwellwert im Tool längst eingetragen ist. Warum der Mensch in dieser Kette überhaupt bleibt und nicht wegautomatisiert wird, haben wir an anderer Stelle aufgeschrieben.
Zehn Rechnungen, eine halbe Stunde
Nimm die zehn größten Eingangsrechnungen des letzten Quartals. Sieh nach, an welchem Tag sie freigegeben wurden, und halte das gegen die jeweilige Skontofrist. Zehn Belege von vielleicht tausend, in der Automatisierungsquote also ein Prozent, statistisch nichts.
In Euro sind sie es nicht. Wenn davon mehr als zwei zu spät dran waren, hast du gerade den Teil deines Rechnungsvolumens geprüft, über den deine Automatisierungsquote nichts aussagt. Sie wird es auch im nächsten Quartal nicht tun, denn sie zählt weiter Belege.