Im B2B-Handel wird selten per Vorkasse gekauft. Der Rechnungskauf ist die mit Abstand beliebteste Zahlungsart: 95 Prozent der B2B-Einkäufer wollen im Online-Shop auf Rechnung bestellen, doch nur 45 Prozent der Händler bieten diese Option an (bevh). Wer sie anbietet, gewährt jedem Geschäftskunden faktisch einen Lieferantenkredit -- und trägt damit ein Ausfallrisiko. Dieses Risiko ist 2026 real: Die Zahl der Unternehmensinsolvenzen erreichte 2025 mit rund 23.900 Fällen den höchsten Stand seit über zehn Jahren, ein Plus von 8,3 Prozent gegenüber dem Vorjahr (Creditreform), und im März 2026 lagen die beantragten Verfahren um 15,8 Prozent über dem Vorjahresmonat (Destatis). Ein Kreditlimit-Check direkt im Checkout gleicht Kreditlimit, offene Posten und Zahlungsziel in Echtzeit aus dem ERP ab, bevor die Bestellung bestätigt wird -- und entscheidet, ob der Rechnungskauf freigegeben, begrenzt oder gesperrt wird. Dieser Artikel zeigt, wie die Zahlungsanbindung an SAP, Dynamics oder DATEV technisch funktioniert und wie sich das Ausfallrisiko in den Bestellprozess einbetten lässt.
Das Wichtigste in Kürze
- Der Kreditlimit-Check prüft vor der Bestellbestätigung in Echtzeit, ob Kreditlimit, offene Posten und Zahlungsziel eines Geschäftskunden die Bestellung tragen.
- Datenquelle ist das ERP oder die Finanzbuchhaltung: SAP, Microsoft Dynamics oder DATEV liefern Kreditlimit, Saldo und überfällige Posten über eine Schnittstelle.
- Das Ergebnis steuert den Checkout: Freigabe des Rechnungskaufs, Teilfreigabe mit Anzahlung oder Umschaltung auf Vorkasse bei überschrittenem Limit.
- Fällt das ERP aus, verhindert eine definierte Rückfallstrategie, dass der Shop entweder blind freigibt oder pauschal blockiert.
- Die Prüfung verarbeitet wirtschaftliche und personenbezogene Daten und gehört auf eine saubere datenschutzrechtliche Grundlage.
Warum der Kreditlimit-Check 2026 zum Liquiditätsschutz wird
Ein ausgefallener Rechnungskauf trifft den Lieferanten doppelt: Die Ware ist raus, das Geld kommt nicht. Für 2025 schätzt Creditreform die Schadensumme aus Unternehmensinsolvenzen auf rund 57 Milliarden Euro, bei einer durchschnittlichen Ausfallforderung von über 2 Millionen Euro je Insolvenzfall (Creditreform). Das Statistische Bundesamt registrierte für das Gesamtjahr 2025 24.064 beantragte Unternehmensinsolvenzen, ein Plus von 10,3 Prozent (Destatis), und im ersten Quartal 2026 lag die Zahl der Verfahren um 6,5 Prozent über dem Vorjahresquartal (Destatis). Besonders betroffen sind kleine Firmen: 81,6 Prozent aller Unternehmensinsolvenzen entfielen 2025 auf Betriebe mit bis zu zehn Beschäftigten (Creditreform) -- also genau auf die Kundengruppe, die im B2B-Shop häufig auf Rechnung bestellt.
Auch das Zahlungsverhalten verschiebt das Risiko nach hinten. Das durchschnittlich eingeräumte Zahlungsziel im deutschen B2B-Geschäft stieg im zweiten Halbjahr 2025 auf 32,13 Tage und damit auf den höchsten Wert seit über sieben Jahren (Creditreform). Zwar sank die Verzugsdauer auf 7,50 Tage (Creditreform), doch jeder Tag zwischen Lieferung und Zahlung ist ein Tag Kreditrisiko. Eine verspätet bezahlte Rechnung hatte im Schnitt einen Wert von 1.838 Euro (Creditreform) -- summiert über viele offene Posten entsteht schnell ein spürbarer Betrag, der im Insolvenzfall gefährdet ist. Wie sich Zahlungseingänge später sauber mit den offenen Posten abgleichen lassen, zeigt unser Beitrag zur Payment Reconciliation im ERP-Abgleich.
Der Checkout ist die letzte Kontrollinstanz
Lieferantenkredit inklusive
Jeder Rechnungskauf ist ein kurzfristiger Kredit an den Kunden. Ohne Limitprüfung wächst das offene Obligo unkontrolliert.
Lange Zahlungsziele
Zahlungsziele von 30 Tagen und mehr verlängern die Spanne, in der eine Forderung offen und damit gefährdet ist.
Viele kleine Bestellungen
Stammkunden bestellen mehrfach im Monat. Erst die Summe aller offenen Posten zeigt, ob das Limit noch trägt.
Verteilte Datenhoheit
Das Kreditlimit lebt im ERP, die Bestellung im Shop. Ohne Schnittstelle kennt der Checkout den aktuellen Saldo nicht.
Veraltete Stände
Nächtliche Exporte hinken der Realität hinterher. Zwischen zwei Läufen kann ein Kunde sein Limit längst ausgeschöpft haben.
Manuelle Freigabe zu spät
Eine Prüfung im Backoffice nach Bestelleingang bremst die Lieferung und greift erst, wenn die Bestellung schon steht.
Was der Checkout prüft: Kreditlimit, offene Posten, Zahlungsziel
Ein Kreditlimit-Check ist mehr als ein Ja-Nein-Schalter. Er wertet mehrere Kennzahlen aus dem ERP gemeinsam aus und leitet daraus eine Entscheidung ab. Die folgende Übersicht zeigt, welche Größen einfließen, woher sie stammen und wie sie im Checkout wirken.
| Kennzahl | Herkunft | Wirkung im Checkout |
|---|---|---|
| Kreditlimit | ERP-Debitorenstamm | Obergrenze des zulässigen offenen Obligos |
| Saldo offener Posten | Debitorenkonto | Mindert den verfügbaren Rahmen |
| Überfällige Posten | Offene-Posten-Liste | Lösen Warnung oder Sperre aus |
| Zahlungsziel | Zahlungsbedingungen | Steuert Fristen und Skonto |
| Sperrkennzeichen | Debitorenstamm | Blockiert den Rechnungskauf sofort |
| Bonitäts- oder Risikoklasse | ERP oder Auskunft | Verschärft oder lockert die Regel |
Die zentrale Rechengröße ist der verfügbare Rahmen: Kreditlimit minus Saldo der offenen Posten minus Wert des aktuellen Warenkorbs. Im Beispiel des Schaubilds stehen einem Kreditlimit von 50.000 Euro offene Posten von 28.500 Euro gegenüber -- der verfügbare Rahmen beträgt also 21.500 Euro. Eine Bestellung über 9.200 Euro passt hinein; nach der Buchung ist das Limit zu rund 75 Prozent ausgelastet, der Rechnungskauf wird freigegeben. Läge der Warenkorb über dem verfügbaren Rahmen, würde der Checkout auf Vorkasse umschalten oder eine Teilzahlung anbieten. Ergänzend fließt die Überfälligkeit ein: Stehen bereits Rechnungen über der zulässigen Verzugsschwelle offen, wird der Rechnungskauf auch dann gesperrt, wenn das nominale Limit rechnerisch noch trägt.
Damit die Rechnung im Checkout stimmt, müssen auch die kundenindividuellen Preise korrekt sein -- der geprüfte Warenkorbwert entscheidet über Freigabe oder Sperre. Wie sich kundenspezifische Preise und Staffeln aus dem ERP sauber in den Shop bringen lassen, ist deshalb eng mit dem Kreditlimit-Check verzahnt. Die eigentliche Prüflogik gehört in eine zentrale Middleware, damit sie für alle Verkaufskanäle einheitlich greift und bei Regeländerungen an einer Stelle gepflegt wird.
Der Echtzeit-Datenfluss vom Checkout ins ERP
Der Kern der Lösung ist ein schneller, nachvollziehbarer Datenfluss zwischen Checkout und ERP. Er beginnt, sobald der Kunde die Zahlart Rechnung wählt, und endet mit einer Entscheidung, die der Shop unmittelbar umsetzt. Dazwischen liegen wenige, klar abgegrenzte Schritte.
- Warenkorb-Snapshot: Der Checkout ermittelt Kunde (Debitor), Warenkorbwert und gewählte Zahlart.
- Bonitätsabfrage: Eine Anfrage an die Schnittstelle holt Kreditlimit, Saldo und überfällige Posten aus dem ERP.
- Regelauswertung: Die Middleware berechnet den verfügbaren Rahmen und wendet die Freigaberegeln an.
- Entscheidung zurück: Der Checkout erhält Freigabe, Teilfreigabe oder Sperre samt Begründung.
- Protokollierung: Anfrage, Antwort und Entscheidung werden revisionssicher festgehalten.
Entscheidend ist die Antwortzeit. Die Prüfung liegt auf dem kritischen Pfad des Kaufabschlusses, also darf sie den Checkout nicht spürbar bremsen. In der Praxis bedeutet das eine schlanke API-Anbindung mit klarem Zeitlimit, möglichst direkte Abfragen statt schwergewichtiger Exporte und einen kurzlebigen Zwischenspeicher für wiederkehrende Abfragen desselben Kunden. Wie sich Shop und ERP technisch in Echtzeit koppeln lassen, vertieft unser Beitrag zur SAP-Shopware-Echtzeit-Synchronisation. Die Freigaberegel selbst lässt sich kompakt ausdrücken:
def evaluate_credit(customer, cart, erp):
data = erp.credit_snapshot(customer.debtor_id)
# data: credit_limit, open_balance, overdue, blocked
if data.blocked or data.overdue > OVERDUE_LIMIT:
return Decision("prepayment", reason="blocked_or_overdue")
available = data.credit_limit - data.open_balance
if cart.total <= available:
return Decision("invoice", reason="within_limit")
if cart.total <= available + TOLERANCE:
deposit = cart.total - available
return Decision("partial", reason="near_limit", deposit=deposit)
return Decision("prepayment", reason="limit_exceeded")Order-Freigabe, Sperre und Rechnungskauf steuern
Das Ergebnis der Prüfung ist kein reines Ja oder Nein, sondern ein abgestuftes Set an Entscheidungen. Jede Stufe hat eine passende Reaktion im Checkout, die das Ausfallrisiko begrenzt, ohne konvertierende Bestellungen unnötig abzuweisen.
| Situation | Entscheidung | Kundenerlebnis |
|---|---|---|
| Warenkorb unter Rahmen, keine Überfälligkeit | Rechnungskauf freigegeben | Bestellung wie gewohnt |
| Warenkorb knapp über Rahmen | Teilfreigabe mit Anzahlung oder reduzierte Menge | Alternative statt Abbruch |
| Limit überschritten oder Sperrkennzeichen | Umschaltung auf Vorkasse oder Karte | Bestellung möglich, ohne Kreditrisiko |
| Überfällige Posten über Schwelle | Rechnungskauf gesperrt, Hinweis auf Klärung | Schutz vor weiterem Obligo |
Sperren heißt nicht verlieren
Welche Zahlarten im Sperrfall angeboten werden, wird in der Zahlungsanbindung konfiguriert. Kommen Bestellungen nicht über den Shop-Checkout, sondern über ein Beschaffungsportal des Kunden, gelten dieselben Regeln -- die Prüfung wandert dann an die Übergabestelle des Auftrags. Wie sich solche Prozesse anbinden lassen, beschreibt unser Beitrag zur OCI-Punchout-Anbindung von Beschaffungsportalen.
Anbindung an SAP, Dynamics und DATEV
Wo die Kreditdaten liegen, hängt vom führenden System ab. In SAP verwalten das klassische Kreditmanagement oder SAP Credit Management das Kreditlimit je Debitor; offene Posten und Saldo lassen sich über standardisierte Schnittstellen abfragen. In Microsoft Dynamics 365 sind Kreditlimit und Zahlungsbedingungen im Debitorenstamm hinterlegt und über die Business-Central- oder Finance-Schnittstellen erreichbar. In der DATEV-Welt liegen vor allem die offenen Posten und der Debitorenstamm vor -- ein explizites Kreditlimit wird hier häufig in der Middleware oder im Shop gepflegt und mit den offenen Posten aus DATEV kombiniert.
SAP
Kreditlimit im klassischen Kreditmanagement oder SAP Credit Management, Saldo und offene Posten je Debitor über standardisierte Schnittstellen.
Microsoft Dynamics 365
Kreditlimit und Zahlungsbedingungen im Debitorenstamm, abrufbar über die Business-Central- oder Finance-Schnittstellen.
DATEV
Offene Posten und Debitorenstamm als Basis; das Kreditlimit wird ergänzend in der Middleware geführt und mit den DATEV-Daten kombiniert.
Damit die Prüfung verlässlich ist, muss der Debitorenstamm konsistent geführt sein -- eine Kundennummer, ein Limit, ein Saldo, keine Dubletten. Wie sich Stammdaten dafür sauber synchronisieren lassen, vertieft unser Beitrag zur Stammdaten-Synchronisation mit MDM. Erst auf dieser Basis liefert der Kreditlimit-Check belastbare Entscheidungen statt Fehlalarme durch inkonsistente Kundenzuordnungen.
Performance, Ausfallsicherheit und Datenschutz
Eine Bonitätsprüfung im Checkout ist nur so gut wie ihre Verfügbarkeit. Weil sie auf dem kritischen Pfad des Kaufabschlusses liegt, braucht sie definiertes Verhalten für den Fall, dass das ERP langsam oder nicht erreichbar ist. Die folgenden Maßnahmen halten den Checkout stabil, ohne das Risiko aus dem Blick zu verlieren.
- Zeitlimit mit definiertem Verhalten: Antwortet das ERP nicht in wenigen hundert Millisekunden, greift eine vorab festgelegte Rückfallregel statt einer Hängepartie.
- Konservativer Fallback: Bei fehlender Antwort wird der Rechnungskauf eher zurückgestellt als blind freigegeben -- das schützt vor Fehlentscheidungen.
- Kurzlebiger Cache: Ein Limit-Snapshot mit wenigen Minuten Gültigkeit fängt Lastspitzen ab, ohne veraltete Stände zu riskieren.
- Idempotente Abfragen: Wiederholte Prüfungen derselben Bestellung dürfen keine widersprüchlichen Entscheidungen oder Doppelbuchungen erzeugen.
- Lückenlose Protokollierung: Jede Entscheidung ist mit Zeitstempel, Eingangsdaten und Regelbezug nachvollziehbar.
Die Prüfung bewegt sensible Daten -- Kreditlimit, Zahlungshistorie, bei externen Auskünften auch Bonitätsmerkmale. Diese Verarbeitung braucht eine saubere Rechtsgrundlage, Datensparsamkeit und eine dokumentierte Zweckbindung; abgefragt wird nur, was für die Freigabeentscheidung nötig ist. Weil die Schnittstelle zwischen Shop und ERP eine sensible Strecke ist, gehört sie technisch abgesichert. Wie sich ERP-Schnittstellen gegen unbefugten Zugriff härten lassen und was die NIS2-Richtlinie dabei verlangt, beschreibt unser Beitrag zur NIS2-konformen Absicherung von ERP-Schnittstellen. Ergänzend zeigt der Leitfaden zur Fehlerbehandlung in Schnittstellen, wie Ausnahmen kontrolliert aufgefangen werden, statt still zu scheitern.
Kein blindes Freigeben bei Systemausfall
Projektablauf einer Kreditlimit-Integration
Rund die Hälfte der Unternehmen automatisiert ihre Geschäftsprozesse bereits mit digitalen Technologien (Bitkom) -- der Kreditlimit-Check ist ein konkreter, gut abgrenzbarer Baustein davon. Die Umsetzung folgt typischerweise fünf Phasen, wobei die enge Abstimmung mit Buchhaltung und Kreditmanagement über die Qualität der Regeln entscheidet.
Fünf Phasen bis zum produktiven Kreditlimit-Check
- 1
Bestandsaufnahme
Führendes System (SAP, Dynamics oder DATEV), vorhandenes Kreditmanagement, angebotene Zahlarten und Sonderfälle wie Sammelbesteller erfassen.
- 2
Regelwerk definieren
Freigabegrenzen, Toleranzen, Umgang mit überfälligen Posten und Fallback gemeinsam mit Buchhaltung und Kreditmanagement festlegen.
- 3
Schnittstelle bauen
Konnektor zum ERP, Prüflogik in der Middleware und Rückgabe der Entscheidung an den Checkout entwickeln.
- 4
Testlauf mit Echtdaten
Historische Bestellungen gegen die Regeln prüfen, Grenzen kalibrieren und die Antwortzeiten unter Last messen.
- 5
Go-Live und Monitoring
Produktivbetrieb mit Überwachung von Freigabequote, Sperren und Antwortzeiten, gefolgt von kontinuierlicher Feinjustierung.
Häufige Stolpersteine und wie man sie vermeidet
Aus Integrationsprojekten kristallisieren sich wiederkehrende Fehler heraus. Wer sie von Anfang an einplant, spart teure Nacharbeit und vermeidet Fehlentscheidungen im Livebetrieb.
- Nächtlicher Export statt Echtzeit: Zwischen zwei Läufen ausgeschöpfte Limits bleiben unentdeckt, bis es zu spät ist.
- Nur Limit, keine Überfälligkeit: Ein eingehaltenes Limit bei längst überfälligen Rechnungen ist trügerisch -- die Verzugsprüfung gehört dazu.
- Warenkorb nicht mitgerechnet: Wer nur den Bestandssaldo prüft, übersieht den Wert der aktuellen Bestellung.
- Harte Sperre ohne Alternative: Ein Abbruch ohne Ersatz-Zahlart kostet den Umsatz, den eine Vorkasse-Option gerettet hätte.
- Kein Fallback bei ERP-Ausfall: Blindes Freigeben oder pauschales Blockieren sind beide teuer -- die Rückfallregel muss definiert sein.
- Datenschutz nachrangig behandelt: Bonitätsdaten ohne Rechtsgrundlage und Zweckbindung zu verarbeiten, ist ein vermeidbares Risiko.
Ein Kreditlimit-Check ist kein Misstrauen gegenüber dem Kunden, sondern die Bedingung dafür, den bequemen Rechnungskauf überhaupt breit und dauerhaft anbieten zu können.
Quellen und Studien