Digitale Anfechtung: Vom Regelwerk zum KI-Agenten

Anfechtungsrelevante Zahlungen finden: vier Perspektiven

Zwölf Kontoauszüge, drei Konten, drei Jahre Geschäftstätigkeit. Irgendwo in diesen Buchungen stecken anfechtbare Zahlungen — inkongruente Deckungen unter Vollstreckungsdruck, Zahlungen an den Schwager des Geschäftsführers, Überweisungen kurz vor Insolvenzantrag.

Die Frage ist, wie man sie findet — und ob dabei nichts übersehen wird. Denn in den oft unstrukturierten Daten geht vieles unter.

Was ist digitale Anfechtung? Digitale Anfechtung bezeichnet den Einsatz von Software und KI zur automatisierten Prüfung anfechtbarer Rechtshandlungen nach §§ 129–147 InsO. Dabei werden Kontodaten, Buchungstexte und Verfahrensdaten systematisch ausgewertet, um anfechtungsrelevante Zahlungen zu identifizieren und Indizienketten aufzubauen.

Alle Anfechtungstatbestände setzen eine objektive Gläubigerbenachteiligung voraus (§ 129 InsO) — die Rechtshandlung muss die Befriedigungsmöglichkeiten der Gläubigergesamtheit verschlechtert haben. Was sie unterscheidet, sind die Zeiträume und die subjektiven Voraussetzungen.

Perspektive 1: Die erfahrene Sachbearbeiterin

Sie macht das seit zwölf Jahren. Sie weiß, worauf sie achten muss: Zahlungen an den Gerichtsvollzieher kurz vor Antrag. Rücklastschriften, die sich häufen. Rundbeträge an den Geschäftsführer persönlich. Eine Überweisung an “Beratung M. Schmidt” — verdächtig, weil Schmidt der Schwager des GF ist. Das steht in keiner Tabelle, das weiß sie aus der Akte.

Ihre Stärke ist Kontextverständnis. Sie liest zwischen den Zeilen, erkennt Muster, die kein Filter je abbilden könnte. Sie denkt in Tatbeständen:

• § 131 InsO (inkongruente Deckung): Zahlungen unter Vollstreckungsdruck, Pfändungen, Ratenzahlungen an den Gerichtsvollzieher — gut erkennbar in Kontodaten. Im letzten Monat vor Antrag keine subjektive Voraussetzung (Nr. 1); im zweiten und dritten Monat muss der Schuldner bereits zahlungsunfähig gewesen sein (Nr. 2) oder der Gläubiger die Benachteiligung gekannt haben (Nr. 3)
• § 130 InsO (kongruente Deckung): Reguläre Zahlungen im Dreimonatszeitraum — erkennbar, aber der Schuldner muss zum Zeitpunkt der Handlung bereits zahlungsunfähig gewesen sein, und der Gegner muss Kenntnis davon gehabt haben. Die Zahlungsunfähigkeit lässt sich aus Kontodaten ableiten, die Kenntnis steht nicht im Kontoauszug
• § 133 InsO (Vorsatzanfechtung): Zahlungen an Nahestehende, auffällige Beträge — Indizien erkennbar, aber Benachteiligungsvorsatz und Gläubigerkenntnis sind innere Tatsachen, die sich nicht aus Buchungszeilen ablesen lassen. Seit dem SanInsFoG gelten erhöhte Anforderungen bei kongruenter Deckung (dazu unten)
• § 134 InsO (unentgeltliche Leistung): Zahlungen ohne Gegenleistung — aus Kontodaten bestenfalls flaggbar, ob tatsächlich keine Gegenleistung vorlag, braucht Verträge und Rechnungen
• § 135 InsO (Gesellschafterdarlehen): Rückzahlungen an Gesellschafter im letzten Jahr vor Antrag — aus Kontodaten erkennbar, wenn Gesellschafterkonten bekannt sind. In der Praxis einer der häufigsten und wirtschaftlich relevantesten Anfechtungstatbestände

