Business margin protection

ARF can be a very efficient hedging instrument when the business margin needs to be protected, namely in the following business scenarios:

• Budgeted sales revenue or budgeted costs of goods sold are incurred with reliable regularity and spread evenly in time. This exposure needs to be hedged against the functional currency.
• The business is run in separate books with different functional currencies, FX exposure is determined and hedged against the respective functional currency of these books. Resulting margin can be budgeted with high degree of reliability and stability, is relatively small and needs to be hedged from the currency of the respective business book to the functional currency of the reporting entity.

Increased complexity

Hedging such FX exposure with conventional FX forwards would lead to a very high number of transactions, as well as data on the side of underlying FX exposure determination, resulting in a data flood and high administrative effort. A hedge accounting according the IFRS 9 rules is almost impossible due to high number of hedge relationships to manage. The complexity increases even more if treasury operations are centralized and the FX exposure has to be concentrated via intercompany FX transactions in the group treasury first.

If the ARF instruments are not directly supported by the used treasury management system (TMS), the users have to resort to replicating the single external ARF deal with a series of conventional FX forwards, creating individual FX forwards for each fixation date of the observation period. As the observation periods are usually long (at least 30 days) and rate fixation periodicity is usually daily, this workaround leads to a high count of fictitious deals with relatively small nominal, leading to an administrative burden described above. Moreover, this workaround prevents automated creation of deals via an interface from a trading platform and automated correspondence exchange based on SWIFT MT3xx messages, resulting in a low automation level of treasury operations.

Add-on for SAP TRM

Currently, the ARF instruments are not supported in SAP Treasury and Risk management system (SAP TRM). In order to bridge the gap and to help the centralized treasury organizations to further streamline their operations, Zanders has developed an add-on for SAP TRM to manage the fixing of the average rate over the observation period, as well as to correctly calculate the fair value of the deals with partially fixed average rate.

The solution consists of dedicated average rate FX forward collective processing report, covering:

• Particular information related to ARF deals, including start and end of the fixation period, currently fixed average rate, fixed portion (percentage), locked-in result for the fixed portion of the deal in the settlement currency.
• Specific functions needed to manage this type of deals: creation, change, display of rate fixation schedule, as well as creating final fixation of the FX deal, once the average rate is fully calculated through the observation period.

Figure 1 Zanders FX Average Rate Forwards Cockpit and the ARF specific key figures

The solution builds on the standard SAP functionality available for FX deal management, meaning all other proven functionalities are available, such as payments, posting via treasury accounting subledger, correspondence, EMIR reporting, calculation of fair value for month-end evaluation and reporting. Through an enhancement, the solution is fully integrated into market risk, credit risk and, if needed, portfolio analyser too. Therefore, correct mark-to-market is always calculated for both the fixed and unfixed portion of the deal.

Figure 2 Integration of Zanders ARF solution into SAP Treasury Transaction manager process flow

The solution builds on the standard SAP functionality available for FX deal management, meaning all other proven functionalities are available, such as payments, posting via treasury accounting subledger, correspondence, EMIR reporting, calculation of fair value for month-end evaluation and reporting. Through an enhancement, the solution is fully integrated into market risk, credit risk and, if needed, portfolio analyser too. Therefore, correct mark-to-market is always calculated for both the fixed and unfixed portion of the deal.

Zanders can support you with the integration of ARF forwards into your FX exposure management process. For more information do not hesitate to contact Michal Šárnik.

The process where virtual accounts are managed in IHC is depicted below:

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

• In-house cash accounts to manage intercompany positions between Treasury and OpCo’s,
• GL accounts to represent external cash and the IC positions.
• Processing of external bank statements,
• Distribution of internal bank statements from IHC towards the OpCo’s ERP system,
• 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 which OpCo these funds originally belongs to and which IHC account to credit.

The idea here is that Treasury will receive the external bank statement and automatically post the receipts into the correct IHC account using the identifier. By posting items on the IHC account, the intercompany positions are updated. Then, at the end of the day, a set of internal bank statements is generated in IHC and sent through an interface to the OpCo’s ERP. The OpCo’s ERP processes these statements, clears out the customers invoices and updates the IC position with treasury.

