Article map
Virtual accounts and on-behalf-of structures promise a compelling combination: fewer physical bank accounts, better transaction identification, centralised payment execution and more transparent cash positions. The promise is real, but the operating design is more demanding than the technology label suggests. A virtual account is not automatically a separate bank account, a legal owner or an accounting subledger. Payments-on-behalf-of and collections-on-behalf-of do not remove the need to preserve the underlying entity obligation and settlement evidence.
The design challenge is therefore to centralise cash and execution while keeping attribution intact. Treasury must know whose cash is being held, whose liability is being settled, which entity bears bank and FX charges, how intercompany positions arise and how the activity is represented in the ledger and statutory records.
This article explains how a TMS can support virtual-account, POBO and COBO structures as governed operating models rather than isolated bank products.
1. Choose the structure by business problem, not fashion
Virtual accounts can support collections, payments, reconciliation, customer identification, entity reporting and liquidity concentration, but different use cases require different designs. Treasury should first define the operating problem and the legal or commercial constraints before choosing a bank offering or account-number model.
The operating boundary should define:
- virtual receivables identifiers mapped to customer, invoice, entity or business line
- virtual disbursement accounts that preserve payer identity or simplify beneficiary reconciliation
- payments-on-behalf-of where a central entity executes obligations for participating entities
- collections-on-behalf-of where receipts enter a central physical account but remain attributable
- hybrid structures that retain local physical accounts where tax, regulation or market practice requires them
The target should explain what changes and what does not. A virtual identifier may simplify reconciliation without changing legal ownership; an on-behalf-of model may change intercompany settlement and documentation significantly.
2. Create a durable attribution model
The central data problem is attribution. Every virtual-account transaction should be connected to the underlying legal entity, customer or supplier, invoice, currency, purpose and accounting treatment. The mapping must survive bank-format differences and remain valid as customers, entities and products change.
The governed data record should capture:
- stable virtual-account identifier and status with effective dates
- physical settlement account, servicing bank and applicable currency
- underlying entity, business unit, customer, supplier or contract relationship
- invoice, payment proposal, remittance and bank-transaction references
- intercompany due-to and due-from rules, fee allocation and FX conversion treatment
Mappings should be versioned rather than overwritten. When a virtual identifier is reassigned or an entity moves to another structure, the TMS must still be able to interpret historical transactions correctly.
3. Connect initiation, settlement, attribution and accounting
A robust operating flow begins before the bank transaction and ends after accounting and intercompany settlement. For POBO, the central payment instruction must retain the original obligor and approval. For COBO, the receipt must be allocated to the correct entity and open item before cash is treated as available at group level.
The end-to-end workflow should make visible:
- source-system obligation or receivable captured with legal-entity identity
- policy and approval performed at the appropriate central and local levels
- bank instruction carrying structured on-behalf-of and remittance information where supported
- bank status and settlement matched to the originating transaction
- automatic posting of entity accounting, central cash movement and intercompany position
The TMS should make the full chain visible. Users should not have to infer the underlying entity from a free-text narrative or reconstruct the intercompany balance after period end.
4. Preserve legal, tax and customer clarity
Centralisation can create ambiguity if documentation and communications are weak. Suppliers may not recognise the payer, customers may send funds using the wrong identifier, and entities may assume central treasury owns risks that legally remain local. Design decisions require jurisdiction-specific tax and legal review.
The control architecture should address:
- formal participation agreements defining authority, ownership, fees and responsibilities
- clear customer and supplier communication of account and remittance instructions
- validation that payment and collection descriptions preserve required entity information
- controlled virtual-account issuance, modification, suspension and reuse
- reconciliation of intercompany balances and settlement according to approved policy
The system should distinguish an operational convenience from a legal conclusion. Product configuration cannot replace advice on agency, beneficial ownership, withholding, permanent establishment, exchange controls or local reporting.
5. Configure the TMS around one-to-many relationships
Traditional account masters assume one account number, one owner and one ledger mapping. Virtual-account structures require richer relationships: many virtual identifiers may settle through one physical account, while one legal entity may use several identifiers by customer, business or currency.
The TMS configuration should support:
- hierarchical physical and virtual account master data
- rules-based allocation using identifiers, references, amount and counterparty data
- POBO and COBO flags carried through payment, receipt, reconciliation and reporting records
- automatic intercompany calculation with configurable settlement and netting cycles
- exception queues for unidentified receipts, invalid identifiers and ownership conflicts
The user interface should allow group cash to be viewed both physically and economically. Physical-account views support bank control; attributed-entity views support ownership, forecasting and accounting.
6. Measure attribution quality and operating value
Success is not demonstrated by the number of virtual accounts issued. The relevant outcomes are faster identification, fewer physical accounts, stronger straight-through processing and reliable entity reporting. Metrics should also expose hidden operating costs such as manual reassignment and unresolved intercompany breaks.
Management reporting should measure:
- percentage of receipts automatically attributed to customer, invoice and entity
- physical accounts eliminated or avoided through the structure
- payment and collection straight-through processing rate
- unidentified cash value and ageing by root cause
- intercompany balances created, settled and overdue under the on-behalf-of model
A high auto-allocation rate can still mask poor quality if incorrect mappings are not detected. Sampling and downstream reconciliation should confirm that automation is accurate, not merely fast.
7. Pilot with a bounded flow and scalable rules
The safest implementation starts with a defined population such as one country, currency, business line or customer group. The pilot should test bank capability, identifier design, ERP posting, intercompany logic and participant behaviour before the structure is expanded.
The implementation plan should sequence:
- select a use case with material manual reconciliation but manageable legal complexity
- agree the identifier convention and prevent accidental reuse
- test source-to-bank-to-ledger processing including reversals and returns
- run customer or supplier communication and support processes before migration
- expand only after allocation accuracy and intercompany reconciliation are stable
Scaling should reuse one canonical design rather than recreating a bespoke interpretation for each bank. Bank-specific formats can vary, but entity ownership and accounting semantics should remain consistent.
Management questions before approval
Before management approves virtual accounts treasury, the discussion should test the boundary described by choose the structure by business problem, not fashion, the reliability of stable virtual-account identifier and status with effective dates, and whether formal participation agreements defining authority, ownership, fees and responsibilities remains effective when an exception occurs. It should also ask how percentage of receipts automatically attributed to customer, invoice and entity will reveal whether the decision delivered its intended treasury result.
- Is the business problem for the virtual or on-behalf-of structure explicit?
- Have legal ownership and operational attribution been distinguished?
- Does every identifier map to an effective-dated entity and purpose?
- Can the bank message preserve required payer, payee and remittance information?
- Are intercompany entries and settlement rules defined before go-live?
- Have tax, legal and regulatory implications been reviewed by jurisdiction?
The TMS record should connect those answers to connect initiation, settlement, attribution and accounting and to the action 'select a use case with material manual reconciliation but manageable legal complexity'. Where judgement changes the normal route for virtual accounts treasury, the evidence, approver, effective date and next review should remain visible beside hierarchical physical and virtual account master data.
Evidence a controlled TMS should retain
The operating record for virtual accounts and on-behalf-of structures should show how stable virtual-account identifier and status with effective dates became an approved action under preserve legal, tax and customer clarity. It should retain source identity, calculation or transformation, workflow status, exception treatment and approval, together with the downstream result represented by hierarchical physical and virtual account master data.
- formal participation agreements defining authority, ownership, fees and responsibilities
- clear customer and supplier communication of account and remittance instructions
- validation that payment and collection descriptions preserve required entity information
- hierarchical physical and virtual account master data
- rules-based allocation using identifiers, references, amount and counterparty data
- POBO and COBO flags carried through payment, receipt, reconciliation and reporting records
Version history for stable virtual-account identifier and status with effective dates should preserve the information used when the decision was taken, even if later correction changes the current view. Comparing that history with percentage of receipts automatically attributed to customer, invoice and entity and the practical outcome in 'central collections without losing entity ownership' allows management to evaluate process discipline and decision quality without hindsight rewriting.
Practical illustration: central collections without losing entity ownership
A group with eight subsidiaries receives customer payments into thirty-two local accounts. Customer references are inconsistent, and central treasury cannot distinguish cash that is economically available from cash awaiting entity allocation. The group introduces virtual collection accounts mapped to entity and customer, with all receipts settling into four physical accounts.
The TMS allocates most receipts automatically, posts the subsidiary receivable clearing and central cash entry, and creates the corresponding intercompany balance. Exceptions are routed to local finance with the bank narrative and candidate invoices. Group cash visibility improves immediately, but treasury continues to report balances by attributed entity and does not treat unidentified receipts as freely deployable.
The control benefit comes from keeping both views: the physical bank position and the economic ownership position.
Implementation checklist
A treasury team preparing to operationalise this topic should be able to answer yes to the following questions:
- Is the business problem for the virtual or on-behalf-of structure explicit?
- Have legal ownership and operational attribution been distinguished?
- Does every identifier map to an effective-dated entity and purpose?
- Can the bank message preserve required payer, payee and remittance information?
- Are intercompany entries and settlement rules defined before go-live?
- Have tax, legal and regulatory implications been reviewed by jurisdiction?
- Can reversals, returns and unidentified transactions be processed?
- Are customers and suppliers given clear instructions?
- Can treasury report physical cash and attributed cash separately?
- Are mapping accuracy and unresolved exceptions monitored?
Common design failures
Structures fail when centralisation is implemented at the bank layer without redesigning ownership, accounting and workflow.
- assuming a virtual account is legally equivalent to a physical account
- using free text rather than stable identifiers for entity attribution
- creating POBO payments that obscure the original obligor or approval
- leaving intercompany balances to be calculated manually at month end
- reusing identifiers without preserving historical effective dates
- treating unidentified or restricted cash as immediately deployable
A sound model makes central execution simpler while increasing, not reducing, the precision with which the group can explain every transaction.
Closing perspective
Virtual accounts and on-behalf-of structures can materially improve treasury efficiency, but their value depends on attribution discipline. Physical concentration must remain connected to economic ownership, original obligation, approval, accounting and intercompany settlement.
A TMS is the natural control layer when it models those relationships explicitly and preserves them through the full transaction lifecycle. That turns a bank product into an enterprise operating capability.
Frequently asked questions
What is the difference between a virtual account and a physical bank account?
A virtual account is generally an identifier used to route or attribute transactions to an underlying physical settlement account. Its legal and operational characteristics depend on the bank product and jurisdiction, so treasury should not assume it creates separate ownership.
What do POBO and COBO mean?
Payments-on-behalf-of allows a central entity to execute payments for participating entities. Collections-on-behalf-of centralises receipts while attributing them to the underlying entities. Both require clear authority, accounting and intercompany rules.
How does a TMS support virtual accounts?
A TMS can maintain physical-to-virtual mappings, allocate transactions, preserve legal-entity identity, automate accounting and intercompany entries, manage exceptions and report both physical cash and attributed ownership.