Virtual Account Concepts

There are many concepts in which a virtual account can be deployed. In this second article on ‘How to setup virtual accounts in SAP’, we depict the concept that can be implemented in SAP the easiest without needing specialized modules like SAP Inhouse cash; all can be supported in the SAP FI-CO module.

In the process, we rely on a simple set of building blocks:

• GL accounts to manage positions between the OpCo’s and Treasury and GL accounts to manage the external cash balance.
• Receipt and processing of external bank statements.
• On the external bank statement for the Master Account, an identifier needs to be available that conveys to which virtual account the actual collection was originally credited. This identifier ultimately tells us to which OpCo these funds originally belongs to.

How to implement virtual accounts in SAP

This part assumes that the basic FI-CO settings for i.e. the company code and such are already in place.

Master Data – General Ledger Accounts

Two sets of GL accounts need to be created: balance sheet accounts for the representation of the intercompany positions and the GL account to represent the cash position with the external bank.

These GL accounts need to be assigned to the appropriate company codes and can now be used to in the bank statement import process.

Transaction code FS00

House bank maintenance bank account maintenance

In order to be able to process bank statements and generate GL postings in your SAP system, we need to maintain the house bank data first. A house bank entry comprises of the following information that needs to be maintained carefully:

1. The house bank identifier: a 5-digit label that clearly identifies the bank branch
2. Bank country: The ISO country code where the bank branch is located.
3. Bank key: The bank key is a separate bank identifier that contains information like SWIFT BIC, local routing code and address related data of your house bank

Transaction code FI12

Secondly, under the house bank entry, the bank accounts can be created.

1. The account identifier: a 5-digit label that clearly identifies the bank account
2. Bank account number and IBAN: This represents the bank account number as assigned to you by the bank.
3. Currency: the currency of the bank account
4. G/L Account: the general ledger account that is going to be used to represent the balance sheet position on this bank account.

Transaction code FI12 in SAP ECC or NWBC in S/4 HANA

The idea here is that we maintain one house bank and bank account in the treasury company code that represents the Master account as held with your house bank. This house bank will have the G/L account assigned to it that represents the house banks external cash position.

In each of the OpCo’s company codes, we maintain one house bank and bank account that represents each of the “virtual” bank accounts as held with your house bank. This house bank will have the G/L account assigned to it that represents the intercompany position with the treasury entity.

Electronic Bank Statement settings

The Electronic Bank Statement (EBS) settings will ensure that, based on the information present on the bank statement, SAP is capable of posting the items into the general or sub ledgers according to the requirements. There are a few steps in the configuration process that are important for this to work:

1. Posting rule construction
   Posting rules construction starts with setting up Account symbols and assigning GL accounts to it. The idea here is to define at least three account symbols to represent the external Cash position (BANK), the IC position with OpCo1 (OPCO1) and thirdly the IC position with OpCo2 (OPCO2). A separate account symbol for customers is not required in SAP.
   For the account symbol for BANK we do not assign a GL account number directly in the settings; instead we will assign a so-called mask by entering the value “+++++++++”. What this does in SAP is for every time the posting rule attempts to post to “BANK”, the GL account as assigned in the house bank account settings is used (FI12 or NWBC setting above).
   For the account symbol OPCO1 and OPCO2 we can assign a dedicated balance sheet GL that represents the IC position with those OpCo’s. These GL accounts have already been created in the first step (FS00).
   Now we have the account symbols prepared, we can start tying together these symbols into posting rules. We need to create 3 posting rules.
   Posting rule 1 is going to debit the BANK symbol and it is going to credit OPCO1 symbol.
   Posting rule 2 is going to debit the BANK symbol and it is going to credit OPCO2 symbol.
   Posting rule 3 is going to debit the BANK symbol and it is going to credit a BLANK symbol. The posting type however is going the be set to value 8 “Clear Credit Subledger Account”. What this setting is going to attempt is that it will try to clear out any open item sitting in the customer sub-ledger using “Algorithms”. More on algorithms a bit later.
   As you can imagine, posting rules 1 and 2 are applicable for the treasury entity. Posting rule 3 is going to be used in the OpCo’s EBS process.
   Transaction code OT83
2. Posting rule assignment
   In the next step we can assign the posting rules to the so-called “Bank Transaction Codes” (or BTC’s like i.e NTRF) that are typically observed in the body of the bank statements to identify the nature of the transactions.
   To understand under which Bank Transaction Code these collections are reported on the statement, you typically need to carefully analyze some sample statement output or check with your banks implementation team for feedback.
   Important to note here is to assign an algorithm to posting rule 3. This algorithm will attempt to search the payment notes of the bank statement for “Reference Numbers” which it can use to trace back the original customer invoice open item. Once SAP has identified the correct outstanding invoice, it can actually clear this one off and identify it as being paid.
   Transaction code OT83
3. Bank account assignment
   In the last part we can then assign the posting rules assignments to the bank accounts. This way we can differentiate different rule assignments for different accounts if that is needed.
   Transaction code OT83
4. Search Strings
   If the posting rule assignment needs more granularity than the level provided in step 2 above here (on BTC level), we can setup search strings. Search strings can be configured to look at the payment notes section of the bank statement and find certain fixed text or patterns of text. Based on such search strings we can then modify the posting behavior by for instance overruling the posting rule assignment as defined in step 2.
   Whether this is required depends on the level of information that is provided by the bank in the bank statements.
   Transaction code OTPM

Importing and processing bank statements

We should now be in good shape to import our first statements. We could download them from our electronic banking platform. We could also be in a situation where we already receive them through some automated H2H interface or even through SWIFT. In any case, the statements need to be imported in SAP. This can be achieved through transaction code FF.5. The most important parameters to understand here are the following:

1. File parameters: Here we define the filename and storage path where our statement is saved. We also need to define what format this file is going to be, i.e. MT940, CAMT.053 or one of the many other supported formats
2. Posting Parameters: Here we can define if the line items on the bank statements are going to be posted to general or sub-ledger.
3. Algorithms: Here we need to set the range of customer invoice reference number (XBLNR) for the EBS Algorithm to search the payment notes for any such occurrence in a focused manner. If we would leave these fields empty, the algorithm will not work properly and will not find any open invoice for automatic clearing.

Once these parameters are maintained in the import variant, the system will start to load the statements and generate the required postings.

Transaction code FF.5

Closing remarks

Other concepts could be where a payment factory is already implemented using i.e. SAP IHC and the customers wants to seek additional benefits by using the virtual account functionality of its bank.

This is the second part of a series on how to set up virtual accounts in SAP. Click here to read the first part. A next part, including more complex concepts, will be published soon.

For questions please contact Ivo Postma.