What are virtual accounts?

Virtual accounts (often virtual IBANs) are sub-accounts layered on top of a single real bank account. Each virtual account has its own account number or IBAN used for identification and routing, but there is no separate pot of money — all the actual cash sits in the one underlying physical account. They let a company give many customers, entities or purposes their own 'account number' to pay into or from, while collapsing the number of real bank accounts it has to open, fund and manage.

What is the difference between a virtual account and a real bank account?

A real bank account holds cash and exists as a distinct account at the bank with its own balance. A virtual account is an identifier layered over a real account — it has its own number for routing and reconciliation, but it doesn't hold cash separately; the money lives in the underlying physical account. So a company can have hundreds of virtual accounts backed by a single real one, getting the identification benefits of many accounts without the cost and administration of opening and maintaining them all.

What are virtual accounts used for?

The most common use is receivables reconciliation: give each customer a unique virtual IBAN to pay into, and incoming payments self-identify by which virtual account they hit, so they match automatically instead of being reconciled by hand. Virtual accounts are also used to replace large numbers of physical accounts (each entity or purpose gets a virtual account instead of a real one), and to support on-behalf-of structures and in-house banking, where virtual accounts represent internal participants over a central real account.

What is virtual account management (VAM)?

Virtual account management is the discipline — and the bank product category — of designing and operating virtual account structures: deciding which real accounts carry which virtual accounts, how the hierarchy is levelled, how virtual balances are tracked as a subledger over the real balance, and how the structure flows into statements and reconciliation. Banks sell VAM as a product; treasury still owns the design, because the bank provides the mechanism, not the structure.

What are the main types of virtual account structures?

Three patterns cover most real implementations: per-payer collection structures (a unique virtual IBAN per customer, for automatic receivables identification), segregation structures (a virtual account per entity, business line or purpose over one real account, replacing physical accounts), and in-house-bank structures (virtual accounts representing internal participants over a central real account, supporting on-behalf-of payments and collections). Most real designs combine two of the three.

What is a multi-level virtual account hierarchy?

A structure where virtual accounts are nested: a real account at the top, a virtual account per entity beneath it, and further virtual accounts per purpose or customer beneath each entity. Banks differ in how many levels they support and how balances roll up. The working rule is to keep the hierarchy as shallow as the reporting actually requires — every extra level adds mapping, statement volume and explanation, and deep trees are the most common form of VAM over-engineering.

How do virtual accounts appear in bank statements and reconciliation?

The cash movement happens on the real account, and the bank reports activity with the virtual account as the identifying reference — depending on the bank, as statements or notifications per virtual account, or as one statement on the real account carrying virtual account references per transaction. That reference is what your reconciliation keys on, so confirming exactly how each bank reports virtual account activity (and testing it with real files) belongs in the design phase, not after go-live.

Virtual Accounts and VAM: Structures and Design

Virtual accounts — often virtual IBANs — are sub-accounts layered on top of a single real bank account: each has its own account number for identification, but all the actual cash is held in the one underlying physical account. They let a company hand out many "account numbers" — one per customer, entity or purpose — while collapsing the number of real accounts it has to open, fund and manage. The payoff is two-fold: incoming payments largely reconcile themselves, because each payer self-identifies by the virtual account they use, and physical account sprawl shrinks.

That's the easy half. Virtual account management (VAM) is the hard half: which real accounts carry the virtual ones, how deep the hierarchy goes, how virtual balances behave as a subledger, and how the whole thing lands in your statements and reconciliation. That design work is what banks and vendors sell as "VAM" — and this post walks through both halves, concept first.

How virtual accounts work

The mental model that unlocks virtual accounts: many account numbers, one pot of cash. A virtual account looks like an account — it has an IBAN, you can route payments to it — but it doesn't hold money separately. It's an identifier over a real account, where the cash actually sits. One physical account can carry hundreds or thousands of virtual accounts beneath it.

The bank maintains a single real account with an actual balance, and a set of virtual account numbers mapped to it. A payment made to a virtual IBAN lands in the underlying real account, tagged with which virtual account it targeted. The company sees both: the real cash position, and which virtual account each flow belongs to. Nothing is physically segregated — the segregation is informational, which is exactly what makes it cheap and flexible.

VAM the product vs VAM the design

Banks offer VAM as a product: the ability to issue virtual account numbers or virtual IBANs over a real account, track per-virtual-account positions, and report activity by virtual account. What the product does not include is the structure — which entities, purposes and customers get virtual accounts, and how they're arranged. That is treasury's design decision, and it's where implementations succeed or quietly bloat. The bank provides the mechanism; you provide the model.

