As organizations continue to adapt to the rapidly changing business landscape, one of the most pivotal shifts is the migration of enterprise resource planning (ERP) systems to the cloud. The evolution of treasury operations is a prime example of how cloud-based solutions are revolutionizing the way businesses manage their financial assets. This article dives into the nuances between SAP’s GROW (public cloud) and RISE (private cloud) products, particularly focusing on their impact on treasury operations. 

The "GROW" product targets new clients who want to quickly leverage the public cloud's scalability and standard processes. In contrast, the "RISE" product is designed for existing SAP clients aiming to migrate their current systems efficiently into the private cloud. 

Public Cloud vs. Private Cloud 

The public cloud, exemplified by SAP's "GROW" package, operates on a shared infrastructure hosted by providers such as SAP, Alibaba, or AWS. Public cloud services are scalable, reliable, and flexible, offering key business applications and storage managed by the cloud service providers. Upgrades are mandatory and occur on a six-month release cycle. All configuration is conducted through SAP Fiori, making this solution particularly appealing to upper mid-market net new customers seeking to operate using industry-standard processes and maintain scalable operations. 

In contrast, the private cloud model, exemplified by the “RISE” package, is used exclusively by a single business or organization and must be hosted at SAP or an SAP-approved hyperscaler of their choice. The private cloud offers enhanced control and security, catering to specific business needs with personalized services and infrastructure according to customer preferences. It provides configuration flexibility through both SAP Fiori and the SAP GUI. This solution is mostly preferred by large enterprises, and many customers are moving from ECC to S/4HANA due to its customizability and heightened security. 

Key Differences in Cloud Approaches 

Distinguishing between public and private cloud methodologies involves examining factors like control, cost, security, scalability, upgrades, configuration & customization, and migration. Each factor plays a crucial role in determining which cloud strategy aligns with an organization's vision for treasury operations. 

1. Control: The private cloud model emphasizes control, giving organizations exclusive command over security and data configurations. The public cloud is managed by external providers, offering less control but relieving the organization from day-to-day cloud management. 
2. Cost: Both the public and private cloud operate on a subscription model. However, managing a private cloud infrastructure requires significant upfront investment and a dedicated IT team for ongoing maintenance, updates, and monitoring, making it a time-consuming and resource-intensive option. Making the public cloud potentially a more cost-effective option for organizations. 
3. Security: Both GROW and RISE are hosted by SAP or hyperscalers, offering strong security measures. There is no significant difference in security levels between the two models. 
4. Scalability: The public cloud offers unmatched scalability, allowing businesses to respond quickly to increased demands without the need for physical hardware changes. Private clouds can also be scaled, but this usually requires additional hardware or software and IT support, making them less dynamic. 
5. Upgrades: the public cloud requires mandatory upgrades every six months, whereas the private cloud allows organizations to dictate the cadence of system updates, such as opting for upgrades every five years or as needed. 
6. Configuration and Customization: in the public cloud configuration is more limited with fewer BAdIs and APIs available, and no modifications allowed. The private cloud allows for extensive configuration through IMG and permits SAP code modification, providing greater flexibility and control. 
7. Migration: the public cloud supports only greenfield implementation, which means only current positions can be migrated, not historical transactions. The private cloud offers migration programs from ECC, allowing historical data to be transferred. 

Impact on Treasury Operations 

The impact of SAP’s GROW (public cloud) and RISE (private cloud) solutions on treasury operations largely hinges on the degree of tailoring required by an organization’s treasury processes. If your treasury processes require minimal or no tailoring, both public and private cloud options could be suitable. However, if your treasury processes are tailored and structured around specific needs, only the private cloud remains a viable option.

In the private cloud, you can add custom code, modify SAP code, and access a wider range of configuration options, providing greater flexibility and control. In contrast, the public cloud does not allow for SAP code modification but does offer limited custom code through cloud BADI and extensibility. Additionally, the public cloud emphasizes efficiency and user accessibility through a unified interface (SAP Fiori), simplifying setup with self-service elements and expert oversight. The private cloud, on the other hand, employs a detailed system customization approach (using SAP Fiori & GUI), appealing to companies seeking granular control. 