Ihre Grenze ist nicht Kompetenz — sondern Kapazität. 25 Verfahren gleichzeitig, 5.000 Buchungszeilen pro Verfahren. Sie priorisiert nach Erfahrung und wirtschaftlicher Sinnhaftigkeit — nicht jedes Verfahren hat Anfechtungspotenzial, das die Kosten rechtfertigt. Aber bei den Verfahren, die es haben, geht bei 5.000 Buchungszeilen zwangsläufig etwas unter.

Perspektive 2: Der regelbasierte Filter

Die erste Automatisierungsstufe: starre Algorithmen, die Kontodaten nach vordefinierten Kriterien durchsuchen.

“Zeige alle Zahlungen über 5.000 € im Dreimonatszeitraum vor Antrag.” “Flagge Zahlungen an Empfänger, die als nahestehend markiert sind.” “Markiere Buchungen mit Verwendungszweck ‘Gerichtsvollzieher’, ‘Vollstreckung’, ‘Pfändung’.”

Das Prinzip kennt man aus der Geldwäscheprävention (AML), wo regelbasierte Transaktionsüberwachung seit Jahren Standard ist. Im Insolvenzbereich funktioniert es ähnlich: Schwellenwerte, Zeitfenster, Textmuster.

Die Stärke: Vollständigkeit. Der Filter übersieht keine einzige Buchung. Er arbeitet alle 5.000 Zeilen ab, auf allen Konten, reproduzierbar und auditierbar. Jedes Ergebnis lässt sich auf eine konkrete Regel zurückführen — wichtig für die gerichtliche Verwertbarkeit.

Die Grenze: Kein Kontextverständnis. In der AML-Praxis mit Millionen von Banktransaktionen liegt die False-Positive-Rate bei bis zu 95 %. Bei einem Insolvenzverfahren mit 5.000 Buchungszeilen und konkretem Verfahrenswissen (Antragszeitpunkt, Gläubigerliste) ist sie niedriger — aber das Grundproblem bleibt: Ein Bauunternehmer, der im Dezember hohe Zahlungen leistet, ist nicht verdächtig — er zahlt seine Subunternehmer. Eine Zahlung an “Schmidt Consulting” ist nur dann relevant, wenn Schmidt der Schwager ist. Der Filter weiß das nicht.

Jede neue Erkenntnis muss manuell als Regel hinterlegt werden. Das System lernt nicht.

Perspektive 3: Das Sprachmodell

Large Language Models verändern die Perspektive grundlegend: Sie können zum ersten Mal Buchungstexte lesen.

“Darlehensrückzahlung GF” — ein regelbasierter Filter sieht Text. Ein LLM versteht, dass hier ein Geschäftsführer ein Darlehen zurückbekommt und das im Kontext einer Insolvenz auffällig sein könnte.

“Beraterhonorar Q3 – Kanzlei Müller” — das LLM kann einordnen, dass Beraterhonorare kurz vor Insolvenz auf Bargeschäft oder Vorsatzanfechtung hindeuten könnten.

“Privatentnahme” — zwei Worte, die kein Schwellenwertfilter flaggt, die aber ein Sprachmodell sofort als potenziell anfechtungsrelevant erkennt.

Die Stärke: Versteht Sprache, nicht nur Zahlen. Kann Verwendungszwecke interpretieren, Zahlungen nach Inhalt kategorisieren, verdächtige Formulierungen erkennen. Kann erklären, warum eine Buchung auffällig ist, statt nur zu flaggen.

Die Grenze: Kein Verfahrenswissen. Das LLM kennt weder den konkreten Zeitpunkt der Zahlungsunfähigkeit noch die Anfechtungsfristen dieses Falls. Es weiß nicht, wer in diesem Verfahren nahestehend ist. Es hat kein Gedächtnis — jede Frage beginnt bei null. Und die Zuverlässigkeit bei Rechtsfragen ist begrenzt: Eine Studie von Dahl et al. (“Large Legal Fictions”, Stanford/Cambridge, 2024) zeigt, dass LLMs bei juristischen Fragestellungen in mindestens 58 % der Fälle fehlerhafte Antworten generieren. Das betrifft vor allem komplexe rechtliche Einordnungen — bei der reinen Kategorisierung von Buchungstexten (“ist das eine Vollstreckungszahlung?”) sind die Ergebnisse deutlich besser. Aber für eine Anfechtungsprüfung, die vor Gericht standhalten muss, reicht Textverständnis allein nicht.

