vIBAN
A virtual account is a sub-account number, usually a virtual IBAN, that looks like a real bank account to the payer but is actually an alias mapped by the bank to a single physical master account plus a reference, letting receivers identify the payer or invoice automatically from the destination account.
A virtual account is a sub-account identifier, typically a virtual IBAN (vIBAN), that a bank issues against a single physical master account. To the payer it looks and behaves exactly like a real bank account: it has a valid IBAN, passes payment validation, and accepts SEPA, SWIFT, or domestic transfers. To the receiver, however, it is an alias. The bank maintains an internal mapping that routes any funds sent to the virtual IBAN into the underlying master account, while preserving the virtual IBAN as a reference in the bank statement.
What gets virtualised is the account number, not the money. There is no separate ledger, no separate balance, and no separate liquidity pool. The corporate sees one consolidated cash position on the master account, but every credit line on the statement carries the virtual IBAN that received the funds. That single field is what makes virtual accounts so powerful for accounts receivable: the destination account itself becomes the remittance advice.
In Europe these structures are usually called Virtual Account Management or vIBAN. In other regions the equivalent functionality may be marketed as virtual account services, alias accounts, or sub-account routing. The mechanics are similar regardless of label.
There are two dominant designs. Per-customer virtual accounts assign one unique virtual IBAN to each customer. Whenever that customer pays, regardless of which invoice they are settling, the funds land on their dedicated virtual IBAN. The receiver knows immediately who paid based on the destination account alone, with no need to parse remittance text or chase the payer for an advice. This single change can eliminate the majority of cash application matching problems for B2B receivables.
Per-invoice virtual accounts go one level deeper. Each invoice is issued with its own unique virtual IBAN printed on the document, and the customer is asked to pay that specific account. The payment then identifies the exact invoice automatically. This is heavier to administer because IBANs must be generated, communicated, and tracked per document, but it removes ambiguity completely. It is common in insurance premiums, utility billing, and high-volume subscription environments.
The headline benefit is cash application accuracy. Most unapplied cash sits in receivables because remittance information is missing, partial, or wrong. When the destination IBAN already identifies the payer or the invoice, that entire failure mode disappears. Auto-match rates above 95 percent become normal, and the residual manual work concentrates on genuine exceptions like short payments or deductions rather than identity guesswork.
The second benefit is structural simplification. Multi-entity groups historically opened a separate physical bank account for every legal entity, currency, or business line, producing dozens of accounts, monthly fees, and complex sweep arrangements. Virtual accounts collapse this into one master account per currency with as many virtual IBANs as the business needs. Cash concentrates automatically, intercompany sweeps shrink, and bank fees often drop.
A third benefit is enabling platform and marketplace business models. Operators that hold funds on behalf of merchants, tenants, or sellers can give each one a virtual IBAN that acts like their own account, while liquidity stays consolidated on the master. This same pattern replaces many traditional lockbox arrangements and supports escrow-style flows without separate trust accounts.
The issuing bank allocates a range of virtual IBANs against the master account and exposes either a portal or an API to mint individual virtual accounts on demand. When a payment arrives, the bank's internal routing maps the virtual IBAN to the master, posts the credit, and records the virtual IBAN on the statement.
For ERP and treasury integration, the virtual account identifier shows up in the bank file. In camt.053 messages it typically appears in a sub-account or related-account structure, and in MT940 it lands in the narrative or related field. The treasury or AR system reads that field, looks up the corresponding customer or invoice in its mapping table, and posts the cash automatically. Real-time crediting through Open Banking APIs is increasingly common, which means the AR ledger can update within seconds of the payment landing.
Virtual IBANs raised anti-money-laundering questions in the European Union because the payer cannot always tell which institution truly holds the funds. An EBA opinion published in 2022 clarified that the issuing bank remains responsible for know-your-customer and transaction monitoring on the underlying master, and that the corporate receiving the virtual IBANs must apply equivalent due diligence to its end customers where relevant. Some jurisdictions require additional reporting or restrict cross-border issuance.
Practical implementation challenges include per-account fees that can add up at scale, ERP work to maintain the virtual IBAN to customer or invoice mapping, customer communication to ensure each payer uses the correct IBAN, and portability risk if the corporate later changes banks. None of these are blockers, but they belong in the business case alongside the cash application savings.
An AI-native AR platform treats the virtual IBAN as the highest-confidence matching signal available. When a payment arrives on a per-customer virtual account, the customer is identified with certainty and the engine only needs to allocate the cash across that customer's open invoices, which is itself a solved problem when invoice numbers, amounts, or aging are available. Per-invoice virtual accounts collapse the problem to a single lookup.
The remaining intelligence sits around exceptions. Agentic matching workflows detect payers who used the wrong virtual IBAN, propose reallocations, flag duplicate or overpayments, and learn customer-specific behaviours such as netting habits or rounding. The same engine integrates with subscription billing systems, prorations, and credit notes, so the cash application result feeds straight into collections, dispute, and credit decisioning without manual touch.
A virtual IBAN is a real, valid IBAN in the sense that it passes payment system validation and can receive funds, but it is not a separately ledgered account. It is an alias that the issuing bank maps to a single physical master account. The payer sees a normal IBAN, while the receiver sees consolidated funds on the master plus the virtual IBAN as a reference field on the statement.
A traditional sub-account is a real ledger held by the bank with its own balance and often its own statements. A virtual account has no independent balance; it exists only as a routing alias against a master. Virtual accounts are cheaper to operate at scale and concentrate liquidity automatically, while sub-accounts give clearer segregation when that is a legal or operational requirement.
Most unapplied cash is caused by missing or ambiguous remittance information. When each customer or each invoice pays into its own unique virtual IBAN, the destination account itself identifies the payer or the invoice. Cash application no longer depends on parsing free-text references, and auto-match rates typically climb well above 95 percent for receipts routed through virtual accounts.
Yes. Virtual IBANs are widely used across the European Union, and an EBA opinion in 2022 clarified the supervisory expectations. The issuing bank retains responsibility for anti-money-laundering controls on the master account, and the corporate using the virtual IBANs must apply appropriate due diligence to its own end customers. Some member states impose additional reporting on cross-border virtual issuance.
For many B2B and subscription use cases, yes. A lockbox traditionally aggregated paper and electronic remittances at a bank facility for processing. Virtual accounts achieve the same goal of cleanly attributing incoming funds without the lockbox infrastructure, and they extend naturally to multi-currency and cross-border flows. Lockbox can still be useful where physical cheque volumes remain high.
Pricing varies by bank and region, but typical European structures involve a one-off setup, a small monthly fee per virtual IBAN, and sometimes a per-transaction component. Costs can range from a few euros to several tens of euros per virtual IBAN per month at low volumes, with steep discounts for large ranges. Most corporates recover the cost quickly through lower unapplied cash and reduced manual matching effort.