The two major benefits of using IHC over the solution as described in the previous articles of this series are:

1. The OpCo’s do not require any direct integration with the bank and can rely on internal interfacing with Treasury. Especially in companies with a fragmented ERP landscape this can become a valuable proposition.
2. IHC can very aptly integrate virtual account management processes with internal netting payments, payments on behalf of (POBO) and payment in name of processes.

Implementing virtual accounts in SAP

In the explanation below we assume that the basic FI-CO settings for the company code a.o. are already in place. Also, it is by no means a complete inventory of all the settings that are required to get IHC up and running. It focusses more on the configurational parts that specifically cater for the VA requirements specifically.

Master data – general ledger accounts

Three sets of GL accounts need to be created: balance sheet accounts for the representation of the intercompany positions, one set for virtual account clearing purposes between the EBS and the IHC accounting process, 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 and the IHC accounting process.

In the Treasury entity we should create a single GL (per position currency) representing the IC position with all its OpCo’s because the granularity of IC position per OpCo is managed in the IHC subledger. This approach results in less of an increase of accounts in the chart of account.

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, including:

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. Or the IC position with Treasury.

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 IHC bank accounts as held with the treasury center. 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 two account symbols, the first one to represent the external Cash position (BANK), and the second one for the virtual account clearing between IHC and EBS (VACLR)

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 VACLR we can assign a dedicated O/I clearing GL that is used to clear out the EBS posting against the IHC posting (more on that later). These GL accounts should have already been created in the first step (FS00).

Now that 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 VACLR symbol

Posting rule 2 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 to clear out any open item sitting in the customer sub-ledger using algorithms. We will explain more on these algorithms below.

As you can imagine, posting rule 1 is applicable for the Treasury entity. Posting rule 2 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 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 bank’s implementation team for feedback.

Important to note here is to assign an algorithm to posting rule 2. 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 clear this one off and identify it as being paid.

If SAP is unsuccessful to automatically identify the open item, it can be manually post processed in FEBAN or FEB_BSPROC.

Transaction code OT83

3) Bank account assignment

