This college consisted of a three-part webinar series, in which Zanders explained best practices on important topics in the world of corporate treasury and SAP elaborated on its latest offerings to support the processes with a focus on accelerated and cloud-based deployments.

If you were not able to attend, please find the recorded webinars here. Nevertheless, we now also offer you a short, written summary of what has been discussed.

Forecasting functionalities

The topic of the first webinar was ‘Cash management & cash flow forecasting’. Pieter Sermeus, senior manager at Zanders, explained the preparations needed before you can start daily short-term cash flow forecasting and executing cash management actions. Subsequently, he explained some approaches to prepare a cash flow forecast, whereby he made the distinction in the objective (cash management, hedging or funding) and the term of the forecast (short term, mid-term or long term). Thereafter, SAP’s Christian Mnich and Christian Schmid presented their SAP Cash Management solution. This module in S/4HANA provides support in bank account management, cash positioning and short-term cash flow forecasting, and can be deployed either on premise or in the cloud. Lastly, SAP elaborated on its Analytics Cloud solution, which offers the functionality to report and slice and dice. It also offers functionality in the workflow around collecting cash flow forecasts and the slicing and dicing of the forecasted and actual items.

Payment factory capabilities

The second webinar was on ‘Payment factory optimization’. Ivo Postma, senior manager at Zanders, elaborated on the payment factory process and the relation with various departments within an organization. In addition, different payment factory models (payment forwarding, payments on behalf of and collection on behalf of), connectivity options (SWIFT, cloud provider, host-to-host and e-banking) and cash management structures (zero balance cash pools and virtual accounts) have been discussed. Subsequently, Christian Schmid presented the cloud-based service SAP Multi-Bank Connectivity as well as dedicated payment factory capabilities supported by SAP In-House Cash and SAP Advanced Payment Management.

Process optimization

The topic of the third webinar was ‘Treasury process optimization’. Jonathan Tomlinson, senior manager at Zanders, provided an overview of financial risks managed by Treasury and explained why it is so important and complex to manage FX risk. Subsequently, the Zanders risk management framework was highlighted, including risk identification, risk measurement, policy and execution process issues. As part of the execution process, the whole deal life cycle was discussed. Lastly, Christian Schmid presented SAP’s Treasury and risk management module and the possibilities with its cloud-based Trading platform integration and Hedge management cockpit. Also, SAP Treasury analytics and reporting capabilities for risk management were addressed.

We are very pleased that over 200 professionals registered to the SAP Summer College and that we received positive reactions from the attendees – thank you!

In case you have any question regarding SAP functionalities or other above-mentioned topics, please do not hesitate to contact us.

Intraday Bank Statements offers a cash manager additional insight in estimated closing balances of external bank accounts and therefore provides the information to manage the cash more tightly on the company’s bank accounts.

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:
   A/CM payment advice: This needs to be enabled to ensure that SAP creates the memo record data from the intraday statements.
   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.
   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.
   D/ Account balance: This needs to be set if we are loading intraday statements.
4. 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.

Therefore, we decided to leverage our cloud-based solution and enable SAP users to determine the arm’s length interest rate with just a few clicks.

The pricing of various treasury transactions, as for all intercompany flows, is subject to transfer pricing regulation. In essence, treasury and tax professionals need to ensure that the pricing is in line with market conditions, i.e. the arm’s length principle. To this end, numerous Zanders clients use the Zanders Inside Transfer Pricing Solution (TPS). Our TPS enables them to set interest rates on intercompany transactions in a compliant and automated way. Since its go-live almost three years ago, clients have priced over 1000 intercompany loans with this self-service solution.

Our TPS has been a stand-alone tool on the Zanders Inside platform, but that is about to change. We have selected SAP as the first treasury management system for online integration. The interface uses APIs between the two systems to pull and push the relevant information. This article will elaborate on how the process flow is designed from an end user perspective.

Automated credit rating assessment

