Exploring S/4HANA Functionalities 

The roundtable session started off with the presentation of SAP on some of the new S/4HANA functionalities. New functionalities in the areas of Cash Management, Financial Risk Management, Working Capital Management and Payments were presented and discussed. In the area of Cash Management, the main enhancements can be found in the management of bank relationships, managing cash operations, cash positioning, and liquidity forecasting and planning. These enhancements provide greater visibility into bank accounts and cash positions, a more controlled liquidity planning process across the organization, increased automation, and better execution of working capital strategies. In Financial Risk Management, the discussion highlighted S/4HANA’s support for smart trading processes, built-in market data integration, and more advanced on-the-fly analysis capabilities. All providing companies with a more touchless, automated and straight through process of their risk management process. The session also covered Working Capital enhancements, including a presentation on the Taulia solution offered by SAP, which provides insights into supporting Payables and Receivables Financing. Finally, the session explored innovations in the Payments area, such as payment verification against sanction lists, format mapping tools, the SAP Digital Payments Add-on, and automated corporate-to-bank cloud connectivity. 

Migration Strategies: Getting to S/4HANA 

While the potential of S/4HANA was impressive, the focus shifted to migration strategies. Zanders presented various options for transitioning from an ECC setup to an S/4HANA environment, sparking a lively discussion. Four use cases were defined, reflecting the diverse architectural setups in companies. These setups include: 

• An integrated architecture, where the SAP Treasury solution is embedded within the SAP ERP system 

• A treasury sidecar approach, where the SAP Treasury solution operates on a separate box and needs to integrate with the SAP ERP system box 

• Treasury & Cash & Banking side car 

• Leveraging Treasury on an S/4HANA Central Finance box 

The discussion also covered two key migration strategies: the brownfield approach and the greenfield approach. In a brownfield approach, the existing system setup is technically upgraded to the new version, allowing companies to implement S/4HANA enhancements incrementally. In contrast, a greenfield approach involves building a new system from scratch. While companies can reuse elements of their ECC-based SAP Treasury implementation, starting fresh allows them to fully leverage S/4HANA’s standard functionalities without legacy constraints. However, the greenfield approach requires careful planning for data migration and testing, as legacy data must be transferred to the new environment. 

Decoupling Treasury: The Sidecar Approach 

The greenfield approach also raised the question of whether treasury activities should migrate to S/4HANA first using a sidecar system. This would involve decoupling treasury from the integrated ECC setup and transitioning to a dedicated S/4HANA sidecar system. This approach allows treasury to access new S/4HANA functionalities ahead of the rest of the organization, which can be beneficial if immediate enhancements are required. However, this setup comes with challenges, including increased system maintenance complexity, additional costs, and the need to establish new interfaces. 

However, this setup comes with challenges, including increased system maintenance complexity, additional costs, and the need to establish new interfaces. Companies need to weigh the benefits of an early treasury migration against these potential drawbacks as part of their overall S/4HANA strategy. With this consideration in mind, participants reflected on the broader lessons from companies already using S/4HANA. 

Lessons from Early Adopters 

Companies that have already migrated to S/4HANA emphasized two critical planning areas: testing and training. Extensive testing—ideally automated—should be prioritized, especially for diverse payment processes. Similarly, training is essential to ensure effective change management, reducing potential issues after migration. 

These insights highlight the importance of preparation in achieving a smooth migration. As organizations transition to S/4HANA, another important consideration is the potential impact on the roles and responsibilities within treasury teams. 

Impact on Treasury Roles 

Participants discussed whether S/4HANA would alter roles and responsibilities within treasury departments. The consensus was that significant changes are unlikely, particularly in a brownfield approach. Even in a greenfield approach, roles and responsibilities are expected to remain largely unchanged. 

Conclusion

The roundtable highlighted the significant value S/4HANA brings to treasury operations, particularly through enhanced functionalities in Cash Management, Financial Risk Management, Working Capital Management, and Payments.

Participants discussed the pros and cons of brownfield and greenfield migration strategies, with insights into the sidecar approach for treasury as a potential transitional strategy. Early adopters emphasized the critical importance of thorough testing and training for a successful migration, while noting that treasury roles and responsibilities are unlikely to see major changes 

If you would like to hear more about the details of the discussion, please reach out to Laura Koekkoek, Partner at Zanders, l.koekkoek@zandersgroup.com 

Banks perform data analytics, statistical modelling, and automate financial processes using model software, making model software essential for financial risk management. 

Why banks are recently moving their model software to open-source¹: 

• Volume dependent costs: Open-source comes with flexible storage space and computation power and corresponding costs and capacity.  
• Popularity: Graduates are often trained in open-source software, whereas the pool of skilled professionals in some specific software is decreasing. 
• Customization: You can tailor it exactly to your own needs. Nothing more, nothing less. 
• Collaboration: Required level of version control and collaboration with other software available within the bank. 
• Performance: Customization and flexibility allow for enhanced performance. 

Often there is a need to reconsider the model software solution the Bank is using; open-source solutions are cost effective and can be set up in such a way that both internal and external (e.g. regulatory) requirements are satisfied. 

How Zanders can support in moving to open-source model software. 

Proper implementation of open-source model software is compliant with regulation.   