Another important consideration is the mandatory upgrades in the public cloud every six months, requiring you to test SAP functionalities for each activated scope item where an update has occurred, which could be strenuous. The advantage is that your system will always run on the latest functionality. This is not the case in the private cloud, where you have more control over system updates. With the private cloud, organizations can dictate the cadence of system updates (e.g., opting for yearly upgrades), the type of updates (e.g., focusing on security patches or functional upgrades), and the level of updates (e.g., maintaining the system one level below the latest is often used). 

To accurately assess the impact on your treasury activities, consider the current stage of your company's lifecycle and identify where and when customization is needed for your treasury operations. For example, legacy companies with entrenched processes may find the rigidity of public cloud functionality challenging. In contrast, new companies without established processes can greatly benefit  from the pre-delivered set of best practices in the public cloud, providing an excellent starting point to accelerate implementation. 

Factors Influencing Choices 

Organizations choose between public and private cloud options based on factors like size, compliance, operational complexity, and the degree of entrenched processes. Larger companies may prefer private clouds for enhanced security and customization capabilities. Startups to mid-size enterprises may favor the flexibility and cost-effectiveness of public clouds during rapid growth. Additionally, companies might opt for a hybrid approach, incorporating elements of both cloud models. For instance, a Treasury Sidecar might be deployed on the public cloud to leverage scalability and innovation while maintaining the main ERP system on-premise or on the private cloud for greater control and customization. This hybrid strategy allows organizations to tailor their infrastructure to meet specific operational needs while maximizing the advantages of both cloud environments. 

Conclusion 

Migrating ERP systems to the cloud can significantly enhance treasury operations with distinct options through SAP's public and private cloud solutions. Public clouds offer scalable, cost-effective solutions ideal for medium-to upper-medium-market enterprises with standard processes or without pre-existing processes. They emphasize efficiency, user accessibility, and mandatory upgrades every six months. In contrast, private clouds provide enhanced control, security, and customization, catering to larger enterprises with specific regulatory needs and the ability to modify SAP code. 

Choosing the right cloud model for treasury operations depends on an organization's current and future customization needs. If minimal customization is required, either option could be suitable. However, for customized treasury processes, the private cloud is preferable. The decision should consider the company's lifecycle stage, with public clouds favoring rapid growth and cost efficiency and private clouds offering long-term control and security.

It is also important to note that SAP continues to offer on-premise solutions for organizations that require or prefer traditional deployment methods. This article focuses on cloud solutions, but on-premises remains a viable option for businesses that prioritize complete control over their infrastructure and have the necessary resources to manage it independently.

If you need help thinking through your decision, we at Zanders would be happy to assist you. 

SWIFT now supports the exchange of ISO 20022 XML or MX message via the so-called FINplus network. In parallel, the legacy MT format messages remain to be exchanged over the ‘regular’ FIN network; The MT flow for message categories 1 (customer payments), 2 (FI transfers) and 9 (statements) through the FIN network will be decommissioned per November 2025. 

As such, between March 2023 and November 2025, financial institutions need to be able to receive and process MX messages through FINplus on the inbound side, and optionally send MX messages or MT messages for outbound messaging. After that period, only MX will be allowed.  

CBPR+ and HVPS+ 

Another important aspect of the MX migration is the development of the CBPR+ and HVPS+ specifications within the ISO20022 XML standard. These specifications dictate how an XML message should be populated in terms of data and field requirements for Cross Border Payments (CBPR+) and Domestic High Value Payments (HVPS+). Note that HVPS+ refers to domestic RTGS clearing systems and a number of countries are in the process of making the domestic clearing systems native ISO20022 XML-compliant.  

Impact for Corporates 

As of today, there should be no immediate need for corporates to change. However, it is advised to start assessing impact and to start planning for change if needed. We give you some cases to consider: 