Initially, the necessary static data on the borrowing entities needs to be saved on the Zanders Inside platform. This data is used to determine an entity-specific credit rating, a requirement for a compliant transfer pricing assessment. This can be done via the Zanders Inside template, which gives the user a standard framework to capture the financial statements for all entities. Additionally, the user also saves qualitative rating information. Based on this information, the automated credit rating assessment is run in the background. The borrower credit rating will be used as input to the pricing assessment. This first step is the only manual process in the entire end-to-end flow. In addition, adjustments to the static data only need to occur once per year, i.e. when the new financial statements are published.

Overview

Once the static data is set up, the user enters an intercompany loan in the usual way. In the interest condition, the SAP user will indicate that the interest rate will be determined using the Zanders TPS platform. Using the SAP standard functionality, the user can define if the interest rate has to be updated via the Zanders TPS platform regularly or only initially at deal creation. Once the deal is created, the Zanders TPS cockpit offers an overview of all intercompany loans with outstanding pricing status. From this environment, the user can select the individual deals and raise a pricing request to the Zanders TPS platform. This pricing request will include identification of the lender and borrower, which impacts the rating, and the relevant terms and conditions of the loan, which impact the arm’s length interest rate.

Transferred values

Aside from the rating, the main drivers are the maturity of the loan, the structure of the facility (level of collateral), the currency and the repayment schedule. These values will be transferred into the Zanders Inside TPS. It enables the solution to operate as a calculation engine, i.e. making the necessary calculations in the background.

In the Zanders TPS cockpit, the user is offered the possibility to review the received interest rate and its constituting components. Given the background of the transaction, the user is free to decide which components will be included in the final rate. Additionally, a manual rate adjustment can be added as a separate component, together with an explanatory comment. The manual rate adjustment and its justification is transferred back to the Zanders TPS platform and will be included in the final pricing documentation.

Fully-fledged report

Finally, the output of the transfer pricing solution is twofold. In addition to pulling the interest rate components into SAP, it will automatically create a fully-fledged transfer pricing report. This report will automatically be saved in the solution and includes a reference towards the transaction identifier in SAP. The report contains the methodology as well as all specifics of the calculation and can be used as a reference document later on. This can be used should a tax audit occur, for example.

Determining the interest rate and entering it into the appropriate deal in a TMS system is often a manual and cumbersome process involving different departments. By connecting the Zanders Inside TPS to SAP, the level of straight-through processing (STP) within a treasury department can significantly improve. Additionally, it offers a less error-prone alternative as it removes manual data entry and calculations.

Free Demo

Would you like to learn more on this new initiative or receive a free demo of our solution? Do not hesitate to reach out!

Even though ERP systems automate most of the handling of accounting and financial activities, many of us still have the drive to seek even further for automation. Even the shortest routines that need to be carried out daily can become irritating and become source of avoidable errors. Wouldn’t it be nice to limit repetitive clicking and typing to the minimum and have more time to focus on what really matters? When looking into automating activities in SAP, the first idea might be to simply ’write a program’ to take care of executing the task at hand. But how can you automate SAP safely, successfully and for free?

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.

The importance and benefits of delivering a digital strategy for treasury operations are well understood. For many organizations, however, there is a significant barrier that may prevent them from being able to successfully implement. In this article, we discuss how to overcome that barrier, resulting in an accelerated process to achieve a true smart treasury function at lower overall cost.

As discussed in the recent joint-whitepaper from Zanders and Citi on the future of corporate treasury, both corporations and financial institutions should be focusing their attention on developing a digital treasury strategy. This is being driven by the increasing pace of regulatory change, continuously evolving business models, volatile economic conditions, fast-growing technological developments and the benefits of a strategically focused ‘smart treasury’ – one that utilizes the latest technology to be more integrated, automated and optimized, adding value to the business.

Although the benefits of going digital are well recognized at a company level, they are not at the treasury level – while two-thirds of respondents to a digital preparedness survey indicated their organizations are already engaged and experimenting with digital solutions, only 14% had a digital strategy in treasury.

Strategy void

