n8n 4 weclapp: Zahlungen automatisch zuordnen

Bankumsätze kommen in weclapp über die Bankanbindung oder einen Kontoauszug-Import an, und weclapp ordnet schon beim Verarbeiten einen Teil davon selbst zu. Was übrig bleibt, landet bei dir: Zahlungen, bei denen der Kunde nicht erkannt wurde, die Rechnungsnummer zu kurz war oder die Rechnung erst nach der Zahlung entstand. Diese Seite zeigt, welche dieser Fälle der Agent übernimmt, welche er bewusst liegen lässt und wie du ihn einrichtest.

Das Wichtigste in Kürze

• Er ordnet zu, er bucht nichts um. Der Agent verknüpft einen Bankumsatz mit einem offenen Posten über die weclapp-Funktion zur Zahlungszuordnung (createPaymentApplication). Andere Datensätze schreibt er nicht.
• Nur eindeutige Treffer. Gleiche Währung, genau der offene Betrag und ein klarer Grund. Passen zwei Rechnungen oder zwei Zahlungen, ordnet er keine davon zu.
• Er ergänzt weclapp. Er prüft jede Stunde erneut alle noch offenen Bankumsätze. So findet er auch Zahlungen, deren Rechnung erst später angelegt wurde, und Rechnungsnummern, die weclapp wegen ihrer Länge nicht sucht.
• Altbestand bleibt unberührt. Er nimmt nur offene Posten, Rechnungen und Bankumsätze ab dem Stichtag cutoffDate und läuft erst, wenn du ihn gesetzt hast. Nach dem Import steht er im Probelauf.
• Fehler werden gemeldet. Eine gescheiterte Zuordnung bleibt offen, der nächste Lauf versucht es erneut, und du bekommst eine Fehlermail. Auch ein Lauf, der an den Einstellungen, an einer Abfrage oder an der Lesegrenze scheitert, schickt eine Mail.

Was bringt dir der Agent?

weclapp erkennt beim Verarbeiten neuer Transaktionen den Kunden über IBAN oder den vollständig gleichen Namen und ordnet zu, wenn der Betrag passt oder eine Rechnungsnummer mit mindestens sechs Zeichen im Verwendungszweck steht. Mehrere offene Posten mit gleichem Betrag bleiben dort offen. Der Agent setzt an den Fällen an, die danach übrig sind, und arbeitet sie stündlich ab statt erst beim nächsten Durchgang in der Buchhaltung.

Der Nutzen ist vor allem Ordnung und Tempo: Die Liste der offenen Posten stimmt früher, Mahnungen gehen nicht an Kunden, die längst bezahlt haben, und in der Zuordnungsansicht bleiben nur die Zahlungen, bei denen wirklich jemand entscheiden muss. Wie viel Zeit das spart, hängt davon ab, wie viele Zahlungen bei dir heute von Hand zugeordnet werden. Rechne mit deinen eigenen Werten:

Wert	Woher du ihn nimmst
A: von Hand zugeordnete Zahlungen pro Monat	Banktransaktionen, die nach der automatischen Verarbeitung offen bleiben
B: Anteil, den der Agent übernimmt	der Probelauf: Anzahl in payments (alle Treffer, nicht nur die des nächsten Laufs) geteilt durch die offenen Bankumsätze
C: Minuten je Zuordnung von Hand	deine Erfahrung, inklusive Suchen der Rechnung
Gesparte Stunden pro Monat	A × B × C ÷ 60

Fazit: Der Agent ersetzt nicht die Buchhaltung, er räumt die eindeutigen Fälle weg, bevor jemand sie anfasst.

Wie arbeitet der Agent?

Jede Stunde liest der Agent die offenen Posten ohne Zahlungszuordnung und die noch nicht ausgeglichenen Bankumsätze einer Richtung: Zahlungseingänge zu Ausgangsrechnungen (direction = sales) oder Zahlungsausgänge zu Eingangsrechnungen (purchase). Dann bildet er Paare. Ein Paar zählt nur, wenn Währung und offener Betrag auf den Cent gleich sind und der Bankumsatz keinem anderen Kunden zugeordnet ist. Für jedes Paar prüft er vier Regeln in fester Reihenfolge:

Regel	Wann sie greift
1. Transaktions-ID	Eine ID, die dein Shop in einem Textfeld der Rechnung ablegt (z. B. die PayPal-Transaktion), steht im Buchungstext.
2. Rechnungsnummer	Die Rechnungsnummer steht als ganzes Wort im Verwendungszweck, ab vier Zeichen. „1001“ zählt nicht in „10012“. Ist am Bankumsatz kein Kunde zugeordnet, reicht die Nummer erst ab sechs Zeichen; eine kürzere zählt dann nur mit Regel 4.
3. Kunde und Datum	weclapp hat den Bankumsatz schon dem Kunden zugeordnet, und er liegt höchstens dateToleranceDays Tage (Standard 2) neben dem Rechnungsdatum.
4. Name im Text	Ohne Kunde am Bankumsatz: Der vollständige Firmenname, zwei Wörter aus Firmen- oder Nachname oder eine kurze Rechnungsnummer stehen im Verwendungszweck, und die Daten liegen nah beieinander. Der Vorname und allgemeine Wörter wie „Zahlung“ zählen nicht, Betrag und Datum allein reichen nie.

Konkurrieren in einer Regel zwei Paare um denselben offenen Posten oder denselben Bankumsatz, ordnet der Agent keines davon zu, auch nicht über eine schwächere Regel. Bei den Regeln 3 und 4 lässt er ein Paar außerdem liegen, wenn der Kunde noch einen offenen Posten mit demselben Betrag hat, auch einen vor dem Stichtag, oder wenn im Verwendungszweck eine andere Rechnungsnummer steht. So landet die Zahlung für die alte Abo-Rechnung nicht auf der neuen. Die eindeutigen Paare ordnet er nacheinander zu, höchstens maxPaymentsPerRun je Lauf (Standard 5); der Rest kommt im nächsten Lauf.

Fazit: Ein Paar braucht immer den exakten Betrag und einen zweiten, unabhängigen Hinweis.

Welche Zahlungen nimmt der Agent, welche nicht?

Setz cutoffDate auf heute. Der Agent nimmt nur offene Posten und Rechnungen, die ab diesem Tag angelegt wurden, und nur Bankumsätze ab diesem Buchungstag. Alte offene Posten aus den Vorjahren rührt er nicht an, auch wenn heute eine passende Zahlung eingeht. Er liest sie nur mit, um mehrdeutige Fälle zu erkennen. Ohne gültiges Datum ordnet er nichts zu und meldet das per Mail.

Er lässt außerdem liegen:

• Teilzahlungen und Skonto: Der Betrag muss genau dem offenen Betrag entsprechen. Skonto berücksichtigt weclapp bei der eigenen Erkennung, der Agent nicht.
• Sammelüberweisungen: Eine Zahlung für mehrere Rechnungen hat keinen gleichen Einzelbetrag.
• Gebühren und Fremdwährung: Bankumsatz und Rechnung brauchen dieselbe Währung und denselben Betrag.
• Gutschriften und Sonderposten: Er nimmt nur offene Posten vom Typ Debitor bzw. Kreditor.
• Bankumsätze über der Lesegrenze: Je Lauf liest er höchstens 1.000 Bankumsätze ab dem Stichtag (HTTP-Fassung 20.000). Kommt er an der Grenze an, ordnet er nichts zu und meldet den Abbruch per Mail, statt den Rest zu übergehen.
• Bank-Quellen, die du ausschließt: Mit bankOrigins begrenzt du ihn etwa auf ["FINAPI", "PAYPAL"]; leer heißt alle.

Alle Bedingungen prüft der Agent nach der Abfrage noch einmal je Datensatz im Code, bevor er zuordnet.

Fazit: Was nicht eindeutig ist, bleibt in weclapp für dich liegen.

Was passiert bei einem Fehler?

