Ein virtuelles Konto ist ein Nebenbuch-Eintrag mit einer Kontonummer. Es hat einen eindeutigen Identifier, oft dargestellt als virtuelle IBAN, hält aber selbst keine Gelder: Jede Transaktion settelt auf dem verknüpften physischen Masterkonto, und die virtuelle Schicht verzeichnet, wem das Geld gehört. Dieses eine Designmerkmal erklärt sowohl, warum Virtual Account Management funktioniert, als auch, wo man damit in Schwierigkeiten gerät.
Das Problem, das es löst, ist real. Multinationale Gruppen sammeln Hunderte physischer Bankkonten an, jedes mit Zeichnungsberechtigten, Gebühren, KYC-Refresh-Zyklen und einem Saldo, der die Gruppenliquidität fragmentiert. Gleichzeitig treffen Forderungseingänge mit Referenzen ein, die zu keiner Rechnung passen, und jemand im Shared Service Center verbringt den Tag damit zu raten, welcher Tochtergesellschaft eine Gutschrift gehört. Virtuelle Konten greifen beides zugleich an: Cash konzentriert sich auf wenige Masterkonten, während jeder Kunde, jede Entität, jedes Projekt oder jede Abteilung einen eigenen Identifier behält, sodass die Zuordnung die Zentralisierung überlebt.
Der Fehler ist, VAM als Produkt zu behandeln, das man einschaltet. Es ist ein Datenmodell, auf das man sich festlegt, und es leistet exakt so viel wie die Entitätsstammdaten, die ERP-Integration und die Governance darunter.
Wo virtuelle Konten physische schlagen
Der Fall ist am stärksten, wenn das Ziel zentralisierte Liquidität mit granularer Zuordnung ist, und er zeigt sich an vier Stellen.
- Kontenrationalisierung. Ein Masterkonto je Währung und Region, plus so viele logische Unterkonten, wie das Geschäft braucht, ersetzt einen Wildwuchs physischer Konten. Ein neues virtuelles Konto zu eröffnen ist Konfiguration, kein Bank-Onboarding-Projekt, weshalb das Modell für Plattform- und Multi-Entity-Geschäfte skaliert, die viele Zahlungsidentifier benötigen.
- Reconciliation. Wenn jeder Kunde auf seine eigene virtuelle IBAN zahlt, sagt der Identifier selbst, wer gezahlt hat, und die Cash Application wird deterministisch. Das Matching wandert vom Parsen unzuverlässiger Verwendungszwecktexte zu einem Lookup. Eine 2025er Studie, die ein VAM-Anbieter zitiert, behauptet eine Reduktion des Abstimmungsaufwands um 70 % und einen Payment-to-Reconciliation-Zyklus, der von 4,2 Tagen auf unter 15 Minuten fällt; das sollte man als anbieterzitierte Benchmarks lesen, nicht als Marktdurchschnitt, aber die Richtung deckt sich mit dem, was wir bei sauberem Mapping sehen.
- Liquiditätszentralisierung ohne Detailverlust. Cash poolt physisch im Masterkonto, Treasury steuert also einen Saldo je Währung, während die Hierarchie die Positionen auf Entitätsebene für Buchhaltung, Zinsallokation und Intercompany-Tracking bewahrt. Nichts muss geswept werden, weil nichts je weg war.
- Strukturelle Flexibilität. Hierarchien können rechtliche Einheiten, Geschäftsbereiche oder Kundenbeziehungen abbilden und lassen sich umbauen, ohne ein Bankmandat anzufassen.
Die Banken haben sich beim Angebot angeglichen: Barclays, HSBC, Deutsche Bank, Citi, J.P. Morgan und Bank of America verkaufen VAM innerhalb ihrer Corporate-Treasury-Suiten, wobei Bank of Americas VAM 2.0 mit Strukturen in mehr als 30 Währungen und Self-Service-Einrichtung wirbt. Daneben konkurrieren API-first-Anbieter wie Airwallex, Currencycloud, Wise Platform und Finzly über Integrationsgeschwindigkeit und Multi-Rail-Abdeckung. Die Trennlinie ist wichtig für die Auswahl: Bankeigenes VAM gewinnt tendenziell bei Pooling-Tiefe und jurisdiktionellem Vertrauen, Plattform-VAM bei Developer Experience und Zeit bis zur ersten Collection.
POBO, COBO und die In-House Bank
Ihren Wert zeigen virtuelle Konten am sichtbarsten in On-Behalf-of-Strukturen. Unter COBO, Collections on behalf of, empfängt eine zentrale Entität alle Gruppeneingänge auf Masterkonten, und die virtuelle Schicht ordnet jede Gutschrift der richtigen Tochtergesellschaft und Verbindlichkeit zu. Unter POBO, Payments on behalf of, zahlt Treasury Lieferanten zentral, während die virtuelle Struktur festhält, welcher Entität die Zahlung gehört, sodass Intercompany-Buchhaltung und Kostenzuordnung intakt bleiben. In beiden Fällen ist der Punkt, dass rechtliche und operative Zuordnung überleben, während das Cash selbst zentralisiert bleibt.
Treibt man diese Logik weiter, landet man bei der In-House Bank: Tochtergesellschaften transagieren mit dem zentralen Treasury, als wäre es ihre Bank, halten interne Konten, erhalten interne Finanzierung und settlen Intercompany-Positionen auf einem internen Ledger statt über externe Zahlungen. VAM liefert das operative Gerüst, eine strukturierte Identifier-Hierarchie, die die Gruppe abbildet, ohne dass das Unternehmen je Entität ein externes Konto eröffnen und verwalten muss.
Zwei Disziplinen halten das ehrlich. Erstens: Die Intercompany-Positionen, die jeder On-Behalf-of-Fluss erzeugt, sind reale Salden mit steuerlichen und Verrechnungspreis-Konsequenzen, und sie brauchen Settlement-Rhythmen und Zinskonditionen, die einer Prüfung standhalten würden. Zweitens: Das System of Record für diese Positionen sollte das eigene Ledger sein, gegen das die virtuelle Hierarchie der Bank abgestimmt wird, nicht umgekehrt als Ersatz dafür.
Wo es schiefgeht
Die Fehlermodi sind vorhersehbar, und fast alle sind Daten und Governance, nicht Banking.
- Schmutzige Entitätsstammdaten. Die virtuelle Hierarchie muss zu ERP-Entitäten, AR/AP-Strukturen und Intercompany-Beziehungen passen. Inkonsistente Namens- und Mapping-Regeln führen dazu, dass die VAM-Schicht neue Abstimmungs-Exceptions erzeugt, statt alte zu beseitigen, also das Gegenteil des Business Case.
- Abdeckungslücken. Virtuelle IBAN-Ausgabe, lokale Kontoformate und Rail-Unterstützung variieren je Bank, Land und Währung. Der Rollout-Plan muss von einer Coverage-Karte ausgehen, denn die Länder außerhalb definieren den verbleibenden Bestand physischer Konten.
- Integrationsschulden. VAM zahlt sich aus, wenn es über APIs oder Dateien mit ERP, TMS und Buchhaltungssystemen verdrahtet ist. Ohne das hat die Organisation manuelle Kontoadministration gegen manuelle Integrationswartung getauscht, und die laufende Ersparnis materialisiert sich nie.
- Regeln ohne Owner. Jemand muss Kontoanlage und -schließung, Referenzkonventionen, Sweep-Logik und Exception Handling verantworten. In POBO/COBO- und In-House-Bank-Settings haben Entscheidungen zu interner Verrechnung und Settlement-Timing reale buchhalterische Konsequenzen, und “das macht die Bank” ist keine Antwort.
- Rechtliche Fehldeutung. Teams, die ein virtuelles Konto wie ein Einlagenkonto behandeln, überschätzen die Separierung und beurteilen das Gegenparteirisiko falsch. Das gesamte Kreditrisiko liegt auf dem Masterkonto und dessen Inhaber.
Die operative Realität
Planen Sie den Aufbau um drei unglamouröse Arbeitsstränge. Zuerst die Daten: saubere Entitätsstammdaten, eine Referenzkonvention, die jedes System einhält, und ein vereinbartes Mapping von virtuellen Konten auf ERP-Objekte, erledigt bevor die erste Struktur live geht, denn Konventionen nachträglich über eine lebende Hierarchie zu ziehen ist eine Qual. Dann die Integration: Kontoauszüge und Intraday-Reporting in Virtuelle-Konten-Granularität, die in TMS und ERP fließen, mit einer Cash Application, die den virtuellen Identifier direkt konsumiert, denn dieser Lookup ist der gesamte Reconciliation-Nutzen. Dann die Governance: ein dokumentierter Owner für die Hierarchie, ein Change-Prozess für deren Umbau und ein Monitoring, das die virtuellen Salden der Bank täglich gegen das eigene Ledger abstimmt.
Das Konzentrationsrisiko verdient eine explizite Entscheidung statt einer Entdeckung. Cash auf wenige Masterkonten zu zentralisieren konzentriert das Exposure auf weniger Banken; das mag genau das Gewollte sein, sollte aber eine limitgesteuerte Wahl sein. Und führen Sie einen Audit Trail der Zuordnung: Wenn eine Aufsichtsbehörde, ein Prüfer oder ein Insolvenzverwalter fragt, wessen Geld ein Saldo an einem bestimmten Datum war, ist die Historie des virtuellen Nebenbuchs die Antwort. Also versionieren und aufbewahren wie den Buchhaltungsbeleg, der sie ist.
So umgesetzt ist VAM eine der seltenen Treasury-Veränderungen, die sowohl Kosten als auch Komplexität senken. Als Produktkauf ohne die Datenarbeit umgesetzt, ist es eine zusätzliche Schicht, die gegen nichts abstimmt.
Häufige Fragen
Sind Gelder auf einem virtuellen Konto separiert, wenn das Unternehmen oder die Bank ausfällt?
Nein. Ein virtuelles Konto ist eine Zuordnungsschicht, und das Geld liegt auf dem Masterkonto; Kreditexposure, insolvenzrechtliche Behandlung und Einlagensicherung folgen daher dem physischen Konto und dessen rechtlichem Inhaber. Wer echte Separierung braucht, etwa für Kundengeldregeln oder Ring-Fencing, braucht reale Konten mit der passenden rechtlichen Struktur. Das falsch zu lesen ist der gefährlichste VAM-Fehler, weil er erst im Ausfallszenario sichtbar wird.
Wie viele physische Konten behalten Unternehmen nach der Einführung von VAM tatsächlich?
Mehr, als das Sales Deck suggeriert. Physische Konten bleiben nötig, wo lokales Recht sie für Steuern, Payroll oder regulierte Tätigkeiten verlangt, wo eine Währung oder ein Land keine virtuelle IBAN-Abdeckung hat, und wo ein Geschäftsbereich tatsächlich Trennung auf Bankebene braucht. Ein realistisches Ergebnis ist, Hunderte Konten auf wenige Master je Währung und Region zu verdichten, plus einen Restbestand verpflichtender lokaler Konten, und auch dieser Rest braucht Governance.
Sollte das Ledger der In-House Bank im VAM der Bank liegen oder in unseren eigenen Systemen?
Die virtuelle Hierarchie der Bank ist die Routing- und Zuordnungsschicht; das System of Record für Intercompany-Positionen, Zinsen und Settlement sollte das eigene sein, im TMS oder ERP. Banken können Plattformen wechseln, und später kommt womöglich ein zweiter VAM-Anbieter hinzu; das Intercompany-Ledger am Produkt einer Bank zu verankern erzeugt vermeidbaren Lock-in. Beide täglich gegeneinander abstimmen und Differenzen als Exceptions behandeln.