A virtual account is a sub-ledger entry wearing an account number. It has a unique identifier, often presented as a virtual IBAN, but it holds no funds of its own: every transaction settles on the linked physical master account, and the virtual layer records who the money belongs to. That one design fact explains both why virtual account management works and where people get into trouble with it.
The problem it solves is real. Multinational groups accumulate hundreds of physical bank accounts, each with signatories, fees, KYC refresh cycles, and a balance that fragments group liquidity. Meanwhile receivables arrive with references that do not match invoices, and someone in a shared service centre spends their day guessing which subsidiary a credit belongs to. Virtual accounts attack both at once: cash concentrates in a small number of master accounts while every customer, entity, project, or department keeps its own identifier, so attribution survives centralisation.
The mistake is treating VAM as a product you switch on. It is a data model you commit to, and it performs exactly as well as the entity master data, ERP integration, and governance underneath it.
Where virtual accounts beat physical ones
The case is strongest when the goal is centralised liquidity with granular attribution, and it shows up in four places.
- Account rationalisation. One master account per currency and region, plus as many logical sub-accounts as the business needs, replaces a sprawl of physical accounts. Opening a new virtual account is configuration, not a bank onboarding project, which is why the model scales for platform and multi-entity businesses that need many payment identifiers.
- Reconciliation. When each customer pays into their own virtual IBAN, the identifier itself tells you who paid, and cash application becomes deterministic. Matching moves from parsing unreliable remittance text to a lookup. One 2025 study cited by a VAM vendor claims a 70% reduction in reconciliation labour and a payment-to-reconciliation cycle falling from 4.2 days to under 15 minutes; treat those as vendor-cited benchmarks rather than market averages, but the direction matches what we see when the mapping is clean.
- Liquidity centralisation without losing the detail. Cash pools physically in the master account, so treasury manages one balance per currency while the hierarchy preserves entity-level positions for accounting, interest allocation, and intercompany tracking. Nothing needs to be swept because nothing ever left.
- Structural flexibility. Hierarchies can mirror legal entities, business units, or client relationships, and can be reshaped without touching a bank mandate.
Banks have converged on the offering: Barclays, HSBC, Deutsche Bank, Citi, J.P. Morgan, and Bank of America all sell VAM within their corporate treasury suites, with Bank of America’s VAM 2.0 advertising structures in more than 30 currencies and self-service setup. Alongside them, API-first providers such as Airwallex, Currencycloud, Wise Platform, and Finzly compete on integration speed and multi-rail coverage. The split matters for selection: bank-native VAM tends to win on pooling depth and jurisdictional trust, platform VAM on developer experience and time to first collection.
POBO, COBO, and the in-house bank
Virtual accounts earn their keep most visibly in on-behalf-of structures. Under COBO, collections on behalf of, a central entity receives all group receipts into master accounts, and the virtual layer allocates each credit to the right subsidiary and obligation. Under POBO, payments on behalf of, treasury pays suppliers centrally while the virtual structure preserves which entity the payment belongs to, keeping intercompany accounting and cost attribution intact. In both cases the point is that legal and operational attribution survives while the cash itself stays centralised.
Push that logic further and you arrive at the in-house bank: subsidiaries transact with central treasury as if it were their bank, holding internal accounts, receiving internal funding, and settling intercompany positions on an internal ledger instead of through external payments. VAM supplies the operational scaffolding, a structured hierarchy of identifiers that mirrors the group, without the company having to open and govern an external account per entity.
Two disciplines keep this honest. First, the intercompany positions created by every on-behalf-of flow are real balances with tax and transfer-pricing consequences, and they need settlement rhythms and interest terms that would survive review. Second, the system of record for those positions should be your own ledger, with the bank’s virtual hierarchy reconciled against it, not substituted for it.
Where it goes wrong
The failure modes are predictable, and almost all of them are data and governance rather than banking.
- Dirty entity master data. The virtual hierarchy must align with ERP entities, AR/AP structures, and intercompany relationships. Inconsistent naming and mapping rules mean the VAM layer generates new reconciliation exceptions instead of removing old ones, which is the opposite of the business case.
- Coverage gaps. Virtual IBAN issuance, local account formats, and rail support vary by bank, country, and currency. The rollout plan has to start from a coverage map, because the countries that fall outside it define your residual physical-account estate.
- Integration debt. VAM pays off when it is wired into ERP, TMS, and accounting engines through APIs or files. Without that, the organisation has swapped manual account administration for manual integration maintenance, and the run-rate saving never materialises.
- Unowned rules. Somebody has to own account creation and closure, reference conventions, sweep logic, and exception handling. In POBO/COBO and in-house bank settings, internal charging and settlement timing decisions have real accounting consequences, and “the bank handles it” is not an answer.
- Legal misreading. Teams that treat a virtual account as a deposit account overstate segregation and misjudge counterparty exposure. All the credit risk sits on the master account and its owner.
The operational reality
Plan the build around three unglamorous workstreams. Data first: clean entity master data, a reference convention that every system honours, and an agreed mapping from virtual accounts to ERP objects, done before the first structure goes live, because retrofitting conventions across a live hierarchy is miserable. Integration second: statements and intraday reporting at virtual-account granularity flowing into the TMS and ERP, with cash application consuming the virtual identifier directly, since that lookup is the whole reconciliation benefit. Governance third: a documented owner for the hierarchy, a change process for restructuring it, and monitoring that reconciles the bank’s virtual balances against your own ledger daily.
Concentration risk deserves an explicit decision rather than a discovery. Centralising cash into a few master accounts concentrates exposure on fewer banks; that may be exactly what you want, but it should be a limit-managed choice. And keep an audit trail of attribution: when a regulator, auditor, or insolvency practitioner asks whose money a balance was on a given date, the virtual sub-ledger history is the answer, so version it and retain it like the accounting record it is.
Done this way, VAM is one of the rare treasury changes that reduces both cost and complexity. Done as a product purchase without the data work, it is an extra layer that reconciles against nothing.
FAQ
Are funds in a virtual account segregated if the company or the bank fails?
No. A virtual account is an attribution layer, and the money sits in the master account, so credit exposure, insolvency treatment, and deposit protection all follow the physical account and its legal owner. If you need genuine segregation, for client money rules or ring-fencing, you need real accounts with the right legal structure. Misreading this is the most dangerous VAM mistake because it surfaces only in a failure scenario.
How many physical accounts do companies actually keep after adopting VAM?
More than the sales deck implies. You still need physical accounts where local law requires them for tax, payroll, or regulated activity, where a currency or country lacks virtual IBAN coverage, and where a business genuinely needs bank-level separation. A realistic outcome is collapsing hundreds of accounts into a few masters per currency and region plus a residual tail of mandatory locals, and the tail needs governance too.
Should the in-house bank ledger live in the bank's VAM or in our own systems?
The bank's virtual hierarchy is the routing and attribution layer; the system of record for intercompany positions, interest, and settlement should be your own, in the TMS or ERP. Banks can change platforms, and you may add a second VAM provider later, so anchoring the intercompany ledger to one bank's product creates avoidable lock-in. Reconcile the two daily and treat differences as exceptions.