1. A corporate currently exchanging e.g. MT101/MT103/MT210 messages towards its house bank via SWIFT FIN Network to make cross border payments, e.g. employing a SWIFT Service Bureau or an Alliance connection. This flow will cease to work after November 2025. If this flow is relevant to your company, it needs attention to be replaced. 
2. Another case is where, for example, an MT101 is exchanged with a house bank as a file over the FileAct network. Now it depends purely on the house bank’s capabilities to continue supporting this flow after 2025; it could offer a service to do a remapping of your MT message into an MX. This needs to be checked with the house banks. 
3. The MT940 message flow from the house bank via FIN also requires replacement. 
4. With respect to the MT940 file flow from house bank via FileAct, we expect little impact as we think most banks will continue supporting the MT940 format exchange as files. We do recommend to check with your house bank to be sure. 
5. High Value Payments for Domestic Japanese Yen using Zengin format; the BOJ-NET RTGS clearing system has already completed the migration to ISO20022 XML standard. Check with your house bank when the legacy payment format will become unsupported and take action accordingly.  

These were just some examples and should not be considered an exhaustive list.  

In addition, moving to the ISO20022 XML standard can also provide some softer benefits. We discussed this in a previously published article. 

Impact on your SAP implementation 

So you have determined that the MT/MX migration has impact and that remediating actions need to be taken. What does that look like in SAP? 

First of all, it is very important to onboard the bank to support you with your change. Most typically, the bank needs to prepare its systems to be able to receive a new payment file format from your end. It is good practice to first test the payment file formatting and receive feedback from the banks implementation manager before going live with it.  

On the incoming side, it is advisable to first request a number of production bank statements in e.g. the new CAMT.053 format, which can be analyzed and loaded in your test system. This will form a good basis for understanding the changes needed in bank statement posting logic in the SAP system.  

PAYMENTS 

In general, there are two ways of generating payment files in SAP. The classical one is via a payment method linked to a Payment Medium Workbench (PMW) format and a Data Medium Exchange (DME) tree. This payment method is then linked to your open items which can be processed with the payment run. The payment run then outputs the files as determined in your DME tree. 

In this scenario, the idea is to simply setup a new payment method and link it to a desired PMW/DME output like pain.001.001.03. These have long been pre-delivered in standard SAP, in both ECC and S/4. It may be necessary to make minor mapping corrections to meet country- or bank-specific data requirements. Under most circumstances this can be achieved with a functional consultant using DME configuration. Once the payment method is fully configured, it can be linked to your customer and vendor master records or your treasury business partners, for example. 

The new method of generating payment files is via the Advanced Payment Management (SAP APM) module. SAP APM is a module that facilitates the concepts of centralizing payments for your whole group in a so-called payment factory. APM is a module that’s only available in S/4 and is pushed by SAP AG as the new way of implementing payment factories. 

Here it is a matter of linking the new output format to your applicable scenario or ‘payment route’.  

BANK STATEMENTS 

Classical MT940 bank statements are read by SAP using ABAP logic. The code interprets the information that is stored in the file and saves parts of it to internal database tables. The stored internal data is then interpreted a second time to determine how the posting and clearing of open items will take place. 

Processing of CAMT.053 works a bit differently, interpreting the data from the file by a so-called XSLT transformation. This XSLT transformation is a configurable mapping where a CAMT.053 field maps into an internal database table field. SAP has a standard XSLT transformation package that is fairly capable for most use cases. However, certain pieces of useful information in the CAMT.053 may be ignored by SAP. An adjustment to the XSLT transformation can be added to ensure the data is picked up and made available for further interpretation by the system. 

Another fact to be aware of is the difference in Bank Transaction Codes (BTC) between MT940 and CAMT.053. There could be a different level of granularity and the naming convention is different. BTC codes are the main differentiator in SAP to control posting logic.  

SAP Incoming File Mapping Engine (IFME) 

SAP has also put forward a module called Incoming File Mapping Engine (IFME). It serves the purpose as a ‘remapper’ of one output format to another output format. As an example, if your current payment method outputs an MT101, the remapper can take the pieces of information from the MT101 and save it in a pain.001 XML file.  