Perspektive 4: Der KI-Agent

Ein Agent ist kein besseres LLM. Er ist ein System, das ein LLM als Denkmotor nutzt — aber zusätzlich auf Daten zugreifen, Werkzeuge einsetzen, und mehrstufige Analysen eigenständig planen und durchführen kann. Mehr dazu im Artikel Die 5 größten Hebel für KI in der Insolvenzverwaltung.

Konkret an einem Beispiel — eine § 131-Prüfung (inkongruente Deckung):

Der Agent kennt den Insolvenzantragszeitpunkt aus der Verfahrensakte. Er berechnet die Anfechtungszeiträume — nicht nur den Ein- und Dreimonatszeitraum für §§ 130/131, sondern auch die Vierjahresfrist für §§ 133/134 InsO. Er durchsucht alle Konten nach Zahlungen in diesen Zeiträumen. Er erkennt an den Buchungstexten Vollstreckungszahlungen — “GV Amtsgericht Köln”, “Pfändung FA Düsseldorf”. Er verknüpft: Im selben Zeitraum häufen sich Rücklastschriften (Beweisanzeichen der Zahlungseinstellung). Lohnzahlungen brechen ab. Sozialversicherungsbeiträge werden nicht mehr abgeführt.

Das Ergebnis ist keine Flagge, sondern eine Indizienkette: Zahlungsunfähigkeit ab Monat X (gestützt auf Beweisanzeichen), inkongruente Deckung in den Monaten Y und Z (gestützt auf Vollstreckungszahlungen), Gesamtvolumen der potenziell anfechtbaren Zahlungen.

Die Stärke: Der Agent arbeitet wie die erfahrene Sachbearbeiterin — aber über alle Daten gleichzeitig, ohne etwas zu vergessen. Er kombiniert die Vollständigkeit des Filters (Perspektive 2) mit dem Textverständnis des LLM (Perspektive 3) und dem Verfahrenswissen, das ihm aus den konkreten Aktendaten zur Verfügung steht.

Die Grenze bleibt — und sie ist juristisch zwingend: Ob ein Bargeschäft vorliegt (§ 142 InsO), ob der Gläubiger tatsächlich Kenntnis hatte, ob die Zahlung wirtschaftlich sinnvoll war — das sind Wertungsfragen, die kein Agent beantworten kann. Die Vorsatzanfechtung nach § 133 InsO ist das deutlichste Beispiel: Benachteiligungsvorsatz ist eine innere Tatsache. KI kann Indizien sammeln — die Würdigung bleibt beim Verwalter. Ebenso kann der Anfechtungsgegner Einwendungen haben, die aus Kontodaten nicht erkennbar sind: Bargeschäftseinwand, Leistung eines Dritten, Anspruch auf anderweitige Befriedigung.

Digitale Anfechtung in der Praxis

Die vier Perspektiven schließen sich nicht gegenseitig aus — sie bauen aufeinander auf.

Für das Gutachten zur Eröffnung reicht oft eine Kombination aus regelbasiertem Screening und LLM-gestützter Kategorisierung. Für eine Anfechtungsklage, die vor Gericht standhalten muss, braucht es die vollständige Indizienkette — und die baut ein Agent schneller und vollständiger als jede manuelle Durchsicht.

Der Agent ersetzt nicht die Sachbearbeiterin. Er gibt ihr die 40 relevanten Buchungen aus 5.000, statt sie alle selbst durchgehen zu lassen. Er liefert die Datengrundlage — sie liefert die Bewertung. Und der Verwalter entscheidet, welche Ansprüche er verfolgt, welche sich wirtschaftlich lohnen, und wie er sie vor Gericht argumentiert.

Die Haftung nach § 60 InsO bleibt beim Verwalter. Wer dokumentieren kann, dass er seine Anfechtungsprüfung systematisch, vollständig und datengestützt durchgeführt hat, steht im Haftungsfall besser da als jemand, der sich auf Stichproben verlässt — vorausgesetzt, die Ergebnisse automatisierter Systeme werden eigenverantwortlich geprüft. Ein fehlerhaft konfiguriertes Tool, dessen Ergebnisse ungeprüft übernommen werden, kann die Haftung auch verschärfen.