We know the levels of adoption of a digital treasury strategy vary greatly between organizations – at the top end of the scale, a number of trailblazers have already developed theirs and are actively implementing, firmly on their way to achieving the smart treasury vision. These are normally financial institutions and large multinationals who utilize in-house technology teams containing a pool of resources dedicated to treasury technology and digital transformation. They may also have ample means to utilize external advisors to deliver on their behalf.

A void exists, however, comprised either of corporates that are yet to transform from traditional MS Excel-based methods to an ‘efficient treasury’ function, or those that have already traversed the transformation pathway but are unable to progress further to ‘smart’.

For those yet to progress to an ‘efficient’ function and realize the benefits of centralization, standardization and automation, getting the basics right is the first hurdle to overcome before digital transformation can be considered. To do this, they should look to select and implement a treasury management system (TMS) and, where appropriate, run a fully operational in-house bank and payment factory. However, in this scenario, the size and scale of their business makes it unlikely that in-house teams with the requisite knowledge and skills to do this exist, and the cost of external advisory projects can be prohibitive. Their barrier is one of having the right structure and resources in place.

For those that have already traversed the treasury transformation pathway and are experiencing the benefits of their new ‘efficient treasury’ function, such as improved cash management, reduced transaction costs, standardized processes and increasingly effective risk management, ‘smart treasury’ is the natural next step. But they also face similar significant barriers in developing and implementing their digital treasury strategy to those struggling to progress to ‘efficient’ – the lack of in-house teams and no budget for advisory projects. Once again, the issue of structure and resources is the barrier.

Progressing through efficient to smart

In our discussion of the aforementioned joint-whitepaper, Ron Chakravarti, Citi’s Global Head of Treasury Advisory, commented: “Today, more than ever, the treasury function needs to include people who are technologically savvy. People who are able to comprehend what is changing and how to best deploy technology… Treasury teams recognize that they need to have a digital strategy, but many of them are not fully equipped to define one.”

Looking more closely at the current team structure of corporates that struggle to achieve their efficient or smart aspirations, it is clear they either have difficulty in finding technologically savvy people, or this requirement is simply being overlooked. The ways that organizations try to respond to the resourcing challenge varies. Some choose to divide the role among existing team members, others merge the requirements into an existing role, and in some cases a dedicated treasury systems manager role is created.

However, none of these solutions are optimal, as to effectively deliver digital change the following niche set of ‘digital treasury’ skills are required:

1. Intricate knowledge of the business coupled with detailed working and technical knowledge of their treasury operations and a strong understanding of corporate treasury principles in general.
2. Well versed in the latest technologies on offer, and any future technology in the pipeline, that could be effectively utilized by the organization based on their current and future needs.
3. Practical experience of implementing and integrating a variety of new digital technologies, combined with strong general IT skills and awareness.

Finding the right resource in a niche market is a challenging one and finding a solution to overcome this becomes critical to moving forwards. We propose a way to remove this barrier and deliver a digital treasury strategy in a lean and cost-effective way, while opening the door to a multitude of further opportunities and benefits for your new ‘smart treasury’ function.

An alternative way to manage your treasury systems

The creation of a dedicated treasury systems manager role appears to be the best of the current solutions to the resourcing barrier, but in practice this is a difficult role to fill due to a trade-off between cost and experience. How can organizations find a senior resource not only with strong experience and understanding of treasury, but with excellent knowledge of the latest treasury technology trends, experience implementing them, and a network of other financial technology professionals on call to resolve issues and propose new ways of working?

One solution may be to form a treasury technology partnership with a third-party, who will assume all day-to-day treasury systems management tasks while defining and delivering the digital treasury strategy. This suggestion is not the costly advisory solution previously mentioned that can be prohibitive for corporates struggling to transform. Contrary to expectations, there are savings to be made and other significant benefits to be enjoyed when a treasury technology partnership is compared to employing a dedicated treasury systems manager.

Treasury technology partnership benefits

