Embracing Risk Management Excellence: An Interview with Zanders’ New Partner, Brecht van den Driessche

October 2023
4 min read

In a constantly evolving financial landscape, the significance of risk management cannot be emphasized enough.

Today, we engage in a conversation with Brecht van den Driessche, a new addition to the Zanders team, to explore his motivations for joining Zanders and his vision for the future of risk management.

Q: Why did you choose Zanders?

A: I've been familiar with Zanders for over a decade, and what has consistently impressed me is the professionalism and deep expertise in Risk Management demonstrated by its people. Consultancy is inherently a people-centric business, and the combination of professionalism with an engaging and enjoyable working environment was a key factor in my decision to join the Zanders team.

Q: What are your focus areas and goals for the short term and long term?

A: The landscape of expectations for Risk Managers and their regulators is rapidly evolving. Recent events such as the collapse of Silicon Valley Bank and the takeover of Credit Suisse by UBS have highlighted the critical importance of proper Risk Management. Financial institutions must invest in a centralized risk function and supporting systems to enhance transparency and real-time Risk Management. Worldwide, there is a clear trend among banks to centralize data, improve Risk Management systems, and perform more frequent, granular, and standardized risk calculations and disclosures. Regulators are increasingly pushing banks to move away from spreadsheets and manage their financial risks with professional, often vendor-based systems. As a result, banks are moving away from legacy systems and heavily investing in new Risk Management Systems.

My primary focus is to assist our customers in embracing further digitalization to maximize the benefits of these investments. This includes strategic benchmarking, optimization, selection, and the implementation of fit-for-purpose Risk Management systems. To achieve this, we collaborate closely with a select group of world-leading suppliers of risk technology.

The ultimate goal is for Zanders to become the go-to expert for our clients, providing them with robust Risk Management systems to effectively manage financial risks and make informed decisions.

Q: How were your first weeks at Zanders?

A: Right from day one, I felt the positive energy and warmth that characterizes the Zanders team. Simultaneously, around 20 new colleagues embarked on their Zanders journeys across Europe, and the onboarding process was exceptionally smooth. I've already had the pleasure of meeting many colleagues, clients, and partners, and I am genuinely convinced that my decision to join Zanders was the perfect career move.

Q: Anything you want to share with the outside world about this career move?

A: If you're curious about our ambitions and how we can help you achieve yours, don't hesitate to reach out. Drop me a message, and let's connect.

In a world of ever-evolving risks and escalating expectations in risk management, Zanders plays a pivotal role in helping organizations navigate these challenges, propelling them toward success. With our unwavering focus on professionalism, expertise, and a commitment to embracing digitalization, we stand as a trusted partner for those in the finance industry. To learn more about us, please visit our About Zanders page.

How to manage SWIFT MT/MX Migration in SAP 

October 2023
4 min read