In the last part, we can 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 (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 its bank statements.

Transaction code OTPM

Prepare IHC to parallel post certain bank statement items into IHC accounts

In IHC there are two ways to parallel post bank statement items into IHC accounts; as payment items or as payment orders.

This can be controlled by setting a specific function module on BTE2810. If we set function module “BKK_IHB_BASTA_IN_POST”, SAP will post an IHC payment item. If we assign “IHC_APPL_XBS_POST”, SAP will post an IHC payment order.

Additional information can be found in note 2370212.

In the subsequent part of the article we assume that we use the payment item logic.

Transaction BF42

IHC account determination from payment notes

In this section of the configuration we can determine which IHC account should be used to post the bank statement items towards using payment notes search strings.

For example, if the master account bank statement payment notes for VA collections for a particular VA contains a string “From VA 54353” and we know this belongs to IHC account “F4000EUR01”, we can setup a rule in this part of the configuration for that. This will ensure that all items on a bank statement containing this text string will get posted into IHC account F4000EUR01.

Maintenance view TBKKIHB1

Assign external BTC to posting category

Here we can identify the external banks BTC codes (NTRF, NCMZ a.o.) which are applicable for the VA movements to post into IHC. Secondly, we can identify with which posting category to post them into the IHC accounts.

Once we identified the BTC code related to our VA collections (e.g. NCMZ), we can link them to the correct posting categories here. You could use standard categories 90 (Balancing Ext. Acct (D)) for debits and 91 (Balancing Ext. Acct (C)) for credits.

Alternatively, you can setup and link your own custom posting categories here to more precisely control how our VA collections are posted into IHC. This is out of scope for this article though.

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 whether 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 would not work properly and would 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 / FEBP

Display IHC account statement

Now that we successfully loaded an external bank statement, we can now check whether the items are posted into the IHC account. This can be done via transaction code F9K3. For each IHC account we can now look at the “Account Turnover” and observe all the VA collections that are posted on the account.

Transaction code F9K3

Prepare the IHC account for FINSTA statement distribution

We need to enable the distribution of internal IHC statements to the OpCo’s ERP on the IHC account master record. This can be achieved via F9K2. On the “Account Statement” tab we can adjust the statement format to “FINSTA” and dispatch type to “ALE” to ensure we are going to send FINSTA statements over an ALE connection. This would be the most common combination; other combinations can be configured and selected here as well.

Transaction code F9K2

Setting up ALE partner profiles

Finally, we can configure the system to determine to which system the FINSTA’s need to be send. This can be done in WE20, partner type GP (business partner).

Here we need to setup the outbound parameters for the FINSTA message type. An appropriate port needs to be selected that represents the ERP of the OpCo.

Transaction code WE20

Trigger the distribution of a FINSTA statement

Now that we have some transactions posted on the IHC account and the FINSTA settings enabled, we can trigger the system to send the FINSTA statements to the receiving ERP system. This can be done in F9N7.

Here we can select the correct IHC account and statement date and run the program to generate the FINSTA statement.

Once the finsta is generated and sent to the receiving ERP, it can be processed there via FEBP there.

Transaction code F9N7

Closing remarks

This is the third part of a series on how to set up virtual accounts in SAP. Please find below the other articles on this subject:

• Virtual Account Concepts | How to setup virtual accounts in SAP, Part II
• Why should a Treasury implement virtual accounts? | How to setup virtual accounts in SAP, Part I

We have has been assisting dozens of multinationals on this topic through our Transfer Pricing Solution (TPS). The TPS enables them to set interest rates on intercompany transactions in a compliant and automated way. Since its go-live, clients have priced over 1000 intercompany loans with a total notional of over EUR 60 billion using this self-service solution.

Cash Pooling Solution

In February 2020, the OECD published the first-ever international consensus on financial transactions transfer pricing. One of the key topics of the document relates to the determination of internal pooling interest rates. As a reaction, Zanders has launched a co-development initiative with key clients to design a Cash Pooling Solution that determines the arm’s length interest rates for physical cash pools, notional cash pools and in-house banks.

The goal of this new solution is to present treasury and tax professionals with a user-friendly workflow that incorporates all compliance areas as well as treasury insights into the pooling structure. The three main compliance areas for treasury professionals are:

1. Ensuring that participants have a financial incentive to participate in the pooling structure. Entities participating in the pool should be ‘better off’ than they would be if they went directly to a third-party bank. In other words, participants’ pooled rates should be more favorable than their stand-alone rates. The OECD sets out a step-by-step approach to improve interest conditions for participating entities to distribute the synergies towards the participants.First, the total pooling benefit should be calculated. This total pooling benefit is the financial advantage for a group compared to a non-pooled cash management set-up. The total pooling benefit can be broken down into a netting benefit and an interest rate benefit. The netting benefit arises from offsetting debit and credit balances. The interest rate benefit arises from more beneficial interest rate conditions on the cash pool or in-house bank position, compared to stand-alone current accounts.
   Once the total pooling benefit has been calculated, it should be allocated over the leader entity and the participating entities. Therefore, a functional analysis of the pooling structure should be made to identify which entities contribute most in terms of their balances, creditworthiness and the administration of the pool. The allocated amount should be priced into the interest rates. A deposit rate will thus receive a pooling premium. A withdrawal rate will incorporate pooling discount.
2. Ensuring a correct tax treatment of the cash pool transactions. Pooling structures are primarily in place to optimize cash and liquidity management. Therefore, tax authorities will expect to see the balances of cash pool participants fluctuate around zero. Treasury professionals should monitor positions to prevent participants from having a structural balance in the pool. If the balance has a longer-term character, tax authorities can classify such pooling position as a longer-term intercompany loan. Consequently, monitoring structural balances can lower tax risk significantly.
3. Appropriate documentation should be in place for each time treasury determines the pooling interest rates. The documentation should include the methodology as well as all specifics of the transfer pricing analysis. Proper documentation will enable the multinational to substantiate the interest rates during tax audits.

Multinationals are confronted with a significant compliance burden to comply with these new guidelines. Different hurdles can be identified, ranging from access to the appropriate market data to a considerable and recurring time investment in determining and documenting the internal deposit and withdrawal rates for each pooling structure.

It remains to be seen how auditors treat these new guidelines, but the recent increased focus on transfer pricing seems to indicate that this will be a topic that may need additional attention in the coming years.

Zanders Inside solutions

In order to support treasury and tax professionals in this area, Zanders Inside launched its cloud-based Cash Pooling Solution. This solution will focus on each of the three compliance areas as described above. In addition, the solution leverages a high degree of automation to support the entire end-to-end process. It offers a cost-effective alternative for the manual process that multinationals go through. Please watch our video showing how the Cash Pooling Solution tackles the challenge of OECD compliancy.

This exemption has been applied in a diverse way by supervisors and therefore, the treatment of Structural FX risk has been updated in recent regulatory publications. In this article we discuss these publications and market practice around Structural FX risk based on an analysis of the policies applied by the top 25 banks in Europe.

Based on the 1996 amendment to the Capital Accord, banks that apply for the exemption of Structural FX positions can exclude these positions from the Pillar 1 capital requirement for market risk. This exemption was introduced to allow international banks with subsidiaries in currencies different from the reporting currency to employ a strategy to hedge the capital ratio from adverse movements in the FX rate. In principle a bank can apply one of two strategies in managing its FX risk.

1. In the first strategy, the bank aims to stabilize the value of its equity from movements in the FX rate. This strategy requires banks to maintain a matched currency position, which will effectively protect the bank from losses related to FX rate changes. Changes in the FX rate will not impact the equity of a bank with e.g. a consolidated balance sheet in Euro and a matched USD position. The value of the Risk-Weighted Assets (RWAs) is however impacted. As a result, although the overall balance sheet of the bank is protected from FX losses, changes in the EUR/USD exchange rate can have an adverse impact on the capital ratio.
2. In the alternative strategy, the objective of the bank is to protect the capital adequacy ratio from changes in the FX rate. To do so, the bank deliberately maintains a long, open currency position, such that it matches the capital ratio. In this way, both the equity and the RWAs of the bank are impacted in a similar way by changes in the EUR/USD rate, thereby mitigating the impact on the capital ratio. Because an open position is maintained, FX rate changes can result in losses for the bank. Without the exemption of Structural FX positions, the bank would be required to hold a significant amount of capital for these potential losses, effectively turning this strategy irrelevant.

As can also be seen in the exhibit below, the FX scenario that has an adverse impact on the bank differs between both strategies. In strategy 1, an appreciation of the currency will result in a decrease of the capital ratio, while in the second strategy the value of the equity will increase if the currency appreciates. The scenario with an adverse impact on the bank in strategy 2 is when the foreign currency depreciates.

Until now, only limited guidance has been available on e.g. the risk management framework, (number of) currencies that can be in scope of the exemption and the maximum open exposure that can be exempted. As a result, the practical implementation of the Structural FX exemption varies significantly across banks. Recent regulatory publications aim to enhance regulatory guidance to ensure a more standardized application of the exemption.

Regulatory Changes

With the publication of the Fundamental Review of the Trading Book (FRTB) in January 2019, the exemption of Structural FX risk was further clarified. The conditions from the 1996 amendment were complemented to a total of seven conditions related to the policy framework required for FX risk and the maximum and type of exposure that can be in scope of the exemption. Within Europe, this exemption is covered in the Capital Requirements Regulation under article 352(2).

To process the changes introduced in the FRTB and to further strengthen the regulatory guidelines related to Structural FX, the EBA has issued a consultation paper in October 2019. A final version of these guidelines was published in July 2020. The date of application was pushed back one year compared to the consultation paper and is now set for January 2022.

The guidelines introduced by EBA can be split in three main topics:

1. Definition of Structural FX.
   The guidelines provide a definition of positions of a structural nature and positions that are eligible to be exempted from capital. Positions of a structural nature are investments in a subsidiary with a reporting currency different from that of the parent (also referred to as Type A), or positions that are related to the cross-border nature of the institution that are stable over time (Type B). A more elaborate justification is required for Type B positions and the final guidelines include some high-level conditions for this.
2. Management of Structural FX.
   Banks are required to document the appetite, risk management procedures and processes in relation to Structural FX in a policy. Furthermore, the risk appetite should include specific statements on the maximum acceptable loss resulting from the open FX position, on the target sensitivity of the capital ratios and the management action that will be applied when thresholds are crossed. It is moreover clarified that the exemption can in principle only be applied to the five largest structural currency exposures of the bank.
3. Measurement of Structural FX.
   The guidelines include requirements on the type and the size of the positions that can be in scope of the exemption. This includes specific formulas on the calculation of the maximum open position that can be in scope of the exemption and the sensitivity of the capital ratio. In addition, banks will need to report the structural open position, maximum open position, and the sensitivity of the capital ratio, to the regulator on a quarterly basis.

One of the reasons presented by the EBA to publish these additional guidelines is a growing interest in the application of the Structural FX exemption in the market.

Market Practice

To understand the current policy applied by banks, a review of the 2019 annual reports of the top 25 European banks was conducted. Our review shows that almost all banks identify Structural FX as part of their risk identification process and over three quarters of the banks apply a strategy to hedge the CET1 ratio, for which an exemption has been approved by the ECB. While most of the banks apply the exemption for Structural FX, there is a vast difference in practices applied in measurement and disclosure. Only 44% of the banks publish quantitative information on Structural FX risk, ranging from the open currency exposure, 10-day VaR losses, stress losses or Economic Capital allocated.

The guideline that will have a significant impact on Structural FX management within the bigger banks of Europe is the limit to include only the top five open currency positions in the exemption: of the banks that disclose the currencies in scope of the Structural FX position, 60% has more than 5 and up to 20 currencies in scope. Reducing that to a maximum of five will either increase the capital requirements of those banks significantly or require banks to move back to maintaining a matched position for those currencies, which would increase the capital ratio volatility.

Conclusion

The EBA guidelines on Structural FX that will to go live by January 2022 are expected to have quite an impact on the way banks manage their Structural FX exposures. Although the Structural FX policy is well developed in most banks, the measurement and steering of these positions will require significant updates. It will also limit the number of currencies that banks can identify as Structural FX position. This will make it less favourable for international banks to maintain subsidiaries in different currencies, which will increase the cost of capital and/or the capital ratio volatility.

Finally, a topic that is still ambiguous in the guidelines is the treatment of Structural FX in a Pillar 2 or ICAAP context. Currently, 20% of the banks state to include an internal capital charge for open structural FX positions and a similar amount states to not include an internal capital charge. Including such a capital charge, however, is not obvious. Although an open FX position will present FX losses for a bank which would favour an internal capital charge, the appetite related to internal capital and to the sensitivity of the capital ratio can counteract, resulting in the need for undesirable FX hedges.

The new guidelines therefore present clarifications in many areas but will also require banks to rework a large part of their Structural FX policies in the middle of a (COVID-19) crisis period that already presents many challenges.

Compared to intraday bank statement reporting, end-of-day (EOD) bank statement reporting is only available the next calendar day. The information therefore always comes too late to be meaningful for cash management decisions – apart from providing an opening bank balance for the next day.

Business rationale behind IBS reporting

So, why would a Treasury typically start implementing IBS reporting in its cash management processes?

1. Cash visibility: In general, IBS reporting will provide your cash management function an additional tool to improve cash visibility. Achieving cash visibility intrinsically might not be a goal of its own, but by achieving visibility, the cash manager now has information to make certain economically relevant decisions in certain situations.
2. Managing cash: By creating cash visibility, we now have an opportunity to manage cash on our accounts in an intelligent way. In case we estimate a positive closing balance, we could decide to invest this surplus in, for example, a money market fund or overnight deposit to earn some return. In case of an expected deficit, we need to fund the account to ensure no EOD negative position happens. This can be achieved by transferring funds from another bank account (in same currency), swapping funds from another bank account (in different currency), or funding it from, for example, a facility drawdown.
3. Reduced risk of delinquency: As we now implemented a process to increase control over our bank balances, we now have less chance of e.g. rejected payments due to insufficient available funds and therefore less chance of being delinquent on certain obligations to pay.
4. Reduced requirements on overdraft facility: By reducing the chance of having insufficient funds on our account, the overdraft facility requirements can also be reduced.
5. Timely clearing of open items: IBS can also be used to clear off open items throughout the day, as opposed to only rely on clearing from EOD statements. Benefit here is that KPI’s like days sales outstanding (DSO) will improve and that reconciliation effort is spread out more through time.

This article will now only focus on the cash management side; the IBS reconciliation process may be discussed another time. If you like to know more about bank reconciliation using intraday statements, feel free to reach out to us. We have a pre-developed solution that we can implement at your side.

IBS concepts

There are a few design considerations that need to be looked at before attempting to implementing this solution in SAP.

1. Reporting formats: MT942, CAMT.052, BAI2 are formats that can be imported by SAP standard and are also supported by most banks to some degree. There may be some informational or structural benefits that one format has over the other which should be considered in the design.
2. Reporting frequency: It is possible to agree with the bank on reporting frequencies of IBS. Ten times through working hours? Or one time only, half an hour before the payment cut-off time? In most cases, the bank will charge a fee for every statement it sends, so this should be considered in the design.
3. Delta vs cumulative reporting: As it is possible for the bank to report multiple times a day, it is important to understand how the data is reported. There are two methodologies. In case of delta reporting, only new transactions are reported, relative to the previously distributed IBS. Alternatively, there is cumulative reporting, where all booked items are reported on the statement throughout the day. Delta reporting typically means that the data in your SAP system needs to be appended for every new IBS. Cumulative reporting means that every time you process an IBS in SAP, the data needs to be rebuilt completely.
4. Data integration: The intraday data as provided by the bank needs to be integrated with already existing cash-relevant data to compile a proper reporting view of estimated closing balance for the day. This needs to happen in the cash management module of SAP (FF7* reports). The design of the structure of the cash management report should be carefully aligned with the liquidity structure (i.e. ZBA structure).
5. Prevention of duplications: Integrating the intraday data with existing data should be designed with data duplication in mind. It is paramount that the data on the same cash movement is not counted twice from two sources and data duplication should always be prevented while designing the solution. For example, if we are not careful, a payment flow can be included in the report twice, once from the intraday statement when it is debited and once from the payment in transit GL in the SAP administration. This would result in a skewed estimated closing balance.

Ultimately, the goal here is to receive and upload intraday bank statements throughout the day and to load cash movement data into your SAP system. This cash-relevant data needs to be made visible through the cash management reports so that the cash manager can better estimate EOD balances and make intelligent decisions related to funding accounts or investing excess funds.

Setting up Intraday Bank Statement reporting in SAP

We will now go into detail on how to setup intraday statement reporting and assume that the basic FI-CO settings for e.g. the company code are already in place. We also assume that the EOD bank statement process has already been implemented. To learn how to set this up, please read this article on virtual accounts.

Cash Management

It is important to understand that intraday statement data is converted into so called ‘Memo Records’ once loaded in SAP. These memo records can be visualized in the cash management reports (FF7AN/FF7BN). We will now explain the necessary settings on the cash management report section to ensure that the intraday data can be made visible in these cash management reports.

Define planning levels

First, we need to define a planning level; a label that is assigned to all cash movements as reported on the intraday statement. The planning level is used to structure the data in the cash management reports.

The level is a two-digit label, freely definable. We set it to C1.

The sign we need to set to blank as cash movements reported on this level can be both positive and negative.

The source will be ‘BNK’. This ensures that this planning level is reported on both ‘cash position’ and ‘liquidity forecast’ in the FF7AN/FF7BN reports.

The descriptions are freely definable. We define it as ‘INTRADAY’.

Define planning types

A planning type is a label under which a ‘memo record’ is stored on the SAP database. A planning type is subsequently linked to a ‘planning level’ to ensure the underlying data can be visualized in the cash management reports.

First, we define the planning type label: we set it identical to the planning level; C1 and link it to planning level C1.

We need to define an archiving category. This defines the data retention period of the memo records. If the period is exceeded and the reorganization program is executed; the memo record data will be cleansed.

The auto-expiry option defines whether the memo record will expire automatically and becomes invisible in the cash management report output. This needs to be enabled. The idea here is that the intraday statement data will be superseded by the EOD statement data once this is loaded after midnight next calendar day. To ensure we do not double count identical cash movements from both sources, the intraday data needs to be expired.

Also, a number range and description need to be entered. No specific functional considerations are needed here.

Define grouping and maintain headers

A ‘grouping’ is a label that is used to structure the cash management report data in a meaningful manner for the user. The grouping can be selected in the cash management reports and is going to dictate how the data is shown to the user.

We will configure a grouping ‘CASHPOS’.

Maintain structure

Under the grouping we can now maintain the structure of the cash management data. For our report, we are including two components. The first component is the planning level., the second will be the GL account under which we record our bank account balances. This is the GL account we typically maintain in the house bank account data (table T012K, transaction FI13, NWBC).

For the first component we are going to add an entry as follows:

The grouping we set to ‘CASHPOS’.

The type we set to ‘E’ for planning level. Now we can define a planning level that is going to be relevant to our cash management report output.

We set the selection to C1 (our intraday planning level we defined earlier).

This setting will ensure all cash management data as stored under C1 planning level is going to be selected in the report output.

For the second component we are going to add an entry as follows:

The grouping we set to ‘CASHPOS’.

The type we set to ‘G’ for GL Account. Now we can define the bank GL account that is going to be relevant for our cash management report output.

The selection we are going to set to a GL account is saved in our bank account entry in table T012K.

This setting will ensure all cash management data as stored under the GL account and relevant for our bank account will be selected in the report output.

The combination of these two lines is going to ensure that we will only see the C1 data for our one bank account. We can add multiple lines to increase the scope of the reports output.

Importing and processing bank statements

We should now be in good shape to import our first intraday statements. We could download these statements from our electronic banking platform. Also, we could 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 e.g. 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; MT940, CAMT.053, or one of the many other supported formats
2. Posting parameters: Here we can define whether the line items on the bank statements should be posted to general or sub-ledger. This section is not relevant for intraday statements, as SAP does not support GL postings and reconciliation from intraday statements out of the box.
3. Cash management: This is the most important section, specifically for intraday statement processing. The fields and tick boxes control a few parameters:
4. A/CM payment advice: This needs to be enabled to ensure that SAP creates the memo record data from the intraday statements.
5. B/Summarization: This tick box controls whether a single memo record will be created for the whole delta balance as reported on the statement or for each reported debit and credit on the statement. If high volumes are expected, summarization can reduce the number of memo records and improve performance a bit. Obviously, it does reduce the data granularity.
6. C/Planning type: Here we set the planning type under which the memo records are going to be recorded. In our sample we set this to C1.
7. D/ Account balance: This needs to be set if we are loading intraday statements.
8. Algorithms: Here we need to set the range of customer invoice reference number (XBLNR) for the electronic bank statement (EBS) algorithm, to search the payment notes for any such occurrence in a focussed manner. If we would leave these fields empty, the algorithm would not work properly and would not find any open invoice for automatic clearing. This section is not relevant for intraday statements as SAP does not support GL postings and reconciliation from intraday statements out of the box.

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

Now we can check if the memo records are updated in table FDES.

Subsequently, we can check the FF7BN report for grouping ‘CASHPOS’ and observe the output.

The language used to write most programs in SAP is called ABAP (Advanced Business Application Programming). This is an extremely powerful tool. ABAP programs sit directly on the foundation of the SAP system and can be used to change the behavior of existing programs (for example the T-Codes you use every day to perform your tasks), as well as write complete new functionality. Unfortunately, ABAP is so powerful that it cannot be used to automate activities for free, because any development in ABAP must be strictly controlled. It needs to be written by an experienced ABAP developer and needs to go through a strict set of testing cycles before being used in production. Not only do you need to make sure that the new code works as expected, you also (even more importantly) need to make sure that ’nothing else gets broken’ by the new code. You will need to employ experienced programmers and testers and you will have to deal with the expensive overhead that comes with making everyone at IT comfortable with your shiny new automation.

A development in ABAP is therefore going to require, even for an experienced programmer, an investment in both time and money.

But what if you just wanted to automate the clicking and the typing that a user performs on screen without adding any logic inside the SAP system?

In this case, Robotic Process Automation (RPA) comes to mind. RPA is a software that allows virtual ’Robots’ to interact with any application available on screen, much like a human does. RPA, unlike ABAP, can only interact with the GUI (Graphical User Interface – i.e. the SAP screen) so there is no risk of causing damage to your SAP system – at least, no more damage than a human end user could cause.

Figure 1: Example of a SAP GUI screen

RPA is perfect if you need to interact with multiple applications and it usually also comes packaged with a handy infrastructure that can take care of audit trails, monitoring dashboards, version control systems, logging systems, centralized credential management, licensing management and much more.

While this sounds very promising, in most cases you cannot automate SAP for free using RPA. Vendors of RPA provide free trials or even free-for-private-use ’community editions’, but in most cases you will still need to buy licenses to use RPA in production.

But what if you just wanted to automate the clicking and the typing that a user performs on screen, if you did not need to add any logic inside the SAP system? If you only wanted to interact with a handful of applications – let’s say SAP and Excel – and you were not interested in all the fancy extra features that come packaged with RPA?

In this case, you can use another tool called SAP GUI Scripting API. Just like with RPA, you can use the SAP GUI Scripting API to emulate the activities that the user would perform on the SAP GUI screen. You can even record the activities the user performs and use the automatically generated code as a starting point for your automation.

You can write scripts in your favorite language, but since Excel <-> SAP interaction is popular, you often see SAP GUI Scripting API being used in a VBA Macro in Excel. All you need to do is add the reference to the API in your VBA editor and you can then start programming which buttons you want to click, what you want to type or what you want to read from the SAP GUI.

Figure 2: Adding the reference to SAP Scripting API in the BVA Editor

And now the recurring question: can you automate SAP for free using SAP GUI Scripting API? Yes! If you have SAP GUI installed on your machine, you should already have access to the Scripting API. You do not need to purchase additional licenses (or wait for the long procurement process to take place).

Okay, SAP GUI Scripting API is free. But is it safe?

Yes, absolutely. Quoting the official SAP GUI Scripting Security Guide: “From the SAP server’s point of view there is no difference between SAP GUI communication generated by a script and SAP GUI communication generated by a user. For this reason, a script has the same rights to run SAP transactions and enter data as the user starting it. In addition, the same data verification rules are applied to data entered by a user and data entered by a script.”

In other words:

• A script cannot corrupt the SAP system’s data, because all changes done from a script are subject to the same data validation rules as end user interaction.
• An end user cannot use a script to access data they would not otherwise have the necessary privileges for. The script only has access to the data that the end user has the access rights for.
• A script cannot record passwords. A script cannot be played back if the user running it does not have an account on the SAP system.
• A script cannot be run in the background without the end user’s knowledge. By default, the end user will be notified when the scripting starts. Furthermore, the SAP GUI needs to be displayed when the script is running.

So, SAP GUI Scripting API is free and it is safe. But is it useful?
Yes, it is. We have used this technology extensively and we have saved ourselves and our clients thousands of hours of repetitive work. Recently, a custom Process Automation tool Zanders developed for British American Tobacco was chosen by the jury of treasurytoday magazine as the winner of the Best Fintech Solution – Adam Smith Award. This award-winning tool was built by leveraging the power of SAP GUI Scripting API.

The key advantage with the SAP GUI Scripting API is that you can use a native SAP functionality designed to allow end users (and not only experienced developers) to automate activities safely and effectively. The IT and procurement overhead is kept to the minimum, allowing you to efficiently avoid those repetitive clicking and typing kind of tasks (and the errors they cause) and to instead focus on what really matters.

Are you interested in knowing more on how you can use ABAP, RPA or SAP Scripting API to automate activities in SAP? Please contact Philip Costa Hibberd for more information.