2 % Skonto bei Zahlung innerhalb von 10 Tagen, jede Rechnung: So
automatisieren Sie die Verfolgung von Frühzahlungsrabatten
Benchmark-Daten von APQC zeigen, dass die durchschnittliche Organisation zwar 96 % der Rechnungen pünktlich bezahlt, aber nur etwa 15 % innerhalb des Frühzahlungsrabatt-Zeitraums. Das Institute of Finance & Management (IOFM) beziffert die Zahl sogar noch niedriger: Die meisten Organisationen nutzen weniger als 21 % der verfügbaren Frühzahlungsrabatte. Dabei erzielt eine 2/10-Netto-30-Kondition eine annualisierte Rendite von rund 36 % – eine risikofreie Verzinsung, die die meisten operativen Margen übertrifft. Die Lücke zwischen der Rabattchance und dem, was Teams tatsächlich realisieren, ist kein Prozessineffizienz. Es ist ein versteckter Kapitalallokationsfehler.
Wichtige Erkenntnisse
- Bis zu 237.000 $ an Frühzahlungsrabatten verfallen jährlich stillschweigend in einem 50-Mio.-$-Beschaffungsbudget – Geld, das Ihre Lieferanten Ihnen bereits zugesagt haben, das aber niemand jemals in der Zahlungsbedingungszeile liest.
- Die manuelle Kreditorenbuchhaltung benötigt durchschnittlich 12 Tage vom Eingang bis zur Genehmigung, aber 2/10-Netto-30-Rabatte schließen am 10. Tag – Ihr Team ist nicht zu langsam, der Erkennungsschritt fehlt einfach im Workflow.
- Ein Extraktionsschritt mit ImageToTable.ai beim Rechnungseingang überführt Zahlungsbedingungen in eine Google-Tabelle, in der bedingte Formatierung auslaufende Fristen markiert – kein ERP-Ersatz, keine sechsmonatige Initiative, sondern nur eine Erkennungsschicht, die das abfängt, was die manuelle Erfassung immer übersieht.
Die Skonto-Mathematik, die niemand prüft
Die meisten AP-Teams können die 2/10 netto 30 Formel aufsagen: bei Zahlung innerhalb von 10 Tagen 2 % Rabatt. Was sie nicht sagen können, ist ihre tatsächliche Skontoausschöpfungsquote, denn die meisten AP-Abteilungen im Mittelstand erfassen diese nicht als separate Kennzahl. Die verfallenen Skonti tauchen in keinem Bericht auf. Sie verschwinden in der Lücke zwischen Bruttorechnungsbetrag und Zahlungsbetrag — zum vollen Preis gebucht, zum vollen Preis bezahlt, ohne Buchungssatz, der das mögliche Einsparpotenzial markiert.
Die annualisierte Rechnung macht die Kosten der Gleichgültigkeit deutlich. Ein Skonto von 2 % für eine Zahlung 20 Tage früher ergibt annualisiert rund 36 %: Sie geben 20 Tage Liquidität auf, um 2 % zu verdienen, und wenn Sie diesen Tausch 18 Mal im Jahr wiederholen könnten, beträgt Ihre Rendite 36 %. Selbst ein 1/10 netto 30 Skonto — seltener, aber im Großhandel noch üblich — liegt annualisiert bei etwa 18 %. Beide Werte liegen deutlich über den Kapitalkosten der meisten mittelständischen Unternehmen, bei denen ein revolvierender Kreditrahmen bis Mitte 2026 bei 9-11 % liegen könnte. Skonti zu verfallen zu lassen, während man Kreditlinien nutzt, bedeutet im Grunde, zu 10 % zu leihen, um eine Rendite von 36 % zu verschenken.
Um den Verlust in Euro zu beziffern, rechnen Sie einfach. Ein Unternehmen mit 50 Millionen Euro jährlichem Einkaufsvolumen, bei dem 30 % der Lieferantenrechnungen 2/10 netto 30 Bedingungen enthalten, hat ein maximales Skontopotenzial von 300.000 Euro pro Jahr (50 Mio. € × 30 % × 2 %). Beim IOFM-Benchmark von 21 % Ausschöpfung erzielt das Team etwa 63.000 Euro. Die restlichen 237.000 Euro — fast eine Viertelmillion Euro risikofreier Einsparungen — verfallen, weil niemand den Skonto vor Tag 10 erkannt hat. Bei der APQC-Ausschöpfungsquote von 15 % ist der Verlust noch größer.
Dies ist kein Verhandlungsproblem. Es ist ein Erkennungs- und Geschwindigkeitsproblem. Die Skontobedingungen stehen bereits auf den Rechnungen, die Ihr Team täglich bearbeitet. Ihre Lieferanten haben ihnen bereits zugestimmt. Die einzige Frage ist, ob Ihr AP-Prozess sie rechtzeitig erkennt, um zu handeln.
Warum 10 Tage nicht reichen, wenn die Verarbeitung 17 Tage dauert
Um zu verstehen, warum manuelle AP-Workflows keine Skonti erfassen, muss man den Zeitablauf betrachten, nicht den Aufwand. Der typische manuelle Rechnungsverarbeitungszyklus dauert 10 bis 17 Tage vom Eingang bis zur Zahlungsfreigabe, so die Ardent Partners-Studie „State of ePayables 2025“. Spitzenteams mit Automatisierung bearbeiten eine Rechnung in 3,1 Tagen. Ein 2/10 netto 30 Skonto verfällt jedoch am 10. Tag. Die Rechnung ist brutal: Wenn Ihre Verarbeitungspipeline im Schnitt 12 Tage braucht und das Skontofenster 10 Tage beträgt, müsste Ihr Team diese eine Rechnung jedes Mal schneller bearbeiten als alle anderen – jedes einzelne Mal.
Was tatsächlich passiert, ist schlimmer als der Durchschnitt vermuten lässt. Der Zeitablauf gliedert sich in drei aufeinanderfolgende Phasen mit eigenen Verzögerungen – und die Skontofrist interessiert nicht, welche Phase die Zeit verbraucht hat:
Ein gut strukturierter automatisierter Rechnungsgenehmigungs-Workflow kann die Stufen 2 und 3 zusammenfassen, aber der Engpass liegt oft in Stufe 1: Niemand weiß, dass ein Skonto existiert, bis jemand manuell das Zahlungsbedingungsfeld auf der Rechnung liest und es eingibt. Dieser Schritt dauert 5-10 Sekunden pro Rechnung – kurz genug, dass niemand es als Problem betrachtet, aber lang genug, dass bei einem Stapel von 400 Rechnungen skontofähige Rechnungen in der Masse untergehen und in Standardreihenfolge statt priorisiert bearbeitet werden.
Wo Skontobedingungen in Ihren Rechnungen tatsächlich versteckt sind
Das zweite strukturelle Hindernis für die Skontoerfassung ist, dass Zahlungsbedingungen kein standardisiertes Feld sind. Anders als die Rechnungsnummer – die fast immer im oberen rechten Kopfblock erscheint – tauchen Skontoangaben an mindestens fünf verschiedenen Stellen auf, ohne einheitliche Bezeichnung oder Format über Lieferanten hinweg:
| Position | Beispieltext | Warum die manuelle Eingabe es übersieht |
|---|---|---|
| Kopfblock (nahe Rechnungsdatum) | Zahlungsbedingungen: 2/10 Netto 30 | Am besten sichtbar, aber oft übersehen, wenn der Sachbearbeiter zuerst auf Rechnungsnummer und Betrag achtet. |
| Fußnoten | 2 % Skonto bei Zahlung innerhalb von 10 Tagen nach Rechnungsdatum | Fußzeilentext wird bei der Dateneingabe routinemäßig ignoriert; Sachbearbeiter scrollen darüber hinweg. |
| Positionen oder Zwischensummenbereich | Skonto: -240,00 € (bei Zahlung bis 15.06.) | Selten, aber sehr wertvoll – der Skonto ist bereits berechnet. Sachbearbeiter lesen möglicherweise nicht über den Positionsbetrag hinaus. |
| E-Mail-Text (Begleitnachricht) | Hinweis: 2 % Frühbucher-Skonto bei Zahlung bis Monatsende | Die E-Mail ist von der Rechnung in der Genehmigungswarteschlange getrennt. Niemand überträgt sie. |
| Lieferantenspezifische Notation | Skonto 2 % bei Zahlung innerhalb 10 Tagen (Deutsch), Escompte 2 % pour paiement sous 10 jours (Französisch) | Mehrsprachige Bedingungen internationaler Lieferanten sind für englischsprachige Datenerfasser unsichtbar. |
Diese Variabilität führt dazu, dass selbst ein gewissenhafter Kreditorenbuchhalter, der beabsichtigt, Skonti zu nutzen, einige verpasst – weil die Skontoangabe nicht dort steht, wo er sie erwartet, oder nicht in einem Format, das er sofort erkennt. Das Problem verschärft sich mit der Menge: Bei 50 Rechnungen pro Tag verbringt ein Buchhalter, der jede Rechnung gründlich nach Skontobedingungen durchsucht, 30–60 Sekunden pro Dokument allein für die Erkennung – das sind 25–50 Minuten zusätzliche Arbeit pro Tag für eine Aufgabe, die bei vielleicht 30 % der Rechnungen Einsparungen bringt. Die meisten Teams entscheiden implizit, dass diese Zeit besser für die Erfassung von Rechnungsbeträgen genutzt wird.
Hier wird auch die Grenze zwischen strukturierten E-Rechnungen und PDF-Rechnungen betrieblich relevant. Eine EDI- oder Peppol-Rechnung enthält Zahlungsbedingungen in einem getaggten Feld (BT-20 in EN 16931), das ab Erhalt maschinenlesbar ist. Eine PDF-Rechnung enthält dieselben Informationen als zu Text angeordnete Pixel – für einen Menschen visuell offensichtlich, für einen traditionellen ERP-Import unsichtbar. Für Unternehmen, die den Übergang zu E-Rechnungspflichten in Frankreich oder Deutschland bewältigen, wird der strukturierte Kanal das Erkennungsproblem irgendwann lösen. Für die PDF-Rechnungen, die bis 2028 und darüber hinaus neben E-Rechnungen bestehen bleiben, ist die Extraktion die Brücke.
Ein Drei-Schritte-Workflow von Extraktion zu Kennzeichnung, der in Ihren bestehenden Stack passt
Der Weg, mehr Skonti zu nutzen, erfordert weder den Austausch Ihres ERP, den Kauf einer vollständigen AP-Automatisierungslösung noch die Neugestaltung Ihres Genehmigungsprozesses von Grund auf. Es erfordert einen einzigen Erkennungsschritt beim Rechnungseingang, der für jede Rechnung eine Frage beantwortet: Bietet diese Rechnung ein Skonto, und wann läuft es ab?
Der Workflow nutzt die Extraktion benutzerdefinierter Spalten: Statt eine Vorlage für bestimmte PDF-Layouts zu trainieren, definieren Sie die Spaltennamen, die die KI aus jedem Dokument extrahieren soll – wie „Zahlungsbedingungen", „Rechnungsdatum" und „Skontofälligkeitsdatum" – und die KI liest das Dokument, um diese Werte zu finden, wo immer sie erscheinen. Dies unterscheidet sich grundlegend von templatebasierten OCR-Tools, bei denen Sie Felder manuell einkreisen müssen. Bei der Extraktion versteht die KI die semantische Bedeutung von „Zahlungsbedingungen" und lokalisiert diese Informationen unabhängig davon, ob sie in der Kopfzeile, Fußzeile oder in Positionsnotizen stehen.
Rechnungsdatum, Zahlungsbedingungen, Rechnungsbetrag und optional Skontofrist. Die KI liest jedes Dokument und gibt eine strukturierte Tabelle mit diesen Feldern zurück. Für berechnete Spalten können Sie Skontofrist als berechnetes Feld definieren — Rechnungsdatum + 10 Tage bei 2/10 netto 30 — sodass die Frist ohne manuelles Kalenderzählen direkt im Ergebnis steht.=DAYS(Skontofrist; HEUTE()). Wenden Sie bedingte Formatierung an: grün bei mehr als 7 Tagen, gelb bei 3–7 Tagen, rot bei weniger als 3 Tagen oder überfällig. So entsteht eine Prioritätsübersicht, die auslaufende Skonti vor Ablauf anzeigt — ohne manuelle Prüfung von Rechnungsdaten.Dateien werden sicher verarbeitet und nicht gespeichert.
Was diesen Ansatz vom Kauf einer durchgängigen AP-Automatisierungsplattform unterscheidet, ist, dass er die Erkennung auf der Eingangsebene löst, ohne Änderungen an der Genehmigungs- oder Zahlungsebene zu erzwingen. Ihr Team nutzt weiterhin dasselbe ERP, dieselbe Genehmigungsroute und denselben Zahlungsplan. Der Extraktionsschritt läuft vorgelagert zu all dem – er beantwortet die Frage „Welche Rechnungen müssen schneller bearbeitet werden?“, bevor sie in die Pipeline gelangen, sodass die Pipeline selbst nicht geändert werden muss.
Die Tabelle ist das Dashboard, nicht das System of Record. Die Extraktion speist Ihre Google-Tabelle mit strukturierten Daten. Bedingte Formatierung hebt hervor, was Aufmerksamkeit erfordert. Ihr ERP bleibt das maßgebliche Hauptbuch. Die Tabelle ist eine Erkennungsschicht zwischen Rechnungseingang und ERP-Erfassung – leichtgewichtig genug für eine Implementierung an einem Nachmittag, spezifisch genug, um zu ändern, welche Rechnungen an Tag 9 statt an Tag 14 bezahlt werden.
Wenn Skonti nicht Ihre oberste Priorität sind
Nicht jede AP-Abteilung sollte 2/10 netto 30 Skonti nachjagen. Die wirtschaftliche Logik von Skonti hängt von zwei Bedingungen ab: Die Skontobedingungen existieren in Ihrer Lieferantenbasis, und ihre Nutzung schafft keinen Cashflow-Nachteil, der schlechter ist als die Rendite.
In Fertigungs- und Schwerindustrie-Lieferketten sind Zahlungsziele von netto 60 und netto 90 die Norm – nicht netto 30. Ein Hersteller, der Rohstoffe auf netto 60 von Lieferanten bezieht, die gar keine Skonti anbieten, gewinnt nichts durch den Aufbau eines Skonto-Erkennungsworkflows. Gleiches gilt für das Baugewerbe, wo Abschlagsrechnungen und Einbehalte Standardskonti selten machen. Für diese Branchen kommt der ROI der AP-Automatisierung aus anderen Hebeln: Senkung der Bearbeitungskosten pro Rechnung, Vermeidung von Säumniszuschlägen oder Erkennung von Doppelzahlungen durch Multi-Feld-Abgleich.
Die Skonto-Erfassung konzentriert sich auf Branchen, in denen Handelskreditbedingungen standardisiert sind und die Margen dünn genug sind, dass 2 % einen Unterschied machen. Einzelhandel, Großhandel, Lebensmittel und Getränke sowie Konsumgüter (FMCG) sind die stärksten Kandidaten. In diesen Sektoren ist 2/10 netto 30 eine Standardbedingung großer Distributoren und Hersteller, und die Rechnungsvolumina sind hoch genug – oft Tausende pro Monat –, dass der kumulierte Skontowert wesentlich ist. Ein mittelständischer Lebensmittelhändler, der 3.000 Rechnungen pro Monat von Lieferanten wie Sysco, US Foods oder regionalen Großhändlern verarbeitet, bei denen 40 % der Rechnungen Skontobedingungen enthalten, hat ein jährliches Skontopotential im niedrigen sechsstelligen Bereich. Selbst die Hälfte davon zu erfassen, ist die Kosten für den Aufbau des Extraktionsworkflows wert.
Die Cashflow-Einschränkung ist real und sollte nicht ignoriert werden. Die Bezahlung aller skontofähigen Rechnungen am Tag 10 bedeutet eine Beschleunigung der Mittelabflüsse um 20 Tage im Vergleich zur Zahlung am Tag 30. Für ein Unternehmen mit knappem Working Capital ist diese Beschleunigung möglicherweise nicht bei allen Lieferanten umsetzbar, selbst wenn die Mathematik eine annualisierte Rendite von 36 % ergibt, die die Kapitalkosten übertrifft. Die richtige Strategie ist selektiv: Priorisieren Sie hochwertige Rechnungen von strategischen Lieferanten, zahlen Sie den Rest zu Standardbedingungen und nutzen Sie das Dashboard mit bedingter Formatierung, um diese Abwägungen sichtbar zu machen, anstatt sie standardmäßig geschehen zu lassen. Ein Multi-Feld-Extraktionsansatz, der bereits Rechnungsdaten für die Duplikatserkennung bereitstellt, kann hier doppelt nützlich sein – dieselben extrahierten Felder, die Duplikate erkennen, speisen auch das Skonto-Tracking-Blatt.
Eine Nuance noch: Zahlungsbedingungen sind manchmal verhandelbar. Ein Lieferant, der Netto 30 ohne Rabatt anbietet, ist vielleicht offen für 2/10 Netto 30, wenn Sie nachweisen können, dass Ihr Zahlungsprozess zuverlässig das 10-Tage-Fenster einhält. Bauen Sie zuerst die Erkennungsfähigkeit auf – beweisen Sie, dass Sie schnell genug verarbeiten können –, dann haben Sie die Daten, um mit Lieferanten, die derzeit keine Rabatte anbieten, bessere Konditionen auszuhandeln. Der Workflow zahlt sich doppelt aus: einmal durch das Erfassen bestehender Rabatte und ein zweites Mal durch die Schaffung der Nachweise, die nötig sind, um den Rabattpool zu erweitern.
FAQ
Kann dieser Workflow Zahlungsbedingungen in verschiedenen Sprachen verarbeiten?
Ja. Da die Extraktion KI nutzt, die Dokumententexte semantisch liest, anstatt vordefinierte Vorlagen abzugleichen, erkennt sie Zahlungsbedingungen auf Deutsch (Skonto), Französisch (escompte), Spanisch (descuento por pronto pago) und anderen Sprachen ohne Konfigurationsänderungen. Die Ausgabe erfolgt stets als strukturierte Daten mit englischen Spaltenüberschriften. Dies ist besonders wichtig für Unternehmen, die bei europäischen Lieferanten einkaufen, wo Peppol-E-Rechnungen und nationale Formate neben PDF-Rechnungen existieren.
Was ist, wenn die Zahlungsbedingungen in einem gescannten bildbasierten PDF versteckt sind?
Das Extraktionstool verarbeitet bildbasierte PDFs – gescannte Dokumente, bei denen der Text als Pixel vorliegt, nicht als auswählbare Zeichen. Es wendet Vision-Modell-OCR an, um den Dokumenteninhalt zu lesen und darin die Zahlungsbedingungen zu identifizieren. Dies ist wichtig, da viele Lieferantenrechnungen als gescannte Anhänge eingehen, bei denen die traditionelle textbasierte Analyse vollständig versagt.
Wie gehen Sie mit Rechnungen mit dynamischen oder gestaffelten Rabatten um?
Die Extraktion erfasst, was in der Rechnung steht. Lauten die Bedingungen „3 % bei Zahlung innerhalb von 5 Tagen, 2 % bei Zahlung innerhalb von 15 Tagen, Netto 30“, extrahiert die KI den vollständigen Text. Für die Entscheidungsfindung kann Ihre bedingte Formatierungsformel in Google Sheets auf beide Stufen verweisen und diejenige markieren, deren Frist als nächstes ansteht. Für komplexere Logik – etwa Rabatte, die als Funktion des Zahlungsdatums berechnet werden – ermöglicht die Funktion „Berechnete Spalten“ die Definition von Regeln, die den anwendbaren Rabatt basierend auf dem aktuellen Datum relativ zum Rechnungsdatum berechnen.
Ersetzt dies eine AP-Automatisierungssoftware?
Nein. Der Workflow von Extraktion bis Markierung löst ein spezifisches Problem: Skonto-Möglichkeiten rechtzeitig zu erkennen und zu nutzen. Er automatisiert weder den Drei-Wege-Abgleich, die Kontenzuordnung, die Zahlungsausführung noch die ERP-Synchronisation. Für Unternehmen mit weniger als 500 Rechnungen pro Monat können dieser Workflow und eine Tabellenkalkulation ausreichen. Bei höheren Volumen dient er als Erkennungsschicht, die in einen breiteren automatisierten Genehmigungsworkflow einfließt. Der Punkt ist: Man muss nicht alle AP-Probleme auf einmal lösen, um mehr Skonti zu sichern.
Was, wenn unsere Lieferanten meist Zahlungsziele von 60 oder 90 Tagen netto gewähren?
Dann sollte die Skonto-Erfassung nicht Ihre oberste Priorität sein. Der Workflow hat nur begrenzten Nutzen, wenn das Skonto-Potenzial gering ist. In diesem Fall sollten Sie Ihre AP-Automatisierung darauf konzentrieren, die Bearbeitungskosten pro Rechnung zu senken und Zahlungsverzug zu vermeiden. Die breitere Entwicklung hin zu E-Rechnungspflichten in Europa könnte die Zahlungsbedingungen der Lieferanten ändern, sobald strukturierte Rechnungsdaten zum Standard werden. Derzeit bringen Netto-60/90-Umgebungen jedoch mehr Nutzen durch Genauigkeit und Kostensenkung als durch schnellere Zahlungen.
Ab welchem Rechnungsvolumen ist dieser Ansatz sinnvoll?
Bei 50 Rechnungen pro Monat sind die Zahlen so gering, dass eine manuelle Prüfung durch eine Einzelperson machbar sein kann – aber nur, wenn diese Person diszipliniert jede Rechnung kontrolliert. Bei 100–200 Rechnungen pro Monat ist der Extraktions-Workflow durchgängig zuverlässiger als die manuelle Prüfung, da das Volumen die Schwelle überschreitet, ab der ein Mensch zwangsläufig einige skontofähige Rechnungen übersieht. Der Break-even hängt von Ihrem durchschnittlichen Rechnungsbetrag und Skontosatz ab, aber die wiederkehrenden Einsparungen bedeuten, dass sich der Workflow bei moderaten Volumen schnell amortisiert.
Erster Schritt: Ein Monat, eine Tabelle
Das Schlimmste wäre, über Skonto-Erfassungsquoten zu lesen, das Problem zu erkennen und es unter „Wir brauchen eine AP-Automatisierungsinitiative" abzulegen. Eine Initiative bedeutet sechs Monate Anbieterbewertung, Budgetgenehmigung und Implementierungsplanung – in denen ein weiterer Skonto-Zyklus verfällt.
Ein besserer Start: Führen Sie einen Monat lang die Extraktion Ihrer eingehenden Rechnungen durch. Definieren Sie drei Spalten – Rechnungsdatum, Zahlungsbedingungen, Rechnungsbetrag. Geben Sie die Ergebnisse in ein Google Sheet mit der oben beschriebenen bedingten Formatierungsformel ein. Vergleichen Sie am Monatsende die markierten Rechnungen mit dem, was Ihr Team tatsächlich wann bezahlt hat. Die Differenz zwischen den von der Tabelle identifizierten und den von Ihrem Team erfassten Skonti zeigt das Ausmaß des Problems. Ist die Zahl klein, bestätigt das, dass Ihr aktueller Prozess funktioniert. Ist sie groß – und das wird sie für die meisten AP-Teams im Mittelstand sein – haben Sie einen einmonatigen Pilotversuch, der den ROI belegt, ohne dass ein Ausschusstreffen nötig ist.