In a constantly evolving financial landscape, the significance of risk management cannot be emphasized enough.

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.  


    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’.  


    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. 

    Networking and new SAP Treasury insights in Chicago 

    October 2023
    4 min read

    In a constantly evolving financial landscape, the significance of risk management cannot be emphasized enough.

    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!

    SAP Treasury conference in Amsterdam 

    October 2023
    4 min read

    In a constantly evolving financial landscape, the significance of risk management cannot be emphasized enough.

    Of the many attending corporates and partners were offered the opportunity to hear the latest ins and outs of treasury transformation with S/4HANA.  

    Next to the enhancements in S/4HANA Treasury, customers had a clear need to understand what it could means for their Treasury and how they could achieve it. The conference provided an excellent opportunity to exchange ideas with each other and learn from the many case studies presented on treasury transformation.  

    Treasury Transformation with SAP S/4HANA 

    Alongside Ernst Janssen, Digital Treasury and Banking Manager at dsm-firmenich, Zanders director Deepak Aggarwal presented the value drivers for treasury in an S/4HANA migration. The presentation also included the different target architecture and deployment options, as Ernst talked about the choices made at dsm-firmenich and the rationale behind them in a real-life business case study. Zanders has a long-standing relationship with DSM going back as far as 2001, and has supported them in a number of engagements within SAP treasury. 

    In addition, there were similar other presentations on treasury transformation with S/4HANA.  BioNTech presented the case study on centralization of their bank connectivity via APIs for both inbound and outbound bank communication. They are also the first adopters of the new In-House Bank under Advanced Payment Management (APM) solution and integrate the Morgan Money trading platform for money market funds. ABB and PwC talked about their treasury transformation journey on centralization of cash management in a side-car, functionality enhancement through APM, and integration with Central Finance system for balance sheet FX management. Alter Domus and Deloitte presented their treasury transformation via S/4HANA Public Cloud including integrated market data feed and Multi-Bank Connectivity. 

    Digital and Streamlined Treasury Management System 

    Christian Mnich from SAP laid out the vision of SAP Treasury and Working Capital Management solution as an agile, resilient and sustainable solution delivering end-to-end business processes to all customers in all industries. Christian referred to the market challenges of high inflation and rising interest rates calling for a greater need of bank resiliency and cash forecasting to reduce dependencies on business partners and improve cash utilization while avoiding dipping into debt facilities. The sustainability duties like ESG reporting and carbon offsetting appear to be more relevant than ever to meet global assignments. SAP’s 2023 product strategy was presented with Cloud ERP (public or private) at the core, Business Technology Platform as integration and extension layer, and the surrounding SAP and ecosystem applications, delivering end-to-end integrated processes to the business. 

    Trading Platform Integration 

    Another focus area was SAP Integration with ICD for Money Market Funds (MMFs) through Trading Platform Integration (TPI) application. MMFs are seen as an attractive alternative to deposits, yielding better returns and diversifying risk through investment in multiple counterparties. Quite often the business is restricted on MMF dealing as a result of system limitations and overhead due to the manual processes. Integration with ICD via TPI offers benefits of single sign on, automated mapping from ICD to SAP Treasury, auto-creation of securities transaction in SAP, email notification and integrated reporting in SAP Treasury. 

    Embedded Receivables Finance 

    Lastly, SAP integration with Taulia was another focus area to facilitate liquidity management in the companies. Taulia was presented as driving Working Capital Management (WCM) in the companies through its WCM platform and Taulia Multi Funder for efficient share of wallet or discovery of new liquidity. The embedded receivables finance solution in Taulia automates the receivables sales process by automating the status updates of all invoices in Taulia platform and the seller ERP.  

    If you are interested in joining SAP Treasury conferences in future, or any of the topics covered, please do reach out to your Zanders’ contacts. 

    Driving Treasury Innovation: A Closer Look at SAP BTP

    October 2023
    4 min read

    In a constantly evolving financial landscape, the significance of risk management cannot be emphasized enough.

    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. 


    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.  

    Three major benefits of S/4 HANA Bank Account Management

    September 2021
    3 min read

    With house bank accounts treated as master data instead of configuration objects including the latest enhancement, the bank account subledger concept, SAP S/4HANA Bank Account Management (BAM) aims to shift responsibility of bank account management life cycle from the technical teams to the cash and banking teams.

    Bank accounts can now be created and maintained by the cash and banking responsible team, giving them more control over the timing of opening or closing of an account as well as expediting the overall process and limiting the number of users involved in the maintenance of the accounts.

    Figure 1 – Launchpad BankApplications

    The advantages of using the full version of BAM are multiple, but below we highlight three of the main reasons full BAM is a must have for the companies using one or multiple SAP environments.

    Flexible workflows

    Maintenance of bank account data can trigger workflows based on the organization’s requirements and the approval processes in place. With the workflows the segregation of duties can be enforced when maintaining a bank account.

    Even though workflows are not a new functionality in S/4HANA, the fact that workflow templates are available and can be amended by defining preconditions, step sequences and recipients improves the approval process of bank accounts.

    The workflows can be created and activated as completely new ones or based on the already existing templates . You can create a new workflow by copying an existing one and updating the parameters according to the new requirements.

    All the requests to release or approve bank account changes are available as of S/4HANA 2020 in the My Inbox for Bank Accounts app, the dedicated inbox app where users can check the status of each request initiated by the users themselves or sent to them and act upon.

    Easy data replication

    One of the challenges multiple organizations have, especially those operating various SAP environments, is data synchronization and replication. We often come across situations when banks, house banks and bank accounts are not maintained in all relevant environments creating data inconsistencies and making processes more difficult than they already are.

    One of the ways of avoiding these types of situations is by replicating banks, house banks and bank accounts from production to quality assurance and to development environments using standard Idocs.

    Figure 2 – Bank data replication in S/4 HANA

    If the organization is operating on multiple SAP and non-SAP instances and running processes in a S/4 HANA side-car solution, the challenge of maintaining banks, house banks and bank accounts grows exponentially. Distributing the data via Idocs will not only keep all the systems coordinated, it will also decrease the amount of manual work and avoid situations when processes fail because of delays in keeping the data up to date in all relevant environments.

    Figure 3 -Bank data replication across multiple environments

    Simple way of managing cash pools

    Cash pooling structures can easily be set up by the user and in this way the BAM solution is integrated with the process of making cash management transfers.

    Even though the cash pooling and cash concentration in S/4HANA are managed using five different apps (shown in the figure below), the actual structure of the cash pool is defined directly in the Manage Bank Accounts app (Cash Pool tab).

    Figure 4 – Five apps to manage cash pooling and cash concentration in S/4HANA

    In the Cash Pool tab, the user can define the cash pool structure as per each company’s requirements. It is important to keep in mind the fact that a bank account can be assigned only to two different cash pools: once as the header account of a cash pool, and once in a different cash pool, as a subaccount.

    The cash pools created in the system are not restricted to one company code but can be defined using various currency accounts belonging to multiple company codes. For each of the bank accounts included in a cash pool, a target balance as well as a minimum transfer amount can be defined in the Cash Pool tab of the Manage Bank Accounts app, with the mention that both (target balance as well as minimum transfer amounts) must be defined in the bank account currency.

    During the cash concentration process, when bank transfers are generated, the payment methods defined in this tab will be picked up. Therefore, if required, two different payment methods can be assigned; the first for the structure where the bank account is acting as a header account and the second for the one where the account in scope is a subaccount. To pick them up from the drop-down list, the assigned payment methods must be initially setup in the system.

    To conclude

    Maintaining banks, house banks and bank accounts can be a difficult task especially in large organizations operating with different SAP and non-SAP environments. It can be time-consuming; it can involve multiple people from different parts of the organization (IT, master data, cash and banking etc.) and it can easily be prone to errors and mismatches if not correctly maintained and synchronized. Having one single source of truth for the bank accounts – which is easy to maintain, user-friendly, with appropriate controls in place and reporting capabilities, easy to replicate the data across different environments and which allows the user to create and maintain not only the bank accounts but also the cash pool structures – can save time, resources and simplify processes.

    Corrections and reversals in SAP Treasury

    December 2020
    3 min read

    With house bank accounts treated as master data instead of configuration objects including the latest enhancement, the bank account subledger concept, SAP S/4HANA Bank Account Management (BAM) aims to shift responsibility of bank account management life cycle from the technical teams to the cash and banking teams.

    As part of an SAP Treasury system implementation or enhancement, we review existing business processes, define bottlenecks and issues, and propose (further) enhancements. Once we have applied these enhancements in your SAP system, we create a series of trainings and user manuals which layout the business process actions needed to correctly use the system.

    “It’s only those who do nothing that make no mistakes, I suppose”

    Joseph Conrad


    This legendary saying of Joseph Conrad is still very valid today, as everyone makes mistakes. Therefore, we help our clients define smooth, seamless and futureproof processes which consider the possibility of mistakes or requirements for correction, and include actions to correct them.

    Some common reasons why treasury payments require corrections are:

    • No need for a cash management transfer between house bank anymore
    • Incorrect house/beneficiary bank details were chosen
    • Wrong currency / amount / value date / payment details
    • Incorrect payment method

    One of our practices is to first define a flowchart structure in form of decision tree, where each node represents either a treasury process (e.g. bank-to-bank transfer, FX deal, MM deal, Securities etc.), a transaction status in SAP, or an outcome which represents a solution scenario.

    We must therefore identify the scope of the manual process, which depends on the complexity of the business case. At each stage of the transaction life cycle, we must identify whether it may be stuck and how it can be rectified or reversed.

    Each scenario will bring a different set of t-codes to be used in SAP, and a different number of objects to be touched.

    Below is an example of a bank-to-bank cash management transfer which is to be cancelled in SAP.

    Figure 1: Bank-to-bank payment reversal

    Scenario 2: A single payment request created via t-code FRFT_B and an automatic payment run is executed (F111), BCM is used but the payment batching (FBPM1) is not yet executed.

    Step 1: define the accounting document to be reversed

    T-code F111, choose the payment run created (one of the options) -> go to Menu -> Edit -> Payments -> Display log (display list) -> note the document number posted in the payment run.

    Step 2: Reverse the payment document

    T-code FB08: Enter the document number defined in step 1, choose company code, fiscal year and reversal reason, and click POST/SAVE.

    SAP creates the corresponding offsetting accounting document.

    Step 3: Reverse clearing of the payment request

    T-code F8BW: Enter the document number defined in step 1, choose company code, fiscal year and click EXECUTE

    The result is the payment request is uncleared.

    Step 4: Reverse the payment request

    T-code F8BV: enter the payment request (taken from FTFR_B or F111 or F8BT) and press REVERSE.

    This step will reverse the payment request itself. Also, you may skip this step if you tick “Mark for cancellation” in STEP 3.

    Step 5: Optional step, depending on the client setup of OBPM4 (selection variants)

    Delete entries in tables: REGUVM and REGUHM. This is required to disable FBPM1 payment batching in SAP BCM for the payment run which is cancelled. The execution of this step depends on the client setup.

    Call functional module (SE37): FIBL_PAYMENT_RUN_MERGE_DELETE with:

    • I_LAUFD : Date of the payment run as in F111
    • I_LAUFI : Identification of the payment run as in F111
    • I_XVORL : empty/blank

    The number of nodes and branches comprising the decision tree may vary based on the business case of a client. Multiple correctional actions may also be possible, meaning there is no unique set of the correctional steps applicable for all the corporates.

    If you interested in a review of your SAP Treasury processes, their possible enhancements and the corresponding business user manuals, please feel free to reach out to us. We are here to support you!

    Managing Virtual Accounts using SAP In-House Cash

    December 2020
    3 min read

    With house bank accounts treated as master data instead of configuration objects including the latest enhancement, the bank account subledger concept, SAP S/4HANA Bank Account Management (BAM) aims to shift responsibility of bank account management life cycle from the technical teams to the cash and banking teams.

    SAP IHC is a module that facilitates a full suite of payment factory processes. It can be seen as an intercompany position subledger with a set of fancy features like POBO payment routing, bank statement allocation, arms-length intercompany interest calculations, out of the box payment and bank statement interfaces with participants (Opco’s) etcetera.

    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:

    How to set up Intraday Bank Statement reporting in SAP

    September 2020
    3 min read

    With house bank accounts treated as master data instead of configuration objects including the latest enhancement, the bank account subledger concept, SAP S/4HANA Bank Account Management (BAM) aims to shift responsibility of bank account management life cycle from the technical teams to the cash and banking teams.

    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:
    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.

    This site is registered on wpml.org as a development site.