The three structures that cover most cases

Per-payer collection structures. A unique virtual IBAN per customer, so every incoming payment self-identifies by the account it hits. This is the receivables-reconciliation pattern, and for many companies it is the entire business case on its own.
Segregation structures. A virtual account per entity, business line, currency-purpose or project over one real account — the identification benefits of many accounts without opening them. This is account rationalization done structurally: you don't close the sprawl, you stop creating it.
In-house-bank structures. Virtual accounts representing internal participants over a central real account, so group entities hold positions with the in-house bank rather than at external banks — the plumbing beneath payments- and collections-on-behalf-of.

Most real designs combine two of these — for example, entity-level segregation with per-customer collection accounts nested beneath one entity.

The classic reconciliation nightmare is a bank credit with no usable reference — who paid this? A unique virtual IBAN per customer answers that automatically: the account it landed in is the identity of the payer.

The collection pattern is usually the single biggest driver: it turns cash application — matching incoming payments to the right customer and invoice — from a large manual effort into a near-automatic one. The segregation pattern pays off differently: fewer physical accounts means lower fees, simpler global cash visibility, less cash stranded in local accounts and a smaller control surface. And in a centralized model, a virtual structure over a handful of real accounts can carry the whole group's collection and payment identities — concentrating the actual cash while preserving the identities the business needs. Virtual accounts are an enabler of centralization, not a rival to pooling or in-house banking.

The subledger model

The shift that makes VAM design clear: virtual balances are a subledger, not balances. The real account has the only actual balance; each virtual account's "balance" is the running sum of transactions tagged to it — informational, maintained by the bank, always reconcilable back to the one real number. Design questions become subledger questions: can a virtual position go negative, how are balances rolled up the hierarchy, and does the arrangement between your entities constitute intercompany lending? That last one is the same position-tracking discipline as cash concentration — sweeping creates intercompany loans physically, virtual structures create the equivalent positions informationally, and both need owners, limits and documentation.

Designing the hierarchy

Every level in a virtual account hierarchy has to earn its place in a report someone actually reads. If a level exists only because the bank supports it, it's mapping work with no customer.

Multi-level hierarchies — real account at the top, entities beneath, purposes or customers beneath entities — are where VAM designs go to over-engineer. Banks differ in how many levels they support and how balances roll up, so a portable design stays shallow: two levels usually cover the genuine requirements. Deep trees multiply statement volume, mapping tables and month-end explanations, and the unwind is painful because account numbers, once given to payers, are sticky.

Getting the data back out

The structure is only as good as its reporting. Cash moves on the real account; the virtual account rides along as the identifying reference. How that reference reaches you differs by bank — per-virtual-account statements, or one real-account statement with per-transaction virtual references, commonly in camt.053 statements and camt.054 notifications. Two design-phase checks save the project: confirm exactly how each bank reports virtual activity (this varies more than the sales deck admits), and test reconciliation with real files before go-live — a virtual structure that reconciles badly is worse than the physical accounts it replaced, because now the mismatch is invisible.

When not to use VAM

Where regulation wants a real account. Some jurisdictions and some purposes (tax, payroll, local statutory requirements) expect a resident physical account; a virtual IBAN is not always an accepted substitute. Verify per country before designing it away.
Where the bank's VAM is thin. Capability varies significantly by bank and country; a structure designed around one bank's rich VAM offering may not port to the next bank.
Where the problem is small. A company with a dozen accounts and clean references doesn't need a virtual hierarchy — it needs its references enforced.

Virtual account design mistakes

Hierarchy sprawl — levels nobody reports on, kept because the bank supports them.
Reconciliation designed last — the structure is agreed with the bank before anyone checks how it lands in statement files.
Intercompany positions untracked — entity-level virtual accounts silently accumulate internal balances no one documents until audit or repatriation forces the question.
One-bank thinking — a design that only one bank can operate, discovered during the next banking RFP.
Expecting them to replace all accounts — some real accounts are genuinely required; virtual accounts reduce the count, they don't eliminate it.

Design the structure from the reports you need, keep it as shallow as those reports allow, and treat virtual balances with the same intercompany discipline as physical sweeps — then VAM delivers what it promises: the identification of many accounts, the administration of few. The companion discipline is managing the real accounts you do keep, which is where eBAM comes in.