Jeden Morgen das gleiche Bild in vielen Buchhaltungen: Der Kontoauszug kommt, jemand öffnet daneben die Liste der offenen Posten und ordnet Zahlung für Zahlung von Hand zu. Bei fünfzig Buchungen am Tag ist das lästig, bei fünfhundert ist es ein Vollzeitjob. Der größte Teil dieser Arbeit lässt sich mit n8n sauber automatisieren. Der Rest, die unklaren Fälle, wird mit Claude deutlich kleiner. Wir beschreiben hier den Aufbau, den wir in der Praxis einsetzen.
Wie der Kontoauszug ins System kommt
Bevor etwas zugeordnet werden kann, müssen die Umsätze maschinenlesbar vorliegen. In der Praxis sehen wir vier Wege:
- Bank-API: Einige Banken und die meisten Fintech-Konten bieten eine REST-Schnittstelle. n8n ruft die Umsätze per HTTP-Request ab, meist mehrmals täglich.
- EBICS oder FinTS: Der klassische Weg für Firmenkonten in Deutschland. Ein kleiner Client holt die Auszüge ab und legt sie als Datei ab, n8n übernimmt von dort.
- CAMT.053-Dateien: Das XML-Format für den Tagesauszug. Es enthält strukturierte Felder für Betrag, Gegenkonto, Verwendungszweck und Ende-zu-Ende-Referenz. Für die Zuordnung ist es die beste Quelle.
- CSV per SFTP: Oft die Übergangslösung, wenn die Bank nichts anderes anbietet oder ein Zahlungsdienstleister dazwischen sitzt. Funktioniert, braucht aber Pflege, weil sich Spalten ohne Ankündigung ändern.
Egal welcher Weg: Der erste Schritt im Workflow normalisiert jede Buchung in ein einheitliches Format. Betrag, Währung, Buchungsdatum, Name und IBAN des Zahlers, Verwendungszweck, Bankreferenz. Alles Weitere arbeitet nur noch mit diesem Format.
Der deterministische Abgleich zuerst
Der Großteil der Zahlungen lässt sich ohne KI zuordnen. Dafür holt n8n die offenen Posten aus dem ERP: bei SAP über OData oder RFC, bei DATEV über die Datenservices, bei kleineren Systemen oft direkt aus der Datenbank oder per REST. Dann prüft der Workflow in fester Reihenfolge:
- Steht eine Rechnungsnummer im Verwendungszweck und stimmt der Betrag exakt? Treffer.
- Steht eine Kundennummer im Verwendungszweck und gibt es genau einen offenen Posten mit diesem Betrag? Treffer.
- Ist die IBAN des Zahlers einem Kunden zugeordnet und passt der Betrag zu genau einer Rechnung? Treffer.
- Entspricht der Betrag der Summe mehrerer offener Posten desselben Kunden? Sammelzahlung, Treffer mit Hinweis.
Diese Regeln sind billig, schnell und nachvollziehbar. Wer an dieser Stelle schon mit einem Sprachmodell anfängt, bezahlt für etwas, das ein paar Zeilen Code besser können.
Unklare Fälle: Claude liest den Verwendungszweck
Was übrig bleibt, ist der interessante Teil. Verwendungszwecke wie "RG v. 12.3. Müller Teilzahlung" oder "Rechnungen März abzgl. Skonto" oder einfach eine Projektbezeichnung, die nur der Sachbearbeiter kennt. Hier übergibt n8n die Buchung zusammen mit den offenen Posten des wahrscheinlichen Kunden an Claude. Die Anfrage ist eng gefasst: Welcher Posten passt, warum, und wie sicher ist das.
Das Ergebnis muss strukturiert zurückkommen, sonst lässt es sich im Workflow nicht weiterverarbeiten:
{
"match": "RE-2024-0471",
"confidence": 0.82,
"reason": "Betrag entspricht Rechnung abzüglich 2 % Skonto, Kundenname im Verwendungszweck",
"flags": ["skonto"]
}
Wichtig ist, was Claude hier nicht tut: Es bucht nichts. Es schlägt vor. Die Confidence ist eine Selbsteinschätzung, keine Garantie, und wir nutzen sie nur zur Sortierung in der Freigabe.
Freigabe durch Menschen
Jeder Vorschlag aus dem unscharfen Abgleich landet in einer Freigabeliste. Das kann eine einfache Tabelle sein, ein Formular in n8n oder eine Nachricht in Teams oder Slack mit zwei Buttons. Die Sachbearbeiterin sieht Zahlung, vorgeschlagenen Posten und Begründung und bestätigt oder korrigiert mit einem Klick.
Ein Schwellenwert hilft, die Liste kurz zu halten: Vorschläge mit hoher Confidence und ohne Flags können nach einer Einführungsphase automatisch durchgehen, alles andere wartet auf Freigabe. Wo diese Schwelle liegt, entscheidet die Buchhaltung, nicht die Technik. Wir empfehlen, in den ersten Wochen alles freizugeben und die Treffsicherheit zu beobachten, bevor man die Schwelle senkt.
Buchung, Audit-Trail und Idempotenz
Nach der Freigabe schreibt n8n den Zahlungseingang ins ERP und gleicht den offenen Posten aus. Zwei Dinge müssen dabei stimmen.
Audit-Trail: Zu jeder Buchung speichern wir, woher die Zahlung kam, welche Regel oder welcher Vorschlag gegriffen hat, wer freigegeben hat und wann. Bei KI-Vorschlägen gehört die Begründung dazu. Das ist keine Kür, Wirtschaftsprüfer fragen genau danach.
Idempotenz: Kontoauszüge kommen doppelt. Die Bank liefert den Tagesauszug erneut, ein SFTP-Job läuft zweimal, jemand startet den Workflow von Hand. Jede Buchung bekommt deshalb einen eindeutigen Schlüssel aus Bankreferenz, Datum und Betrag, und der Workflow prüft vor jeder Verarbeitung, ob dieser Schlüssel schon bekannt ist. Ohne diese Prüfung bucht man irgendwann eine Zahlung zweimal, und das fällt erst beim Mahnlauf auf.
Was mit dem Rest passiert
Auch mit Claude bleibt ein Rest, der sich nicht sauber zuordnen lässt:
- Teilzahlungen: Der Betrag ist kleiner als die Rechnung. Der Workflow bucht die Zahlung auf den Posten und lässt den Restbetrag offen, mit einem Vermerk für das Mahnwesen.
- Überzahlungen und Sammelzahlungen ohne Aufschlüsselung: Vorschlag an die Freigabe, mit der wahrscheinlichsten Aufteilung.
- Unbekannte Zahler: Keine IBAN im Stamm, kein Name im Verwendungszweck, kein passender Betrag. Diese Zahlungen landen auf einem Verrechnungskonto und in einer eigenen Liste, die täglich jemand abarbeitet.
Der Punkt ist nicht, dass die Liste leer wird. Der Punkt ist, dass sie kurz wird und nur noch die Fälle enthält, bei denen ein Mensch wirklich nachdenken muss.
Fazit
Zahlungseingänge zuordnen ist zum größten Teil Regelwerk und zum kleineren Teil Interpretation. n8n übernimmt das Regelwerk, Claude die Interpretation, und die Freigabe bleibt bei Ihrem Team. Richtig aufgebaut läuft das stabil, nachvollziehbar und ohne Doppelbuchungen.
Wenn Sie wissen wollen, wie das mit Ihrer Bank und Ihrem ERP aussieht: Buchen Sie ein kostenloses 30-minütiges Erstgespräch unter /#kontakt.