Although there may be some fringe scenarios for this solution, we do not recommend such an approach as MT101 is generally weaker in terms of data structure and content than XML. Mapping it into some other format will not solve the problems that MT101 has in general. It is much better to directly generate the appropriate format from the internal SAP data directly to ensure maximum richness and structure. However, this should be considered as a last resort or if the solution is temporary. 

As the first conference in the US since its 4-year hiatus, there was good attendance among corporates and partners. The SAP Treasury conference is an excellent opportunity for customers to see the latest developments within the S/4 HANA Treasury suite.  

Christian Mnich, VP and Head of Solution Management Treasury and Working Capital Management at SAP, gave the opening keynote titled: "SAP Opening Keynote: Increase Financial Resiliency with SAP Treasury and Working Capital Management Solutions." 

 Corporate Structure changes  

Ronda De Groodt, Applications Integration Architect at Leprino Foods, presented a case study that covered how Leprino Foods embarked on a company-wide migration from SAP ECC to S/4HANA, specifically implementing SAP Treasury, Cash Management, and Payments solutions in a 6-month time frame. The presentation also had a focus on leveraging SAP S/4HANA Cash Management and SAP machine learning capabilities while migrating to S/4 HANA. 

Trading Platform Integration 

 In a joint presentation, Justin Brimfield from ICD and Jonathon Kluding from SAP discussed the strategic partnership between the two companies in developing a streamlined Trading Platform Integration. This presentation went into detail on how SAP leverages Trading Platform Integration between SAP and ICD and the efficiencies this integration can create for Treasury. 

 Multi-Bank Connectivity (MBC) 

Another area of focus at the conference was the capabilities of SAP Multi-Bank Connectivity and how it can simplify and automate financial processes associated while having multiple banks. This was presented by Kweku Biney-Assan from HanesBrands. The presentation focused on answering some crucial questions corporates may have about SAP MBC, ranging from the possible improvements MBC can make to your Treasury Operations and Cash Management processes, to the typical timeline for an implementation. 

 Cash Management & Liquidity Forecasting 

Renee Fan from Freeport LNG, gave a presentation overviewing the challenges the company faced in terms of cash management, reporting, and analytics. She gave an overview of Freeport LNG’s Treasury Transformation Journey and insights into the upgrades they had made, as well as a further focus on the benefits they have seen as a result of their new cash and liquidity solution. 

In addition, the conference offered attendees the opportunity to share ideas, build networks, and discuss topics face-to-face. All this made this edition of the event a success!

The SAP Business Technology Platform (BTP) is not just a standalone product or a conventional module within SAP's suite of ERP systems; rather, it serves as a strategic platform from SAP, serving as the foundational underpinning for all company-wide innovations. In this article, we will delve deeper into some of the key offerings of SAP BTP for treasury and explore how it can contribute to driving innovation within treasury. 

The platform is designed to offer a versatile array of tools and services, aiming to enhance, extend, and seamlessly integrate with your existing SAP systems and other applications. Ultimately enabling a more efficient realization of your business objectives, delivering enhanced operational efficacy and flexibility. 

Analytics and AI 

One of the standout features of SAP BTP for treasury is its analytics and planning solution, SAP Analytics Cloud (SAC). This feature seamlessly connects with different data sources and other SAP applications. It supports Extended Planning & Analysis and Predictive Planning using machine learning models.  

At the core of SAC, various planning areas – like finance, supply chain, and workforce – are combined into a cloud-based interconnected plan. This plan is based on a single version of the truth, bringing planning content together. Enhanced by predictive AI and ML models, the plan achieves more accurate forecasting and supports near-real-time planning. Users can also compare different scenarios and perform what-if analysis to evaluate the impact of changes on the plan equipping organizations to prepare for uncertainties effectively. 

Application Development and Integration 

An organization's treasury architecture landscape often involves numerous systems, custom applications, and enhancements. However, this complexity can result in challenges related to maintenance, technical debt, and operational efficiency. 

Addressing these challenges, SAP BTP offers a solution known as the SAP Build apps tool. The tool enables users to adapt standard functionalities and create custom business applications through intuitive no-code/low-code tools. This allows that all custom development takes place outside your SAP ERP system, thereby preserving a ‘clean core’ of your SAP system. This will allow for a simpler, more streamlined maintenance process and a reduced risk of compatibility issues when upgrading to newer versions of SAP. 