Lehnt weclapp eine Zuordnung ab, etwa weil jemand den Bankumsatz zwischen Abfrage und Zuordnung von Hand verknüpft hat, kommt eine Fehlermail mit Rechnung, Bankumsatz, Betrag und einem Link auf den Lauf in n8n. Die HTTP-Fassung schreibt die Begründung aus der weclapp-Antwort hinein, zum Beispiel „HTTP 400: …“; die Fassung mit Community-Node bekommt von der Node keine Begründung und meldet nur, dass weclapp die Zuordnung nicht bestätigt hat. Den Zuordnungsaufruf wiederholt der Agent nie automatisch, und eine Zuordnung zählt erst, wenn weclapp sie in der Antwort bestätigt. Ein abgelehntes Paar versucht er im nächsten Lauf erst nach allen anderen, damit es die Warteschlange nicht blockiert.

Scheitert der ganze Lauf, weil eine Konstante fehlt, eine Abfrage an weclapp fehlschlägt oder die Lesegrenze erreicht ist, ordnet er nichts zu und schickt eine Mail „the run stopped“ mit dem Schritt und dem Grund. Dieselbe Meldung kommt höchstens einmal in errorMailRepeatHours Stunden (Standard 24), der Lauf endet als fehlgeschlagen. Keine Mail ist möglich, wenn die Mailadressen fehlen oder der Mailserver die Mail ablehnt; dafür hinterlegst du in n8n zusätzlich einen Error-Workflow.

Ein bereits zugeordneter offener Posten und ein ausgeglichener Bankumsatz tauchen im nächsten Lauf nicht mehr auf. Eine falsche Zuordnung löst du in weclapp wie gewohnt: im Schnellbuchungsfenster der Banktransaktion über das rote X oder durch Löschen der Zahlung am offenen Posten. Ein Paar, das du so gelöst hast, ordnet der aktive Workflow nicht noch einmal zu; er führt es nur noch unter review.

Fazit: Jeder Fehler, den n8n verschicken kann, kommt als Mail, und eine gelöste Zuordnung bleibt gelöst.

Wie richtest du den Agent ein?

1. Importieren: Lade die passende Fassung in n8n. Mit Community-Node hinterlegst du ein Weclapp API-Credential, in der HTTP-Fassung setzt du weclappBaseUrl und ein Header-Auth-Credential mit dem Namen AuthenticationToken und deinem weclapp-API-Token.
2. Konstanten setzen: direction, cutoffDate (heute), die Mailadressen und n8nBaseUrl, die Adresse deiner n8n für den Link in der Fehlermail. Optional mailBrand = neutral für eine Mail ohne wals.pro-Logo, bankOrigins und transactionIdAttributeId, die ID eines Textfelds an der Rechnung, in dem dein Shop die Transaktions-ID ablegt.
3. Fehlermail: Hinterlege ein SMTP-Credential an „Send error email“ und in den Workflow-Einstellungen einen Error-Workflow für den Fall, dass keine Mail rausgeht.
4. Probelauf: dryRun steht auf true. Starte „Manual start“ und lies die Ausgabe von „Select payments“: payments zeigt jede Zuordnung, die der Agent machen würde, auch über maxPaymentsPerRun hinaus, review die mehrdeutigen Fälle. Prüf jede vorgeschlagene Zuordnung in weclapp.
5. Scharf schalten: Stimmen die Vorschläge, setz dryRun auf false und aktiviere den Workflow. Für Zahlungsausgänge importierst du den Agent ein zweites Mal mit direction = purchase.

Fazit: Erst der Probelauf, dann die Zuordnung, und der Stichtag schützt alles davor.

Steckbrief

Trigger	stündlich und von Hand
Standard je Lauf	höchstens 5 Zuordnungen (maxPaymentsPerRun)
Nach dem Import	Probelauf, inaktiv, startet erst mit Stichtag und Mailadressen
Richtung	Zahlungseingänge oder Zahlungsausgänge, je Kopie eine
Schreibt in weclapp	nur die Zahlungszuordnung am offenen Posten
Voraussetzungen	weclapp mit Bankumsätzen (Bankanbindung oder Kontoauszug-Import), API-Token, n8n, SMTP für die Fehlermail
Fassungen	mit Community-Node @wals-pro/n8n-nodes-weclapp oder nur mit HTTP-Request-Nodes

