Wir nutzen Google Analytics für Besucherstatistiken. Analyse-Cookies werden nur gesetzt, wenn Sie zustimmen. Ohne Einwilligung werden die Statistiken anhand cookieloser Signale geschätzt. Cookie-Richtlinie.
vIBAN · Zahlungsabgleich
Wenn jeder Zahler auf seine eigene IBAN zahlt, kann eine eingehende Zahlung nur eines bedeuten. Das Zuordnungsproblem wird nicht gelöst – es hört auf zu existieren.
Im Hintergrund gibt es ein Hauptkonto. Nach außen erhält jeder Zahler, Mieter oder Abonnent eine eigene virtuelle IBAN. Das Geld landet in beiden Fällen auf dem Hauptkonto — aber bereits beschriftet: wer es gesendet hat und wofür.
Die Sicht des Zahlers — eine IBAN, die ihm allein gehört, kopieren und teilen.
Die Ausstellung läuft in großen Mengen, nicht Formular für Formular — ein Marktplatz, der tausend Verkäufer onboardet, erzeugt tausend IBANs in einem Vorgang. Zweck-Tags halten die Zahlungsflüsse getrennt: Miete hier, Abos dort, Marktplatz-Auszahlungen in einer eigenen Lane — so erhält jede Einheit einer Plattform ihre eigene, abgleichbare Kontonummer.
Massenausstellung — 2.400 Zeilen validiert, IBANs reserviert, eine Aktion zum Ausstellen.
Integration
Erzeugen Sie eine vIBAN pro Zahler — eine per API oder 2.400 per CSV mit Prüfschritt.
Jeder Zahler überweist an seine eigene IBAN – kein Verwendungszweck, den man falsch tippen könnte.
Gutschriften ordnen sich konstruktionsbedingt selbst zu – in der Demo 99,6 % automatisch abgestimmt.
Der Rest landet in einer gezählten Ausnahmewarteschlange, inklusive Historie.
Kontoauszüge pro vIBAN als CSV und PDF, monatlich am 1. per E-Mail.
Features
Ein Bildschirm für das ganze Programm: 12.480 aktive vIBANs, heute 2,4 Mio. € geroutet, 8.912 Gutschriften automatisch abgestimmt. Jede Zeile zeigt die IBAN, wem sie gehört, ihr Zweck-Tag und die heutigen Zahlungseingänge. Suche nach IBAN, Kunde oder Referenz; das Buch als CSV exportieren.
Kunden sehen ihre eigenen Kontodaten: die dedizierte IBAN mit Kopier-Button, den BIC für Überweisungen von außerhalb von SEPA, Name und Adresse der Bank und einen Teilen-Button für alle, die sie bezahlen. Jede Überweisung auf diese IBAN landet bereits zugeordnet in ihrem Saldo – der Zahler tippt nie eine Referenz.
Eine CSV mit 2.400 Zahlern wird hochgeladen, validiert – 2.400 gültig, 0 Fehler – und zeigt vorab die genaue IBAN, die jede Zeile erhält; sie wird beim Upload aus dem Bereich reserviert und bei der Ausgabe zugewiesen. Bereich, Zweck-Tag und Referenzpräfix konfigurieren, dann den gesamten Batch mit einer Aktion ausgeben. Derselbe Vorgang läuft über die API.
Der angezeigte Zeitraum umfasst 412.380,44 € aus 8.912 Gutschriften, zu 99,6 % automatisch abgestimmt – die 34 manuellen Fälle und 12 Rückläufer werden gezählt statt versteckt. Jede vIBAN exportiert ihren eigenen Auszug als CSV oder PDF, der gesamte Zeitraum lässt sich mit einer Aktion exportieren, und Monatsauszüge gehen am 1. automatisch per E-Mail an das Finanzpostfach.
Jede Gutschrift, Rückgabe, Ausgabe und Pause ist ein Event, und jedes Event zeigt seine Zustellung: Statuscode, Latenz und Retry-Status je Versuch. Zustellungen werden mit HMAC-SHA256 signiert und über 24 Stunden mit exponentiellem Backoff 6-mal wiederholt – und eine Zustellung, die alle Versuche erschöpft hat, bekommt einen Button für den manuellen Retry statt eines Achselzuckens.
In der Operator-Konsole sind die Empfangskonten hinter dem Programm Daten, kein implizites Wissen: ein aktives Konto je Währung, und wird eines stillgelegt, rückt das nächste automatisch nach. Jede Änderung verlangt eine schriftliche Begründung und landet im Audit-Log.
Jeder Zahler erhält eine eigene IBAN, sodass jede eingehende Zahlung ihren Absender nennt, bevor jemand hinsieht. Es gibt kein Referenzfeld, in dem man sich vertippen kann, und keine Zuordnungswarteschlange, die abgearbeitet werden muss. Identifikation ist eine Eigenschaft der Kontonummer, kein Prozess.
Jede vIBAN trägt ein Tag: rent-collection, subscriptions, marketplace-payouts, payroll. Zahlungsströme bleiben auf Kontoebene getrennt, sodass Reporting nach Zweck ein Filter ist, kein Projekt.
Wenn jeder Zahler auf seine eigene IBAN einzahlt, kann eine Gutschrift nur eines bedeuten. Im Demo-Zeitraum stimmen sich 99,6 % von 8.912 Gutschriften selbst ab – und die wenigen, die es nicht tun, landen in einer manuellen Warteschlange statt in einem Rätsel.
Hinter jeder vIBAN steht ein reales Konto. Gelder werden automatisch konzentriert – keine Unterkonto-Salden, die einzusammeln sind, keine Fragmentierung, die verwaltet werden muss. Die Oberfläche besteht aus Tausenden Adressen; das Hauptbuch ist eines.
vIBANs werden aus dedizierten Bereichen ausgegeben – das Demo-Programm läuft unter RO49 PRCT, die Zahl freier IBANs je Bereich wird bei der Ausgabe angezeigt. Bereiche halten Programme, Marken oder Gesellschaften sauber getrennt, während alles weiter ins Hauptkonto fließt.
Jede vIBAN sammelt ihre eigene Zahlungshistorie, sodass die Akte eines Zahlers per Definition vollständig ist. Ein Streitfall oder ein Audit beginnt bei einer gefilterten Liste, nicht bei einer Untersuchung.
Das Onboarding von Verkäufern und Mietern kann eine vIBAN als Schritt im Ablauf erzeugen: Konto anlegen, IBAN übergeben, Einzug starten. Die Kundenansicht wird als Whitelabel ausgeliefert – die Demo läuft als „Powered by Protocore“; Ihre läuft unter Ihrer Marke.
Manche Zahlungen kommen zurück – Konto geschlossen, Daten falsch. SEPA-Rückläufer tragen ihren Reason Code in ein payment.returned-Event und haben auf der Auszugsseite eine eigene Zählung – Daten mit Ursache, keine Rätsel. Der Sonderfall bekommt eine Zeile, keinen Support-Thread.
Eine vIBAN lässt sich mit einer Aktion pausieren, und der Event-Stream hält fest, wer sie von wo pausiert hat. „Pausiert“ erscheint überall als Status, wo die IBAN auftaucht – im Buch, in den Auszügen, im Stream.
Ein konfigurierter Batch wird als Entwurf gespeichert: Quelle validiert, Bereich gewählt, noch nichts ausgegeben. Der Ablauf lautet Quelle, Konfiguration, Prüfung – der unumkehrbare Klick ist bewusst der letzte.
Die Ausgabe läuft gegen ein monatliches Kontingent mit sichtbarem Zähler, und ein Batch nennt vor dem Start, was er hinzufügt – 1.204 von 5.000 genutzt, mit diesem Batch sind es 3.604. Kapazität ist Arithmetik, keine Fehlermeldung.
Jeder Batch versieht seine Gutschriften mit einem Referenzpräfix – in der Demo ARC-PAYOUT- –, sodass nachgelagerte Systeme ihre eigenen Zahlungsströme auf den ersten Blick erkennen.
Jede Zahlerzeile trägt eine externe Referenz aus Ihrem System – in der Demo EXT-00311 – und bleibt der vIBAN zugeordnet. Abfragen laufen auch über Ihre Kennungen, nicht nur über unsere.
Alles, was die Konsole kann, kann die API – ausgeben, pausieren, abfragen, exportieren. CSV-Upload und API-Aufruf steuern denselben Vorgang; die Konsole ist ein Client, kein Sonderweg.
Senden Sie ein Testereignis direkt aus der Konsole an jeden Endpoint. Die Integration bewährt sich an synthetischen Zustellungen, noch bevor die erste echte Gutschrift eintrifft.
Endpoints haben eigene Signing Secrets und eigene Subscriptions und lassen sich pausieren, ohne gelöscht zu werden – in der Demo liegt ein pausierter Staging-Endpoint direkt neben dem aktiven Produktiv-Endpoint.
CSV für Maschinen, PDF für Menschen – pro vIBAN oder für den gesamten Zeitraum. Der Export ist zum Importieren gedacht, nicht zum Abtippen.
Monatliche Kontoauszüge gehen am 1. automatisch an die Finanzadresse. Der Routinebericht ist ein Abonnement, keine wiederkehrende Aufgabe auf der Liste von jemandem.
Ereignisse lassen sich nach Typ, vIBAN oder Referenz filtern; das Kontobuch in der Konsole durchsucht IBAN, Kunde oder Referenz. Eine einzelne Zahlung unter Tausenden zu finden, ist eine Abfrage mit drei Einstiegspunkten.
Änderungen von Operatoren am Programm – Konten, Pausierungen, Stilllegungen – erfordern eine Begründung und landen im Audit-Log. Die Historie des Programms erklärt sich schriftlich selbst.
Screens
Echte Produktoberfläche, gezeigt mit Demodaten.
FAQ
Es sind adressierbare IBANs aus eigenen Nummernkreisen, die auf ein Hauptkonto laufen. Eine Zahlung an eine vIBAN kommt an wie jede SEPA-Gutschrift; die Gelder werden automatisch auf dem Hauptkonto gebündelt — ohne Sweeping-Jobs.
Die Rückbuchung trägt ihren Grundcode in ein payment.returned-Event und erscheint separat in der Auszugsstatistik. Rückbuchungen sind Daten mit hinterlegter Ursache, keine Rätsel, denen man nachjagen muss.
Sie brauchen einen Ausnahmeprozess, kein Matching-Team. Eine Zahler-IBAN pro Zahler macht Gutschriften selbstidentifizierend — in der Demo 99,6 % automatisch abgeglichen —, und der Rest landet mit vollständiger Zahlerhistorie in der Prüfwarteschlange.
Stellen Sie in großen Mengen aus — eine CSV mit 2.400 Zahlern wird validiert, in der Vorschau geprüft und in einer Aktion ausgestellt — und versehen Sie jede vIBAN mit einem Zweck-Tag. Jeder Verkäufer, Mieter oder jede Einheit erhält eine eigene, abgleichbare Kontonummer; Reporting nach Zweck wird zum Filter statt zum Projekt.
Bewerten
Wir spielen den kompletten Ablauf mit Ihnen durch — ausstellen, teilen, zuordnen, Ausnahmen klären, berichten — auf denselben Demodaten, einschließlich der Massenausstellung für 2.400 Zahler.
Ein Testprogramm mit Hauptkonto und aktivierter Ausstellung, damit Ihr Team vIBANs erzeugen, Test-Gutschriften senden und deren Selbstzuordnung beobachten kann.
Die Issuing-API, Webhooks für Zahlungen und Lebenszyklus sowie die Integrationsdokumentation — genug, um den Zahlungsabgleich in Ihr eigenes Backoffice einzubinden.
Testen Sie unter der Marke Protocore oder stellen Sie unter Ihrer eigenen aus — das Hauptkonto bleibt in beiden Fällen die zentrale Quelle der Wahrheit.
Weiterführende Inhalte
Einzeln oder als Whitelabel verfügbar — Ausstellung unter Ihrer Marke.
Pay-by-Transfer-Bestellungen von Gateway tragen vIBAN-Referenzen, PoS-Auszahlungen laufen über dieselben IBAN-Schienen, und Center bearbeitet die Ausnahmen, die das Matching von vIBAN übrig lässt.
Alles oben Gezeigte läuft in Produktivdemos, die wir Ihnen gern vorführen – standalone, als Whitelabel oder als eine Plattform. Sagen Sie uns, was Sie bauen, und wir zeigen Ihnen den kürzesten Weg dorthin.
