Ist die Rechnung bezahlt? Zahlungseingänge automatisch zuordnen
Gleiche offene Rechnungen mit Bankumsätzen ab: mit Ninox oder deiner eigenen API-Anbindung und klaren Regeln für Teilzahlungen und unklare Treffer.
Aktualisiert am
Die Rechnung ist verschickt, der Kunde hat überwiesen und trotzdem steht der Vorgang noch auf „offen“. Im Bankportal lautet der Verwendungszweck „Projekt Website“, in deiner Liste steht „RE-184“. Spätestens wenn zwanzig Rechnungen auf eine Zuordnung warten, wird das Wechseln zwischen Kontoauszug und Rechnungsliste mühsam.
Mit Kontoflux.io kannst du die verfügbaren Bankumsätze in deinen Rechnungsprozess einbinden. Die API hilft bei der Suche nach passenden Zahlungsreferenzen. Deine Anwendung prüft anschließend, welche Zahlung zu welcher Rechnung gehört und welcher Betrag noch offen ist. Für dein Team bleiben die Fälle übrig, die tatsächlich eine Rückfrage brauchen.
Ein Zahlungseingang ist noch kein Haken an der Rechnung
Die fiktive Agentur Nordlicht hat eine Rechnung über 1.200 Euro gestellt. Der Kunde zahlt zunächst 700 Euro und eine Woche später weitere 500 Euro. Beide Überweisungen gehören zum selben Auftrag. Nach dem ersten Eingang ist die Rechnung teilweise bezahlt; erst die zweite Zahlung gleicht sie vollständig aus.
Wer beim ersten Treffer nur das Feld „bezahlt“ setzt, verliert den Restbetrag aus dem Blick. Ein brauchbarer Abgleich speichert deshalb jede einzelne Zuordnung: den Bankumsatz, die Rechnung und den zugewiesenen Teilbetrag. Daraus ergibt sich der offene Betrag.
| Ereignis | Zugeordnet | Noch offen |
|---|---|---|
| Rechnung gestellt | 0 Euro | 1.200 Euro |
| Erste Zahlung | 700 Euro | 500 Euro |
| Zweite Zahlung | 500 Euro zusätzlich | 0 Euro |
Dasselbe Modell hilft in der anderen Richtung: Zahlt ein Kunde drei Rechnungen mit einer einzigen Überweisung, verteilst du den Bankbetrag auf mehrere Rechnungen. Die Summe der Zuordnungen darf den tatsächlich verfügbaren Zahlungseingang nicht überschreiten.
Die API nimmt dir die Suche ab
Die Kontoflux.io-API stellt Konten und Transaktionen für eigene Anwendungen bereit. Für den Rechnungsabgleich gibt es außerdem eine Suche nach Zahlungsreferenzen. Sie liefert passende Transaktionen mit einem Ähnlichkeitswert. In der offiziellen Dokumentation zum Referenzabgleich findest du die Filter und die Bedeutung der Ergebnisse.
Deine Anwendung kann zum Beispiel nach „RE-184“ suchen und die Auswahl auf das erwartete Geschäftskonto und einen passenden Zeitraum begrenzen. Das hilft bei abweichenden Schreibweisen im Verwendungszweck. Ein hoher Trefferwert bestätigt allerdings nur eine textliche Ähnlichkeit. Ob der Umsatz die Rechnung bezahlt, ergibt sich aus den weiteren Prüfungen.
Ein vollständiger Ablauf fragt deshalb: Ist das Geld eingegangen oder abgegangen? Stimmen Währung und Betrag? Ist diese Zahlung bereits einer anderen Rechnung zugeordnet? Passt die Gegenpartei, soweit ihre Daten vorliegen? Gibt es mehrere plausible Treffer, sollte das System sie zur Prüfung vorlegen.
- Offene Rechnung und Zahlungsreferenz auswählen
- Passende Bankumsätze über die API suchen
- Richtung, Währung und verfügbaren Betrag prüfen
- Eindeutige Zuordnung speichern oder Rückfrage anlegen
So könnte der Abgleich in Ninox aussehen
Wenn du Rechnungen bereits in Ninox verwaltest, kannst du die Bankumsätze über die Ninox-Integration in eine eigene Tabelle übertragen. Die Einrichtungsanleitung beschreibt die Auswahl der Tabellen und die Feldzuordnung. Wie der Bankfeed grundsätzlich aufgebaut ist, zeigen wir im Beitrag zu Bankfeeds für Buchhaltung und ERP.
Für unseren Agenturfall würde eine zusätzliche Tabelle „Zahlungszuordnungen“ die Rechnungen mit den Bankumsätzen verbinden. Jede Zeile enthält den zugewiesenen Betrag und den Bearbeitungsstatus. Eine Ansicht zeigt offene Rechnungen, eine weitere nur unklare Zahlungseingänge. Ein Kommentar wie „Kunde hat zwei Rechnungen zusammengefasst“ bleibt direkt am Vorgang.
Diese Zuordnungslogik richtest du in deiner Ninox-Anwendung ein. Für eine automatische Kandidatensuche kann ein eigener Integrationsprozess zusätzlich die Matching-API nutzen. So bleibt klar, welcher Teil Bankdaten überträgt und welcher Teil über den Rechnungsstatus entscheidet. Bei einem anderen ERP übernimmt dessen Adapter dieselben Aufgaben.
Die Ausnahmen verdienen eine gute Liste
Zwei Kunden können am selben Tag denselben Betrag überweisen. Ein Kunde kürzt die Zahlung um Skonto, ein anderer zahlt versehentlich zu viel. Solche Fälle passen schlecht zu einer Regel, die lediglich Beträge vergleicht. Lege fest, welche Abweichungen dein Team prüfen muss und wie es die Entscheidung festhält.
Eine nützliche Prüfliste zeigt die Rechnung, den vorgeschlagenen Bankumsatz, die Differenz und den Grund für die Rückfrage. Ein Klick sollte zu den ursprünglichen Angaben führen. Dann lässt sich ein Fall klären, ohne noch einmal im Bankportal nach der Überweisung zu suchen. Bei einer Rückzahlung bleibt die ursprüngliche Zuordnung nachvollziehbar; die neue Bewegung bekommt einen eigenen Eintrag.
Achte auch auf Wiederholungen: Wenn zwei Läufe denselben Zahlungseingang finden, darf er nur einmal verteilt werden. Speichere dafür die Umsatzkennung mit jeder Zuordnung und prüfe den noch verfügbaren Betrag beim Schreiben. Diese Regel gehört in dein Zielsystem, damit auch parallele Vorgänge konsistent bleiben.
Vor der nächsten Zahlungserinnerung kurz den Datenstand prüfen
Ein fehlender Treffer bedeutet zunächst, dass die Suche keine passende Zahlung gefunden hat. Vielleicht liegt der Umsatz außerhalb des gewählten Zeitraums oder der Bankabruf ist noch nicht aktuell. Zeige deshalb den letzten erfolgreichen Import neben deiner Liste offener Rechnungen. Die API liest den in Kontoflux.io vorhandenen Datenbestand; ihr Aufruf startet keinen neuen Bankabruf.
Probiere den Abgleich mit bekannten Rechnungen aus
Wähle einige bereits geklärte Fälle, darunter eine Teilzahlung. Vergleiche die Ergebnisse mit deinen vorhandenen Zuordnungen. Mit den API-Beispielen für Kontoflux.io kannst du die erste Referenzsuche aufbauen und anschließend deine eigenen Freigaberegeln ergänzen.