Cost reduction – your partner will be able to perform the day-to-day treasury systems management service at lower cost than an in-house treasury systems manager. This is because it can be delivered by a pool of dedicated systems admin staff, allowing the benefits from economies of scale to be realized. The quality of service would also improve based on the collective knowledge of the partner, who will also be managing the same systems for other clients.

Accelerated strategy – your partner will be uniquely placed to define and deliver your digital strategy quicker than can be achieved by the treasury team or a stand-alone systems manager. They would be able to achieve this by applying extensive company-specific knowledge gained during the partnership, along with their awareness and experience of the latest technology. They will already have solutions for common treasury issues and will be supported by their in-house team of treasury technology professionals.

Additionally, the accelerated strategy could be delivered at a lower cost than any discrete transformation advisory project, as the technology partner would benefit from already having a strong understanding of your business’s strategic and technical requirements. Time spent on scoping would be vastly reduced.

Ad-hoc – for similar reasons to the accelerated strategy, the treasury technology partner would also be able to deliver ad-hoc projects at a much more reasonable cost than engaging in an advisory project. Tasks such as systems selections, technical changes required by regulatory changes, market reform or adjustments in generally accepted best practice, could be delivered swiftly as the technology partner would already be experienced in delivering these for other customers, while also being aware of your specific technical requirements.

Exponential technology – the use of a treasury technology partner will open up the possibility of always being able to deploy the latest technology. For example, Zanders are already experienced in delivering technological improvements utilizing robotic process automation (RPA), machine learning (ML), artificial intelligence (AI), external and internal APIs, custom applications/middleware, and a multitude of other exponential technologies. The technology partner will already be experienced in the design, implementation and use of these with their other clients, and will bring significant experience in how to deliver these, in conjunction with their understanding of your organization’s strategic and technical requirements.

Summary

Zanders has a wealth of experience in this field with numerous awards and recognitions for our technological solutions, and already performs similar services for several organizations. Entering into a Zanders Treasury Technology Partnership to deliver your first steps to an efficient treasury, perform day-to-day systems admin tasks, and develop and implement the digital treasury strategy, is an ideal solution for those corporates lacking the appropriate resources to move from ‘efficient’ to ‘smart’.

Moreover, it gives an organization access to a pool of treasury professionals at all levels of seniority, to continuously benefit from their collective experience and skills. This expertise is available at a lower cost than the alternative of employing an in-house treasury systems manager or engaging in advisory projects. For cases where the current systems admin tasks are merged into one or several existing roles, it will allow core treasury team members to focus on treasury management by removing the burden of systems management placed upon them, while also improving the quality of the systems management service.

Finally, it opens up the possibility of greater use of a multitude of exponential technologies, all resulting in cost savings, increased operational efficiencies, improved risk management, and a technology landscape that is scalable and rapidly deployable. This will ensure you achieve your smart treasury vision for a function that is well placed to support your business going forward.

In our previous article, the reasons for a new reference rate (SARON) as an alternative to CHF LIBOR were explained and the differences between the two were assessed. One of the challenges in the transition to SARON, relates to the compounding technique that can be used in banking products and other financial instruments. In this article the challenges of compounding techniques will be assessed.

The end of 2021 remains as a key deadline after which the Financial Conduct Authority (FCA) will no longer require banks to submit rates to be used for the calculation of IBOR based reference rates. While regulatory uncertainties and differences between currencies and jurisdictions persist, corporates should have arranged and executed an IBOR transition plan to renegotiate existing contracts, update valuations and financial models, implement new accounting and hedge accounting guidance, and upgrade technology solutions before the end of 2021.

In the Treasury technology space, system providers are already announcing development roadmaps and implementation plans.

In June 2020, SAP announced their development strategy and roadmap for supporting system developments arising from IBOR reform. In addition to developing the additional functionality in S/4HANA, SAP will be down-porting IBOR functionality to ECC EHP8 systems. The first parts of SAP’s release are expected in July 2020 and corporates are encouraged to incorporate SAP’s latest roadmap announcement into their transition plans.