• Replication of historical situations is possible via version control, containerization and release notes within the open-source model software. Allowing third parties to replicate historical model outcomes and model development steps.   
• Governance setup via open-source ensures that everything is auditable and is released in a governed way; this can be done through releases pipelines and by setting roles and responsibilities for software users.  
• This ensures that the model goes from development to production only after governed review and approval by the correct stakeholders.  

Migration to open-source software is achievable. 

• The open-source model software is first implemented including governance (release processes and roles and responsibilities).  
• Then all current (data and) models are refactored from the current model software to the new one.  
• Only after an extensive period of successful (shadow) testing the migration to the new model software is completed.  

Zanders has a wealth of experience performing these exercises at several major banks, often in parallel to (or combined with) model change projects. Hence, if you have interest, we will be happy to share some further insights into our latest experiences/solutions in this specific area.  

Therefore, we welcome you to reach out to Ward Broeders (Senior Manager).

The CLS system was established back in 2002 and since then, the FX market has grown significantly. Therefore, there is a high demand from corporates to leverage CLS to improve corporate treasury efficiency.

In this article we shed some light on the possible technical solutions in SAP Treasury to implement CLS in the corporate treasury operations. This includes CLS deal capture, limit utilization implications in Credit risk analyzer, and changes in the correspondence framework of SAP TRM.

Technical solution in SAP Treasury
There is no SAP standard solution for CLS as such. However, SAP standard functionality can be used to cover major parts of the CLS solution. The solution may vary depending on the existing functionality for hedge management/accounting and limit management as well as the technical landscape accounting for SAP version and SWIFT connectivity.

Below is a simplified workflow of CLS deal processing:

The proposed solution may be applicable for a corporate using SAP TRM (ECC to S/4HANA), having Credit risk analyzer activated and using SWIFT connection for connectivity with the banks.

Capturing CLS FX deals
There are a few options on how to register the FX deal as a CLS deal, with two described below:

Option 1: CLS Business partner – a replica of your usual business partner (BP) which would have CLS BIC code and complete settlement instructions.
Option 2: CLS FX product type/transaction type – a replica of normal FX SPOT, FX FORWARD or FX SWAP product type/transaction type.

Each option has pros and cons and may be applied as per a client technical specific.

FX deals trading and capturing may be executed via SAP Trade Platform Integration (TPI), which would improve the processing efficiency, but development may still be required depending on characteristics of the scope of FX dealing. In particular, the currency, product type, counterparty scope and volume of transactions would drive whether additional development is required, or whether standard mapping logic can be used to isolate CLS deals.

For the scenarios where a custom solution is required to convert standard FX deals into CLS FX deals during its creation, a custom program could be created that includes an additional mapping table to help SAP determine CLS eligible deals. The bespoke mapping table could help identify CLS eligibility based on the below characteristics:

• Counterparty
• Currency Pair
• Product Type (Spot, Forward, SWAP)

Correspondence framework
Once CLS deal is captured in SAP TRM, it needs to be counter-confirmed with the trading counterparty and with CLS Bank. Three new types of correspondence need to be configured:

• MT300 with CLS specifics to be used to communicate with the trading counterparty;
• MT304 to communicate with CLS Custody service;
• SWIFT MT396 to get the matching status from CLS bank.

Credit Risk Analyzer (CRA)
FX CLS deals do not bring settlement exposure, thus CLS deals need to be exempt from the settlement risk utilization. Configuration of the limit characteristics must include either business partner number (for CLS Business Partner) or transaction type (for CLS transaction type). This will help determine the limits without FX CLS deals.

No automatic limits creation should be allowed for the respective limit type; this will disable a settlement limit creation based on CLS deal capture in SAP.
CLS Business partner setting must be done with ‘parent <-> subsidiary’ relationship with the regular business partner. This is required to keep a single credit limit utilization and having FX deals being done with two business partners.

Deal execution
Accounting for CLS FX deals is normally the same as for regular FX deals, though it depends on the corporate requirements. We do not see any need for a separate FX unrealized result treatment for CLS deals.

However, settlement of CLS deals is different and standard settlement instructions of CLS deals vary from normal FX deals.

Either the bank’s virtual accounts or separate house bank accounts are opened to settle CLS FX deals.

Since CLS partner performs the net settlement on-behalf of a corporate there is no need to generate payment request for every CLS deal separately. Posting to the bank’s CLS clearing account with cash flow postings (TBB1) is sufficient at this level.

The following day the bank statement will clear the postings on the CLS settlement account on a net basis based on the total amount and posting date.

Cash Management
A liquidity manager needs to know the net result of the CLS deals in advance to replenish the CLS bank account in case the net settlement amount for CLS deal is negative. In addition, the funds would need to be transmitted between the house bank accounts either manually or automatically, with cash concentration requiring transparency on the projected cash position.

The solution may require extra settings in the cash management module with CLS bank accounts to be added to specific groupings.

Conclusion
Designing a CLS solution in SAP requires deep understanding of a client’s treasury operations, bank account structure and SAP TMS specifics. Together with a client and based on the unique business landscape, we review the pros and cons of possible solutions and help choosing the best one. Eventually we can design and implement a solution that makes treasury operations more efficient and transparent.

Our corporate clients are requesting our support with design and implementation of Continuous Linked Settlement (CLS) solutions for FX settlements in their SAP Treasury system. If you are interested, please do not hesitate to contact us.