In addition, SAP BTP facilitates seamless connectivity through a range of connectors and APIs integrated within the SAP Integration Suite. Enabling a harmonious integration of data and processes across diverse systems and applications, whether they are on-premise or cloud-based. 

Process Automation and Workflow Management 

Efficient process automation and workflow management play a pivotal role in enhancing treasury operations. SAP BTP offers an efficient solution named SAP Build Process Automation which enables users to design and oversee business processes using either low-code or no-code methods. It combines workflow management, robotic process automation, decision management, process visibility, and AI capabilities, all consolidated within a user-friendly interface.  

A significant advantage of SAP BTP's  workflow approach over conventional SAP workflows is the unification of workflows across diverse systems, including non-SAP systems and increased flexibility, enabling smoother interaction between processes and systems. 

The integration of SAP BTP for workflow with different SAP modules such as TRM, IHC, BAM is facilitated through the SAP Workflow Management APIs within your SAP S/4 HANA system. 

In the context of treasury functions, SAP Build Process Automation proves invaluable for automating and refining diverse processes such as cash management, risk management, liquidity planning, payment processing, and reporting. For instance, users can leverage the integrated AI functionalities for tasks like collecting bank statements/account balance information from different systems, consolidating information, saving and/or distributing the cash position information to the appropriate people and systems. Furthermore, the automation recorder can be employed to mechanize the extraction and input of data from diverse systems. Finally, the SAP Build Process Automation can also be utilized to create workflows for complex payment approval scenarios, including exceptions and escalations. 

Extensions to the Treasury Ecosystem 

SAP BTP extends the treasury ecosystem with multiple treasury-specific developed solutions, seamlessly enhancing your treasury SAP S/4 HANA system functionality. These extensions include: Multi-Bank Connectivity for simplified and secure banking interactions, SAP  Digital Payment Add-On for efficiently connecting to payment service providers. Trading Platform Integration for streamlined financial instrument trading, SAP Cloud for Credit Integration to assess business partner credit risk, SAP Taulia for Working Capital Management, Cash Application for automatic bank statement processing and cash application, and lastly, SAP Market Rates Management for the reliable retrieving of market data. 

Empowering organizations with extensive treasury needs by enabling them to selectively adopt these value-added capabilities and solutions offered by SAP. 

Alternatives to SAP BTP 

The primary driving factor to consider integrating SAP BTP as an addon to your SAP ERP is when there is an integrated company-wide approach towards adopting BTP. Furthermore, if the standard SAP functionalities fall short of meeting the specific demands of the treasury department, or if the need for seamless integration with other systems arises. 

It's important to prioritize the optimization of complex processes whenever feasible first, avoiding the pitfall of optimizing inherently flawed processes using advanced technologies such as SAP BTP. It is worth noting that the standard SAP functionality, which is already substantial, could very well suffice. Consequently, we recommend conducting an analysis of your processes first, utilizing the Zanders best practices process taxonomy, before deciding on possible technology solutions. 

Ultimately, while considering technology options, it's wise to explore offerings from best-of-breed  treasury solution providers as well – keeping in mind the potential need for integration with SAP. 

Getting Started 

The above highlights just a glimpse of SAP BTP's capabilities. SAP offers a free trial that allows users to explore its services. Instead of starting from scratch, you can leverage predefined business content such as intelligent RPA bots, workflow packages, predefined decision and business rules and over 170 open connectors with third-party products to get inspired. Some examples relevant for treasury include integration with Trading Brokers, S4HANA SAP Analytics Cloud, workflows designed for managing free-form payments and credit memos, as well as connectors linking to various accounting systems such as Netsuite Finance, Microsoft Dynamics, and Sage. 

Conclusion 

SAP BTP for Treasury is a powerful platform that can significantly enhance treasury. Its advanced analytics, app development and integration, and process automation capabilities enable organizations to gain valuable insights, automate tasks, and improve overall efficiency. If you are looking to revolutionize your treasury operations, SAP BTP is a compelling option to consider.