Fazit: Klein eingestellt, im Probelauf und mit Stichtag – der Agent fängt vorsichtig an.

Was ist im Download?

• Anleitung als PDF: Einrichtung, alle Konstanten, die vier Regeln, Probelauf, Aktivieren und jede Fehlermeldung mit Lösung.
• Agent mit Community-Node: match-bank-payments.weclapp-node.json für n8n mit installiertem @wals-pro/n8n-nodes-weclapp.
• Agent als HTTP-Fassung: match-bank-payments.http.json für n8n ohne Community-Nodes, zum Beispiel n8n Cloud.

Der Agent kostet nichts: Du schließt die Bestellung zu 0 € ab und bekommst den Download-Link mit der Bestellbestätigung per Mail und auf der Bestellstatusseite.

Fazit: Beide Fassungen tun dasselbe – nimm die, die zu deiner n8n-Instanz passt.

Was passt dazu?

• Zahlungsabgleich 4 weclapp: Wenn PayPal oder American Express Sammelzahlungen schicken, löst der Zahlungsabgleich sie in einzelne Zahlungen samt Gebühren auf, bewertet unsichere Treffer und legt sie dir zur Prüfung vor, für Debitoren und Kreditoren zugleich.
• n8n 4 weclapp Autopilot: Der kostenlose Agent trägt den Auftrag von der Bestätigung bis zur Rechnung; die Zahlung dazu ordnet dieser Agent zu.
• Weiterlesen: weclapp automatisieren: alle Bausteine.

Fazit: Für eindeutige Einzelzahlungen reicht der Agent, für Sammelavise und Prüfvorlagen gibt es den Zahlungsabgleich.

Technik: Wie sieht der Aufruf an die weclapp-API aus?

Für Zahlungseingänge liest der Agent offene Posten samt Rechnung und Bankumsätze und ordnet dann zu (REST API v2, Stichtag als Zeitstempel in Millisekunden):

curl -G "https://DEIN-MANDANT.weclapp.com/webapp/api/v2/salesOpenItem" \
  -H "AuthenticationToken: DEIN-TOKEN" \
  --data-urlencode "cleared-eq=false" \
  --data-urlencode "createdDate-ge=1764543600000" \
  --data-urlencode "includeReferencedEntities=salesInvoiceId" \
  --data-urlencode "pageSize=1000"

curl -G "https://DEIN-MANDANT.weclapp.com/webapp/api/v2/bankTransaction" \
  -H "AuthenticationToken: DEIN-TOKEN" \
  --data-urlencode "cleared-eq=false" \
  --data-urlencode "paymentType-eq=RECEIPT" \
  --data-urlencode "effectiveDate-ge=1764543600000"

curl -X POST "https://DEIN-MANDANT.weclapp.com/webapp/api/v2/salesOpenItem/id/OFFENER-POSTEN-ID/createPaymentApplication" \
  -H "AuthenticationToken: DEIN-TOKEN" -H "Content-Type: application/json" \
  -d '{"bankTransactionId": "BANKUMSATZ-ID"}'

Ob ein offener Posten schon eine Zahlungszuordnung hat, prüft der Agent im Code, denn paymentApplications lässt sich in der API nicht filtern. Für die Mehrdeutigkeitsprüfung liest er zusätzlich alle offenen Posten mit einem der gefundenen Beträge, ohne Stichtag (amountOpen-in=["99.00","-99.00"]). Für Zahlungsausgänge heißen die Endpunkte purchaseOpenItem und purchaseInvoiceId, die Zahlungsart DISBURSEMENT.

Fazit: Drei Lesezugriffe und ein Schreibaufruf, mehr braucht der Agent von weclapp nicht.

Quellen und Grenzen

