Evolution of different types of virtual accounts has created a potentially confusing array of solutions of different levels of sophistication and serving different corporate needs. This article looks at the different types of virtual accounts and clarifies where they should fit in the treasurer’s toolkit.

Different virtual account types

Early virtual accounts were designed to facilitate accounts receivable reconciliation – the first idea being to assign one virtual account number to each customer.

Early virtual account systems required corporates to ask their bank to load each customer virtual account into their back-end systems – often, ironically, on paper forms. This was called static virtual account. An early natural enhancement was the dynamic virtual account where any customer code – so long as the root account number is correct and the whole complies with clearing rules – is accepted by the bank.

Some corporates have experimented with unique virtual account numbers for each invoice. This can work for collections from retail customers but corporate governance around procure-to-pay processes makes it unwieldy for business-to-business collections.

Once dynamic virtual account came along, creative minds quickly realised that the <customer> free format segment could be segmented in different ways to suit corporate requirements.

Virtual accounts beyond reconciliation

Once the dynamic virtual account had brought in the concept of multiple segments in the free format section of the virtual account number, more functionality became conceivable.

As shown above, while <root> must identify the legal entity owning the account, the free form part can be used for profit centre, cost centre, business unit, or other organisational entity within the account owning legal entity.

After the concept of including multiple organisational entities within the virtual account gained acceptance, the next evolution was to extend beyond reporting to bank account operation and authorisation. Using a virtual account for reconciliation is simply a reporting exercise – the single bank account can be viewed and reported as if it was multiple virtual accounts corresponding to each customer or to each profit centre and customer segment. This has no impact on the account from an operational perspective – no change to authorisations and other governance, and no major change to ebanking for example.

To make the virtual account work more like a normal bank account requires full operational capabilities by virtual account with different signatories and governance for each organisational entity within the virtual account structure. Then virtual accounts can be used for payments and indeed can fully replace what might have previously been separate legal bank accounts.

Multi-entity virtual accounts

With the virtual account evolving beyond the reporting functionality required for reconciliation to full bank account functionality, the next logical step was to go multi-entity, following the IHB concept.

Normally IHB is run on ERP or TMS software which segments flows into separate participating entities. In this scenario, the bank’s virtual account software is providing IHB functionality for the corporate – not without irony.

Multi-currency virtual accounts

A further evolution comes from the increasing popularity of multi-currency accounts. In many ways, multi-currency accounts resemble virtual accounts – one legal bank account which is segmented into different sub parts. In the case of multi-currency accounts, it is segmented into different currencies. In the case of the virtual account, it is segmented into different organisational entities.

Once we have the concept of multiple segments within the free format section of the virtual account number, we can combine the two.

Virtual account functionality

We can summarise the evolution of virtual accounts as follows:

• Reconciliation.

  Segmented reporting.

• Multiple organisational entities.

  Segmented governance and ebanking.

• Multiple legal entities.

  Functionally similar to above, includes legal entities not just departments.

• Multi-currency.

  All of the above plus multiple currencies.

It is important to be clear that even a sophisticated multi-currency multi-entity virtual account structure can still support reconciliation of both collections (eg by customer) and payments (eg segmenting direct versus indirect procurement). As virtual accounts become more sophisticated they have retained the basic functionality. In other words, the extra virtual account functionality is additive.

Cash management landscape

It is also helpful to situate virtual accounts within the cash management landscape. Cash management requires that treasurers manage flows and balances to optimise ‘cost effective risk reduction’ (CERR).

There are two ways to pool cash balances – as intercompany balances and as bank balances.

Intercompany balances require journal entries into the general ledger and give rise to withholding tax in the many countries where withholding tax on intercompany interest applies. Bank balances generally require less accounting and most countries do not apply withholding tax on bank interest.

Managing flows focuses on cost reduction, process efficiency and control.

Comparing virtual accounts

Virtual accounts combine different functionality that touches on different parts of the cash management landscape.

• Reconciliation.

  Helps flow process efficiency, especially for collections and accounts receivable.

• Multiple organisational entities.

  Primarily helps flow process efficiency and also helps balance management through account rationalisation.

• Multiple legal entities.

  Helps balance management by pooling different legal entity balances into one account, generating intercompany balances, analogous to IHB.

• Multi-currency.

  Helps balance management by pooling currency balances, analogous to single entity multi currency notional pooling.

The basic reconciliation functionality helps flow management by improving flow process efficiency, especially for collections. It can have a benefit for balance management when virtual account permits account rationalisation.

Account rationalisation solves the common historical problem of excess bank accounts often set up to facilitate collections management – for example, one account per department or per business unit. With a virtual account, these can be combined into a single bank account balance without losing control over collections. In fact, virtual accounts normally improve collection efficiency by allowing one virtual account per customer.

Virtual account structures including multiple legal entities are in many ways functionally equivalent to IHB. Because multi-entity virtual accounts outsource the system work to the bank, this can be an attractive solution for corporates who struggle with IHB. This is typically because they have heterogenous accounting systems and/or do not have the resources to implement IHB with an ERP or TMS.

Multi-currency virtual accounts – to the extent that they allow negative balances (overdraft) in some currencies – are functionally equivalent to single-entity multi-currency notional pooling. They solve the cross-currency problem which is not intrinsically addressed by any of the intercompany balance management solutions. This can be attractive for established IHBs using their ERP or TMS to manage intercompany current accounts (and who therefore may not need the other virtual account functionality described above).

Conclusion

Virtual account technology is wonderful for cash managers. To make best use of virtual accounts requires understanding of their different functionalities and how they compare with other cash management tools that are available.