For more information relating to SAP’s roadmap, please see their announcement here or contact Constantine Tyraskis on +44 20 7730 2510.

Are you interested in how these can help your Treasury and how to implement them in SAP? Look no further; in this article we will guide you through the first steps of virtual accounts in SAP.

What are virtual bank accounts?

In its most basic form, a virtual bank account can be described as a bank account number towards which a payment can be initiated, but where ultimately the credit is going to happen on a “real” bank account. It is a service that is mostly associated with a concept called “Collections on behalf”.

“Virtual account” (VA) is a product that is continuously developed by the global cash management banks. Within the product of virtual accounts, there are many variants and sub-services that a bank could support. Some examples:

1. Multitiered virtual accounts: It is possible to create and assign VA’s to i.e. the level of your operating company. On the other hand, to make collections reconciliation more efficient, the bank could offer the possibility to setup a VA that is assigned to one unique trade customer. Any receipt hitting this VA will then be logically and uniquely linkable to that particular trade customer.
2. Virtual sweeping: If line by line crediting into the master account is not desired, a bank could setup a virtual sweep that sweeps the individual credits from the virtual account into the master account in bulk.
3. Separate virtual account bank statement reporting: A separate bank statement could be prepared on the VA level that reports only the debits and credits that hit that VA.
4. Cross border virtual accounts: VA’s could be setup in a different country then where the master account is held.
5. Intercompany position ledger services: Some banks also provide an additional service to record the intercompany positions that arise from the VA movements into the master account movement and reports on it through i.e. an electronic banking platform. Otherwise such IC position mutations need to be managed in the ERP systems of the company on a daily basis.

In the most typical way, a virtual account structure is setup as follows;

1. The real bank account is held by the treasury entity
2. The virtual account is assigned to the operating entity
3. The customers of the operating company will settle trade invoices by making a payment into the virtual account
4. The bank will apply the cash credit from the VA into the master account, for the benefit of the treasury entity
5. The treasury entity and operating company will need to account for this transaction by maintaining an intercompany position.
6. The operating company can clear off its outstanding invoice against the IC position increase.
7. The treasury company can counter the cash increase against the IC position decrease.

Business Rationale behind Virtual Accounts

So why would a treasury typically start implementing virtual accounts in their cash management processes?

Cash centralization: Cash centralization is ultimately the main goal of implementing any liquidity structure and virtual accounts are an excellent in supporting automatic processes to centralize cash to i.e. the treasury entity.

Centralized bank relationship management (and improved negotiating position): By implementing a centrally coordinated liquidity structure, the relationship with the bank can be centrally managed and negotiation position becomes a bit stronger.

Centralized bank connectivity: By implementing a centrally coordinated liquidity structure, bank connectivity can be centralized as well, bringing further reductions in IT costs.

Daylight overdraft facility requirement reduction: Where a zero-balance type of liquidity structure typically brings the funds into the master account after EOD, for any payments made throughout the day being executed over the master account, need to be funded through i.e. a daylight overdraft facility. By employing a virtual account structure on the other hand, the collections will be credited on the master account throughout the day, effectively funding your master account.

Intraday cash balance reporting: in a virtual account setup, as the credits flow in throughout the day on the master account, it becomes feasible to better estimate EOD balances from intraday statement reporting

Reduction of required bank accounts and associated costs: Depending on the bank and country requirements, typically opening a virtual account requires less effort in terms of KYC, contract work and suchlike, as compared to opening up a real account and hanging the account in the liquidity structure through i.e. a zero balancing agreement.

Reduction of vendor confusion: In a more classical Payment factory/Payment on own Behalf (POBO) model where a centralized Treasury entity executes payments on behalf of its operating companies, it is an often heard complaint of the beneficiaries of payments (i.e. trade vendors) that it is unclear that a payment originated from the operating company, causing issues in their reconciliation processes. Executing POBO through a virtual account attempts to remedy this.

This is the first part of a series on how to set up virtual accounts in SAP. Click here to read the second part, on Virtual Accounts Concepts.