• weclapp: Wie werden Kontoauszüge in weclapp erkannt?, zur eingebauten Erkennung über IBAN, Namen, Betrag und Rechnungsnummer ab sechs Zeichen, abgerufen am 06.11.2026.
• weclapp: Wie werden offene Posten verwaltet und Zahlungen zugeordnet?, zur manuellen Zuordnung und zum Lösen einer Zuordnung, abgerufen am 06.11.2026.
• weclapp: Wie kann ich meine Kontoauszüge aktualisieren und wann wird mein Saldo aktualisiert?, zu Bankanbindung und Kontoauszug-Import, abgerufen am 06.11.2026.
• weclapp: Gibt es eine API zu weclapp und wo finde ich Informationen dazu?, zum API-Token, abgerufen am 06.11.2026.
• weclapp REST API v2 (OpenAPI-Beschreibung): GET /salesOpenItem, GET /purchaseOpenItem, GET /bankTransaction, POST /salesOpenItem/id/{id}/createPaymentApplication, POST /purchaseOpenItem/id/{id}/createPaymentApplication, Stand 16.10.2026.
• Eigener Test in einem weclapp-Testmandanten am 06.11.2026, beide Fassungen: alle vier Regeln, Zahlungseingänge und -ausgänge, Probelauf, Stichtag, Mengengrenze und Fehlerpfad. Mehrdeutige Beträge, eine Teilzahlung und eine Abweichung um einen Cent blieben wie vorgesehen offen. Nachprüfung der überarbeiteten Logik am 07.11.2026 mit echten Daten desselben Mandanten: Ein zweiter offener Posten mit gleichem Betrag schickt das Paar in die Prüfliste, ein abgelehnter Lesezugriff beendet den Lauf mit Fehlermail. Der Versand der Fehlermail über SMTP war nicht Teil der Tests.

Der Agent passt nicht, wenn die meisten deiner Zahlungen Sammelüberweisungen, Teilzahlungen oder Zahlungen mit Skonto sind, oder wenn Zahlungsdienstleister dir nur Sammelauszahlungen schicken. Dann bleibt fast alles für die Prüfung von Hand übrig.

Je Lauf liest der Agent höchstens 1.000 offene Posten und 1.000 Bankumsätze ab dem Stichtag, in der HTTP-Fassung höchstens 20.000. Bankumsätze, die zu keiner Rechnung passen, etwa Gebühren oder Gehälter, bleiben offen und zählen weiter mit. Erreicht eine Abfrage die Grenze, bricht der Lauf ab, ohne etwas zuzuordnen, und meldet das per Mail; dann schiebst du den Stichtag nach vorn.

Fazit: Der Agent ist für Einzelzahlungen mit klarem Bezug gebaut, für alles andere ist er ein Ausgangspunkt.

Häufige Fragen

Ordnet weclapp Zahlungen nicht schon selbst zu?

Ja, beim Verarbeiten neuer Bankumsätze, wenn Kunde und Betrag oder eine Rechnungsnummer ab sechs Zeichen eindeutig passen. Der Agent prüft danach jede Stunde erneut die offenen Bankumsätze und nimmt weitere eindeutige Fälle mit, etwa wenn die Rechnung erst nach der Zahlung entstand.

Was passiert bei Teilzahlungen oder Skonto?

Nichts. Der Agent ordnet nur zu, wenn der Bankumsatz genau dem offenen Betrag entspricht. Teilzahlungen und Zahlungen mit Skontoabzug bleiben für dich in weclapp liegen.

Kann der Agent falsch zuordnen, und wie mache ich das rückgängig?

Er ordnet nur bei exaktem Betrag und einem zweiten Hinweis zu und lässt alles Mehrdeutige liegen; ausschließen lässt sich ein Fehlgriff trotzdem nicht. Eine Zuordnung löst du in weclapp im Schnellbuchungsfenster der Banktransaktion über das rote X. Der aktive Workflow ordnet ein so gelöstes Paar nicht noch einmal zu.

Was ist mit alten offenen Posten?

Die ordnet der Agent nicht zu. Er nimmt nur offene Posten, Rechnungen und Bankumsätze ab dem Stichtag cutoffDate, den du beim Einrichten auf heute setzt. Ältere offene Posten mit gleichem Betrag liest er nur mit, damit eine Zahlung nicht auf der falschen Rechnung landet.

Geht das auch für Lieferantenrechnungen?

Ja. Importier den Agent ein zweites Mal und setz direction auf purchase, dann ordnet er Zahlungsausgänge den offenen Eingangsrechnungen zu.