Virtual accounts (VAs) are remittance or ledger identifiers issued against one or more physical master bank accounts. Payers can send to a unique VA reference (often looking like an IBAN or account number) while cash still lands in the master’s legal balance. The bank (or TMS overlay) then allocates that cash to the right customer, invoice, or group entity.
VAs solve visibility and reconciliation. They do not, by themselves, create a separate legal deposit relationship, replace a subsidiary’s licensed bank account, or deliver notional pooling interest offset. See do virtual accounts replace subsidiary bank accounts? for that boundary.
What they are (and are not)
| They are | They are not |
|---|---|
| Unique collection / allocation keys on a master account | Separate legal bank accounts for each subsidiary |
| A way to auto-match remittances to customers or entities | Automatic [[cash-pooling |
| Often a backbone for [[robo | ROBO]]-style collections |
| Bank or TMS ledger entries with reporting | A substitute for entity KYC where regulators require local accounts |
If marketing slides say “virtual pooling,” ask which product is actually on the term sheet: VA allocation, ZBA concentration, or notional interest offset.
Where treasurers use them
- Collections / AR — one VA per customer, per invoice series, or per entity so unallocated cash shrinks
- ROBO designs — central entity receives; VA keys drive which affiliate’s books get the credit (ROBO)
- Shared service centers — fewer debtor-facing physical accounts without losing entity-level posting quality
- Payment factories (inbound side) — pair with outbound payment factory controls so cash-in and cash-out share the same entity map
- BAM reduction — retire redundant local collection accounts once VA coverage and bank product rules allow (liquidity management still needs real balances somewhere)
Mechanics that matter
- Master account — legal balance, currency, and bank jurisdiction sit here.
- VA issuance — bank portal, host-to-host, or API; know who can create, freeze, and close VAs.
- Remittance information — payer must use the VA identifier; train customers and update invoices / portals.
- Allocation rules — VA → customer / entity / GL; handle partials, overpays, and unknown VAs.
- Statements — camt / MT940 / bank APIs must expose VA-level detail, not only the master total.
- Internal books — if an in-house bank sits on top, map VA credits to internal current accounts without double-counting the master.
Without statement-level VA detail and a clear exception queue, VAs become another unreconciled suspense pile.
Design choices
Granularity — per customer vs per entity vs per business line. Finer keys improve matching and multiply VA inventory and KYC/AML review.
Who owns the master — one regional collection entity vs many local masters. Cross-border VA programmes inherit FX, beneficiary-name, and documentation constraints the same way cross-border cash pooling does.
Bank vs overlay — bank-native VAs ride clearing rails; TMS/ERP overlays may only relabel after cash posts. Overlay-only designs fail when the payer’s bank validates beneficiary account strictly.
Corridor limits — some schemes reject third-party or on-behalf collections even with VAs. Markets such as China often need domestic collection design confirmed before any cross-border VA story.
How VAs sit in the liquidity stack
- Visibility — earlier, cleaner entity/customer cash under liquidity management
- Forecasting — better collection driver data for cash forecasting when VAs map to known counterparties
- Concentration — cash still moves (or does not) via cash pooling; VAs do not concentrate by themselves
- IHB / factory — allocation quality is what makes central collections usable for IHB books and factory funding
Minimum design package
- Purpose statement (AR matching, entity allocation, ROBO, or account reduction)
- Master-account and currency map per corridor
- VA naming / issuance policy and owner
- Allocation and exception playbook (unknown VA, partial pay, name mismatch)
- Bank statement / API contract that includes VA-level detail
- Link to ROBO, payment factory, and pooling decisions so “virtual” is not confused with concentration
VAs earn their keep when unallocated cash and local collection accounts both fall — not when the VA count alone rises.