Exploring the Shift: From ‘Best of Breed’ to ‘Integrated’ Treasury Management Systems and vice versa

March 2024
3 min read

Is the grass always greener on the other side? Observing a tendency to change from “best of breed treasury management systems” to best “integrated treasury management systems” and vice versa.

In large organizations, the tendency is to select large scale ERP systems to support as much of the organization's business processes within this system. This is a goal that is driven typically by the IT department as this approach reduces the number of different technologies and minimizes the integration between systems. Such a streamlined and simplified system architecture looks to mitigate risk by reducing the potential points of failure and total cost of ownership.

Over the years the treasury department has at times chosen to rather deploy “best of breed” treasury management systems and integrate this separate system to the ERP system. The treasury business processes and therefore systems also come with some significant integration points in terms of trading platforms, market data and bank integration for tasks such as trade confirmations, payments, bank statements and payment monitoring messaging.

The IT department may view this integration complexity as an opportunity for simplification if the ERP systems are able to provide acceptable treasury and risk management functionalities. Especially if some of the integrations that the treasury requires does overlap with the needs of the rest of the business – i.e. payments, bank statements and market data.

Meanwhile, the treasury department will want to ensure that they have as much straight through processing and automation as possible with robust integration. Since their high value transactions are time sensitive, a breakdown in processing would result in negative transactional cost implications with their bank counterparts.

Deciphering Treasury System Selection: Below the Surface 

The decision-making process for selecting a system for treasury operations is complex and involves various factors. Some are very much driven by unique financial business risks, leading to a functional based decision process. However, there are often underlying organizational challenges that play a far more significant role in this process than you would expect. Some challenges stem from behavioral dimensions like the desire for autonomy and control from the treasury. While others are based on an age-old perception that the “grass is greener on the other side” – meaning the current system frustrations result in a preference to move away from current systems.

An added and lesser appreciated perspective is that most organizations tend to mainly focus on technical upgrades but not often functional upgrades on systems that are implemented.  Meaning that existing systems tend to resemble the version of the system based on when the original implementation took place. This will also lead to a comparison of the current (older version) system against the competing offerings latest and greatest.

Another key observation is that with implementing integrated TMS solutions like the SAP TRM solution in the context of the same ERP environment, the requirements can become more extensive as the possibilities for automating more with all source information increase. Consider for example the FX hedging processes where the source exposure information is readily available and potential to access and rebalance hedge positions becomes more dynamic.

Closing thoughts

There is no single right answer to this question for all cases. However, it is important to ensure that the process you follow in making this decision is sound, informed and fair. Involving an external specialist with experience in navigating such decisions and exposure to various offerings is invaluable.

To support these activities, Zanders has also built solutions to make the process as easy as it can possibly be, including a cloud-based system selection tool.

Moreover for longer term satisfaction, enabling the evolution of the current treasury system (be it best of breed or integrated) is essential. The system should evolve with time and not remain locked into its origin based on the original implementation. Here engaging with a specialist partner with the right expertise to support the treasury and IT organizations is key. This can improve the experience of the system and this increased satisfaction can ensure decision making is not driven or led by negativity.

In support of this area Zanders has a dedicated service called TTS which can come alongside your existing IT support organization and inject the necessary skill and insight to enable incremental improvements alongside improved resolution timeframes for day-to-day systems issues.

For more information about out Treasury Technology Service, reach out to Warren Epstein.

Bolt chooses treasury efficiency in scale-up of business 

Revolutionizing Bolt’s Treasury: Efficiency, Reliability, and Growth

Mid 2023, Bolt successfully implemented its new full-fledged treasury management system (TMS). With assistance of Zanders consultants, the mobility company implemented Kyriba – a necessity to support Bolt’s small treasury team. As a result, all daily processes are almost completely automated. “It's about reliability.”

Bolt is the leading European mobility platform that’s focused on more efficient, convenient and sustainable solutions for urban travelling. With more than 150 million customers in at least 45 countries, it offers a range of mobility services including ride-hailing, shared cars and scooters, food and grocery delivery. “Bolt was founded by Markus Villig, a young Estonian guy who quit his school to start this business with €5,000 that he borrowed from his parents,” says Mahmoud Iskandarani, Group Treasurer at Bolt. “He built an app and started to ask drivers on the street to download it and try it out. Now we have millions of drivers and passengers, almost 4,000 employees and several business lines. Last August, we celebrated our 10th anniversary. So, we have one of the fastest growing businesses in Europe. And our ambition is to grow even faster than so far.” 

Driven by technology 

Because of its fast growth, Bolt’s Treasury team decided to look for a scalable solution to cope with the further expansion of the business. Freek van den Engel, Treasury manager at Bolt: “We needed a system that could automate most of our daily processes and add value. Doing things manually is not efficient and risks are high. To help us scale up while maintaining efficiency, we needed our Treasury to be driven by technology.” 

Iskandarani adds: “Meanwhile, our macro environment is changing and we had some bank events. In the past years, startups or scale-ups have seen big growth and didn't focus too much on working capital management. Interest rates were low, which made it easy to raise money from investors. Now, we need to make sure that we manage our working capital the right way so that we can access our money, mitigate risks, and that we get a decent return on our cash. That’s when it's controlled by Treasury and invested correctly.” 

Choosing Kyriba

Van den Engel led a treasury system selection process three years ago for his previous employer, where he also worked together with Iskandarani. “That experience helped us to come up with a shortlist of three providers, instead of having a very long RfP process looking at a long list of vendors. We started the selection process in June 2022 and two months later we chose Kyriba because of its strong functionality. Also, it’s a solution offered as SaaS, which means we don't have to worry about upgrades – a very important reason for us. Kyriba has been working with tech companies similar to ours. Another decisive factor was their format library, called Open Format Studio. It allows us to use self-service when it comes to configuring payment formats, reducing our costs and turn-around time when expanding to new geographies.” 

Implementation partner 

For Bolt, Kyriba will function as in-house bank system, and support its European cash pool. During the selection process, the team had some reference calls with other Kyriba users to discuss experiences with the system and the implementation. “One piece of feedback we received was that it works very well to bring in implementation partners to complete such a project successfully. Zanders stood out, because of its proven track record and the awards it had won. Also, Mahmoud and I both had experience with Zanders during some projects at our previous employer. That’s why we asked them to be our implementation partner.” 

In October 2022, the implementation process started. In July 2023, the system went live. Kyriba’s TMS solution covered all treasury core processes, including cash position reporting (including intra-day balance information), liquidity management, funding, foreign exchange with automatic integration to 360T and Finastra, investments, payment settlements and risk management.  

Trained towards independency 

As part of the implementation process, Zanders trained Bolt on how to use the new tool, and assisted in using the Open Format Studio. In this way, the team built the knowledge and experience needed to roll out to new countries more independently.  

Van den Engel: “We aimed to be independent and do as much as possible ourselves to reduce costs and build up in-house expertise on the system. Zanders helped us figuring out what we wanted, explained and guided us, and showed what the system can do and how to align that with our needs in the best possible way. Once we were clear on the blueprint, they helped us with our static data, connectivity and initial system set-up. After the training they led, we were able to do most of it ourselves, including the actual system configuration work, for which Zanders had laid the foundation.” 

Rolling out the payment hub 

With assistance of Zanders consultants, Bolt also set up a framework to roll out the payment hub, for the vendor payments from its ERP system called Workday and its payroll provider, Immedis. The consultants assisted with configuration of initial payment scenarios and workflows. “We made the connections, tested them and did a pilot with Workday last summer. After training and with the experience that we've built up using Open Format Studio, we can roll out to new countries and expand it ourselves. Starting in August, we continued to roll out Kyriba’s payment hub to more countries, and to implement Payroll. With the payment hub we are now live in 16 countries and that's basically fully self-serviced. Apart from some support for specialized cases, we don’t need support anymore for the payment hub.” 

Many material benefits 

Having a small hands-on project team meant no need for a complex project management organization to be set-up. Naturally Bolt and Zanders started using agile project management, with refocus of priorities to different streams as necessary. The Kyriba implementation project was closed within the set budget in 9 months’ time.  

Iskandarani is happy with the results. “It is clear there are benefits of this implementation when it comes to efficiency and risk management. We now have the visibility over our cash and the fact that we have a system telling us that there’s an exposure that we should get rid of, that has a lot of value. Also, we have some financial benefits that we could not have achieved without the system. Today we can pool our cash better, we can invest it better, and we can handle our foreign exchange in a better way. Before this, we have overpaid banks.” 

Reliability and control 

“We could have hired more people”, Van den Engel adds. “But some things are just very difficult to do without this system. It's also about reliability. Even if you have a manual process in place that works, you will see it breaking down from time to time. If someone deletes a formula, or a macro stops working, that becomes very risky. It’s also about the control environment. As a company we're looking to become more mature and implement controls that should be there – that too is very difficult to do without a proper system that can generate these reports, be properly secured with all the right standards that we need to adhere to, or do fraud detection based on machine learning in the future. It's impossible to do all that manually. Those are material benefits, but hard to quantify.”

Customer successes

View all Insights

Zanders listed on Swift Customer Security Programme (CSP) Assessment Providers directory 

July 2023
3 min read

Is the grass always greener on the other side? Observing a tendency to change from “best of breed treasury management systems” to best “integrated treasury management systems” and vice versa.

The CSP helps reinforce the controls protecting participants from cyberattack and ensures their effectivity and that they adhere to the current Swift security requirements.

*Swift does not certify, warrant, endorse or recommend any service provider listed in its directory and Swift customers are not required to use providers listed in the directory. 

Swift Customer Security Programme 

A new attestation must be submitted at least once a year between July and December, and also any time a change in architecture or compliance status occurs. Customer attestation and independent assessment of the CSCF v2023 version is now open and valid until 31 December 2023. July 2023 also marks the release of Swifts CSCF v2024 for early consultation, which is valid until 31 December 2024.   

Swift introduced the Customer Security Programme to promote cybersecurity amongst its customers with the core component of the CSP being the Customer Security Controls Framework (CSCF).​ Independent assessment has been introduced as a prerequisite for attestation to enhance the integrity, consistency, and accuracy of attestations. Each year, Swift releases an updated version of the CSCF that needs to be attested to with support of an independent assessment.  

The Attestation is a declaration of compliance with the Swift Customer Security Controls Policy and is submitted via the Swift KYC-SA tool. Dependent on the Swift Architecture used, the number of controls to be implemented vary; of which certain are mandatory, and others advisory.​ 

Further details on the Swift CSCF can be found on their website:

Our services 

Do you have arrangements in place to complete the independent assessment required to support the attestation?  

Zanders has experience with and can support the completion of an independent external assessment of your compliance to the Swift Customer Security Control Framework that can then be used to fully complete and sign-off the Swift attestation for this year.​  

With an extensive track record of designing and deploying bank integrations, our intricate knowledge of treasury systems across both IT architecture as well as business processes positions us well to be a trusted independent assessor. We draw on past projects and assessments to ask the right questions during the assessment phase, aligning our customers with the framework provided by Swift.  

The Swift attestation can also form part of a wider initiative to further optimise your banking landscape, whether that be increasing the use of Swift within your organisation, bank rationalization or improving your existing processes. The availability of your published attestation and its possible consultation with counterparties (upon request) helps equally in performing day-to-day risk management. 



We start with rigorous planning of the assessment project, developing a scope of work and planning resources accordingly. Our team of experts will work with clients to formulate an Impact Assessment based on the most recent version of the Swift Customer Security Controls Framework. 

Architecture Classification 

A key part of our support will be working with the client to formulate a comprehensive overview of the system architecture and identify the applicable controls dictated by the CSCF.  

Perform Assessment 

Using our wide-ranging experience, we will test the individual controls against specific scenarios designed to root out any weaknesses and document evidence of their compliance or where they can be improved.  

Independent Assessment Report 

Based on the evidence collected, we will prepare an Independent Assessment report which includes status of the compliance against individual controls, baselining them against the CSCF and recommendations for improvement areas within the system architecture.  

Post Assessment Activities 

Once completed, the Independent Assessment report will support you with the submission of the Attestation in line with the requirements of the CSCF version in force, which is required annually by Swift. In tandem, Zanders can deliver a plan for implementation of the recommendations within the report to ensure compliance with current and future years’ attestations. Swift expects controls compliance annually, together with the submission of the attestation by 31 December at the latest, in order to avoid being reported to your supervisor. Non-compliant status is visible to your counterparties. 

Do you need support with your Swift CSP Independent Assessment?  

We are thrilled to offer a Swift CSP Independent Assessment service and look forward to supporting our clients with their attestations, continuing their commitment to protecting the integrity of the Swift network, and in doing so supporting their businesses too. If you are interested in learning more about our services, please contact us directly.  

ISO 20022 XML (Pain.001.001.09) – Introduction of the Structured Address

May 2023
3 min read

Is the grass always greener on the other side? Observing a tendency to change from “best of breed treasury management systems” to best “integrated treasury management systems” and vice versa.

However, possibly the most important point for corporates to be aware of is the planned move towards explicit use of the structured address block. In this second article in the ISO 20022 series, Zanders experts Eliane Eysackers and Mark Sutton provide some valuable insights around this industry requirement, the challenges that exists and an important update on this core topic. 

What is actually happening with the address information? 

One of the key drivers around the MT-MX migration are the significant benefits that can be achieved through the use of structured data. E.g., stronger compliance validation and support STP processing.  The SWIFT PMPG1 (Payment Market Practice Group) had advised that a number of market infrastructures2  are planning  to mandate the full structured address with the SWIFT ISO migration. The SWIFT PMPG had also planned to make the full structured address mandatory for the interbank messages – so effectively all cross-border payments. The most important point to note is that the SWIFT PMPG had also advised of the plan to reject non-compliant cross border payment messages from November 2025 in line with the end of the MT-MX migration. So, if a cross border payment did not include a full structured address, the payment instruction would be rejected. 

What are the current challenges around supporting a full structured address? 

Whilst the benefits of structured data are broadly recognised and accepted within the industry, a one size approach does not always work, and detailed analysis conducted by the Zanders team revealed mandating a full structured address would create significant friction and may ultimately be unworkable. 

Diagram 1: Challenges around the implementation of the full structured address. 

From the detailed analysis performed by the Zanders team, we have identified multiple problems that are all interconnected, and need to be addressed if the industry is to achieve its stated objective of a full structured address. These challenges are summarized below:  

  • Cost of change: The 2021 online TMI poll highlighted that 70% of respondents confirmed they currently merge the building name, building number, and street name in the same address line field. The key point to note is that the data is not currently separated within the ERP (Enterprise Resource Planning) system. Furthermore, 52% of these respondents highlighted a high impact to change this data, while 26% highlighted a medium impact. As part of Zanders’ continued research, we spoke to two major corporates to gain a better sense of their concerns. Both provided a high-level estimate of the development effort required for them to adapt to the new standard: ½ million euros. 
  • Fit for Purpose: From the ISO 20022 expert group discussions, it was recognized that the current XML Version 9 message would need a significant re-design to support the level of complexity that exists around the address structure globally.  
  • Vendor Support: Whilst we have not researched every ERP and TMS (Treasury Management System) system, if you compare the current structured address points including field length in the XML Version 9 message with the master data records currently available in the ERP and TMS systems, you will see gaps in terms of the fields that are supported and the actual field length. This means ERP and TMS software vendors will need to update the current address logic to fully align with the ISO standard for payments – but this software development cannot logically start until the ISO address block has been updated to avoid the need for multiple software upgrades.
  • Industry Guidelines: Whilst industry level implementation guidelines are always a positive step, the current published SWIFT PMPG guidelines have primarily focused on the simpler mainstream address structures for which the current address structure is fine. By correctly including the more complex local country address options, it will quickly highlight the gaps that exist, which mean compliance by the November 2025 deadline looks unrealistic at this stage. 
  • Regulatory Drivers: At this stage, there is still no evidence that any of the in-country payments regulators have actually requested a full structured address. However, we have seen some countries start to request minimum address information (but not structured due to the MT file format), such as Canada and US. 
  • Time to Implement: We must consider the above dependencies that need to be addressed first before full compliance can logically be considered, which means a new message version would be required. Whilst industry discussions are ongoing, the next ISO maintenance release is November 2023, which will result in XML version 13 being published. If we factor in time for banks to adopt this new version (XML Version 13), time for software vendors to develop the new full structured address including field length and finally, for the corporates to then implement this latest software upgrade and test with their banking partners, the November 2025 timeline looks unrealistic at this point in time.

A very important update 

Following a series of focused discussions around the potential address block changes to the XML Version 9 message, including the feedback from the GLEIF3 the ISO payment expert group questioned the need to support a significant redesign of the address block to enable the full structured address to be mandated. The Wolfsberg Group4 also raised concerns about scale of the changes required within the interbank messaging space.

Given this feedback, the SWIFT PMPG completed a survey with the corporate community in April. The survey feedback highlighted a number of the above concerns, and a change request has now been raised with the SWIFT standards working group for discussion at the end of June. The expectation is that the mandatory structured address elements will now be limited to just the Town/City, Postcode, and country, with typical address line 1 complexity continuing to be supported in the unstructured address element. This means a blended address structure will be supported.    

Is Corporate Treasury Impacted by this structured address compliance requirement? 

There are a number of aspects that need to be considered in answering this question. But at a high level, if you are currently maintaining your address data in a structured format within the ERP/TMS and you are currently providing the core structured address elements to your banking partners, then the impact should be low. However, Zanders recommends each corporate complete a more detailed review of the current address logic as soon as possible, given the current anticipated November 2025 compliance deadline. 

In Summary 

The ISO 20022 XML financial messages offer significant benefits to the corporate treasury community in terms more structured and richer data combined with a more globally standardised design. The timing is now right to commence the initial analysis so a more informed decision can be made around the key questions. 


  1. The PMPG (payment market practice group) is a SWIFT advisory group that reports into the Banking Services Committee (BSC) for all topics related to SWIFT. 
  1. A Market Infrastructure is a system that provides services to the financial industry for trading, clearing and settlement, matching of financial transactions, and depository functions. For example, in-country real-time gross settlement (RTGS) operators (FED, ECB, BoE). 
  1. Global Legal Entity Identifier Foundation (Established by the Financial Stability Board in June 2014, the GLEIF is tasked to support the implementation and use of the Legal Entity Identifier (LEI). 
  1. https://www.wolfsberg-principles.com/sites/default/files/wb/pdfs/wolfsberg-standards/1.%20Wolfsberg-Payment-Transparency-Standards-October-2017.pdf 

How to setup a Vendor Supply Chain Finance Process in SAP

June 2022
3 min read

Vendor Supply Chain Finance (SCF) constitutes the transfer of a (trade) payable position towards the SCF underwriter (i.e. the bank). The beneficiary of the payment can then decide either to receive an invoice payment on due date or to receive the funds before, at the cost of a pre-determined fee.

The debtor’s bank account will only be debited on due date of the payable; hence the bank finances the differential between the due date and the actual payment date towards the beneficiary for this pre-determined fee. This article elaborates on why and how corporates set-up an SCF scheme with their suppliers.

The Vendor SCF construction can be depicted as:

There are multiple business rationales behind Supply Chain Finance. Why would a corporate want to setup an SCF scheme with its suppliers? The most prominent rationales are:

  • Reduction of the need of more traditional trade finance
    The need for individual line of credits and bank guarantees for each trade transaction is removed, making the trade process more efficient.
  • Sellers can flexibly and quickly fund short term financing needs
    If working capital or financing is needed, the seller can quickly request for outstanding invoices to be paid out early (minus a fee).
  • Sharing the benefits of better credit rating from buyer towards seller
    Because the financing is arranged by the buyer, the seller can enjoy the credit terms that were negotiated between buyer and financier/bank.
  • Streamlining the AP process
    By onboarding various vendors into the SCF process, the buyer can enjoy a singular and streamlined payment process for these vendors.
  • Strengthening of trade relations
    Because of the benefits of SCF, more competitive terms on the trade agreement itself can be negotiated.

SCF is typically considered a tool to improve the working capital position of a company, specifically to decrease the cash conversion cycle by increasing the payment terms with its suppliers without weakening the supply chain.

Set-up and onboarding

Typically, a set-up and onboarding process consists of the following steps. First a financing for SCF is obtained from, for example, a bank. In addition, an SCF provider must be selected and contracted. Most major banks have their own solutions but there are many third parties, for example fintechs, that provide solutions as well. Consequently, the SCF terms are negotiated, and the suppliers are onboarded to the SCF process. Lastly, your system should of course be able to process/register it. Therefore, the ERP accounts payable module needs to be adjusted, such that the AP positions eligible for SCF are interfaced into the SCF platform. Besides, your ERP system needs to be adjusted to be able to reconcile the SCF reports and bank statements.

Design considerations and Processing SCF in SAP

In the picture below we provide a high-level example of how a basic SCF process can work using basic modules in SAP. Note that, based on the design considerations and capabilities of the SCF provider, the picture may look a bit different. For each of the steps denoted by a number, we provide an explanation below the figure, going a little deeper into some of the possible considerations on which a decision must be made.

  1. Invoice and credit note data entry; In the first step, the invoices/credit notes will be entered, typically with payment terms sometime in the future, i.e. 90 days. Once entered and approved, these invoices are now available to the payment program.
  2. Payment run: The payment run needs to be engineered such that the invoices that are due in the future (i.e. 90 days from now) will be picked up already in today’s run. Some important considerations in this area are:
    • Payment netting logic: the netting of invoices and credit notes is an important design consideration. Typically, credit notes are due immediate and the SCF invoices are due sometime in the future, i.e. 90 days from now. If one would decide to net a credit note due immediate with an invoice due in 90 days, this would have some adverse impact on working capital. An alternative is to exclude credit notes from being netted with SCF invoices and have them settled separately (i.e. request the vendor to pay it out separately or via a direct debit). Additionally, some SCF providers have certain netting logic embedded in their platform. In this case, the SAP netting logic should be fully disabled and all invoices should be paid out gross. Careful considerations should be taken when trying to reconcile the SCF settled items report as mentioned in step 4 though.
    • Payment run posting: When executing the SAP payment run it is possible to either clear the underlying invoices on payment run date or to leave them open until invoice due date. If the invoices are kept open, they will be cleared once the SCF reporting is imported in SAP (see step 4). This is decision-driven by the accounting team and depends on where the open items should be rolling up in the balance sheet (i.e. payable against the vendor or payable against the SCF supplier).
  3. Payment file transfer: At this step, the payment file will be generated and sent to the SCF supplier. The design considerations are dependent on the SCF supplier’s capabilities and should be considered carefully while selecting an appropriate partner.
    • File format: Most often we advise to implement a best practice payment file format like ISO pain.001. This format has a logical structure, is supported out of the box in SAP, while most SCF partners will support it too.
    • Interface technology: The payment files need to be transferred into the SCF platform. This can be done via a multitude of ways; i.e. manual upload, automatically via SWIFT or Host2Host. This decision is often driven internally. Often the existing payment infrastructure can be leveraged for SCF payments as well.
    • Remittance information: By following ISO pain.001 standard, the remittance information that remits which invoices are paid and cleared, can be provided in a structured format, irrespective of the volume of invoices that got cleared. This ensures that the beneficiary exactly knows which invoices were paid under this payment. Alternatively, an unstructured remittance can be provided but this often is limited to 140 characters maximum.
    • Payment status reporting: Some SCF supplier will support some form of payment status reporting to provide immediate feedback on whether the payments were processed correctly. These reports can be imported in SAP; SAP can subsequently send notifications of payment errors to the key users who can then take corrective actions.
  4. SCF payment clearing reporting: At this step, the SCF platform will send back a report that contains information on all the cleared payments and underlying invoices for that specific due date. Most typically, these reports are imported in SAP to auto reconcile against the open items sitting in the administration.
    • Auto import: If import of the statement into SAP is required, the report should be in one of SAP’s standard-supported formats like MT940 or CAMT.053.
    • Auto reconciliation: If auto reconciliation of this report against line items in SAP is required, the reports line items should be matchable with the open line items in the SAP administration. Secondly, a pre-agreed identifier needs to be reported such that SAP can find the open item automatically (i.e. invoice reference, document number, end2endId, etc.). Very careful alignment is needed here, as slight differences in structure in the administration versus the reporting structure of SCF can lead to failed auto reconciliation and tedious manual post processing.
  5. Pay out to the beneficiary: Onboarded vendors can access the SCF platform and report on the pending payments and invoices. The vendor has the flexibility to have the invoices paid out early (before due date) by accepting the deduction of a pre-agreed fee. The SCF provider should ensure payment is made.
  6. Debiting bank account: At due date of the original invoice, the SCF provider will want to receive the funds.
    • Payment initiation vs direct debit: The payment of funds can in principle be handled via two processes; either the SCF customer initiates the payment himself, or an agreement is made that the SCF provider direct debits the account automatically.
    • Lump debit vs line items: Most typically, one would make a lump payment (or direct debit) of the total amount of all invoices due on that day. Some SCF providers may support line by line direct debiting although this might result in high transaction costs. Line by line debiting might be beneficial for the auto reconciliation process in SAP though (see step 7)
  7. Bank statement reporting: The bank statement of the cash account will be received and imported into SAP. Most often, the statements are received over the existing banking interface.
  8. Bank statement processing: Based on pre-configured posting rules and reconciliation algorithms in SAP, the open items in the administration are cleared and the bank balance is updated appropriately.

To conclude

If the appropriate SCF provider is selected and the process design and implementation in SAP is sound, the benefits of SCF can be achieved without introducing new processes and therefore creating a burden on the existing accounts payable team. It is fully possible to integrate the SCF processes with the regular accounts payable payments processes without adding additional manual process steps or cumbersome workarounds.

For more information, contact Ivo Postma at +31 88 991 02 00.

Three major benefits of S/4 HANA Bank Account Management

September 2021
3 min read

Vendor Supply Chain Finance (SCF) constitutes the transfer of a (trade) payable position towards the SCF underwriter (i.e. the bank). The beneficiary of the payment can then decide either to receive an invoice payment on due date or to receive the funds before, at the cost of a pre-determined fee.

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

Vendor Supply Chain Finance (SCF) constitutes the transfer of a (trade) payable position towards the SCF underwriter (i.e. the bank). The beneficiary of the payment can then decide either to receive an invoice payment on due date or to receive the funds before, at the cost of a pre-determined fee.

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

Vendor Supply Chain Finance (SCF) constitutes the transfer of a (trade) payable position towards the SCF underwriter (i.e. the bank). The beneficiary of the payment can then decide either to receive an invoice payment on due date or to receive the funds before, at the cost of a pre-determined fee.

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

Vendor Supply Chain Finance (SCF) constitutes the transfer of a (trade) payable position towards the SCF underwriter (i.e. the bank). The beneficiary of the payment can then decide either to receive an invoice payment on due date or to receive the funds before, at the cost of a pre-determined fee.

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.

Bank connectivity – Making the right choices

July 2020
3 min read

Vendor Supply Chain Finance (SCF) constitutes the transfer of a (trade) payable position towards the SCF underwriter (i.e. the bank). The beneficiary of the payment can then decide either to receive an invoice payment on due date or to receive the funds before, at the cost of a pre-determined fee.

Bank connectivity options

Within the space of bank connectivity, there is a range of choices that corporates face when deciding the best way to integrate banks towards their ERP or treasury platforms.


The most historic option, with users logging into online banking platforms to extract bank reporting and initiate payments. Banking platforms have evolved, with some offering electronic statement download (which can be readily imported into ERPs), and payment status monitoring. Whilst a readily available, easy-to-use solution, it has issues with controls and requires separate platforms for each bank.


SWIFT provides global coverage to a wide range of banks. It is seen as the global standard in bank connectivity, and from a bank perspective we have seen the membership increase.
There are two channels available:

ChannelMessage Types
FINSWIFT MT Messages – e.g. MT101, MT940
FileACTAny Message Type – typically ISO20022

SWIFT FileAct is suited to AP Payments, as ISO20022 message standards permit high volumes of payments in files. SWIFT FIN is more commonly used for treasury integration, due to the historic use of SWIFT MT messages. As ISO20022 is more widely adopted, SWIFT FileAct will become the default choice for messaging channel.

A useful tool to identify if your partner banks are onboard is SWIFT’s Readiness Portal.


Originally developed as a financial messaging transmission vehicle for Germany, EBICS has been later extended to France and Switzerland. It provides wide coverage of banks within these countries, but is not in use outside of these countries.

It generally has a lower total cost of ownership than SWIFT. The geographic restrictions mean that this is commonly used for corporates who have strong focus in the German, French or Swiss Market. For corporates operating on a global basis, EBICS does not tend to provide the bank coverage that is required.

Host-to-host (H2H)

H2H connections are direct connections from a corporate’s integration system towards a specific bank.

H2H connections are most suitable where corporates engage with a single core bank who can support local services and branch coverage in all relevant markets. These can have a lower total cost of ownership compared to using SWIFT, but this solution has a level of bank lock-in.

Direct to clearing house (UK BACS)

Within the UK, the primary clearing house is BACS, which ensures settlements of payments between debtor and creditor banks.

It is common practice in the UK for corporates to make payment instructions & direct debit instructions directly to the local clearing house BACS, where the partner bank acts as a sponsor. This requires a BACS service bureau who can act as a gateway into the BACS network. This is commonly known as “direct transmission”.

An alternative to this transfer method is “indirect transmission” where payments and direct debits are sent to the partner bank, via any of the preceding methods before being submitted to BACS itself.

API connectivity

Triggered by the PSD2 initiative, banks are now offering API connectivity.

One of the issues with API connectivity is that modern API design is targeted towards JSON formats, whilst ISO20022 is an xml-based schema. Due to low levels of standardization across different banks and countries, this has meant that ERPs and treasury platforms may require bespoke functionality to cater for these bank-specific APIs.

It is likely that these will become the future of bank connectivity, but will require some level of standardization, which could possibly come under the SWIFT umbrella.

Access to SWIFT

Connectivity of corporates to the SWIFT network has expanded over the last years from the largest corporates with high volumes of bank connections, to small-to-medium corporates with lower volumes of bank connections. To access the global SWIFT network, there are 4 main options that corporates can leverage:

  • In-house – SAG
    SWIFT Alliance Gateway (SAG) was the standard connection offered to corporates. It requires specialist SWIFT knowledge and has high complexity. This is no longer encouraged by SWIFT.
  • Outsourced – SSB
    SWIFT Service Bureaus (SSBs) remove the complexities of establishing the connection to the SWIFT network. SSBs certified by SWIFT manage the hardware and access configuration. Nowadays approximately 50% of all corporates access SWIFT through a SSB.
  • In-house – Alliance Lite 2
    SWIFT introduced Alliance Lite2 to enable smaller corporates to connect to the network. SWIFT proprietary software, installed locally, in combination with a hard token, transfers messages to the SWIFT network. Since each transmission may require an approval, this option is not fit for corporates with high payment volumes/STP-rates.
  • Outsourced – Alliance Lite2 embedded within Business Application
    Applications (L2BA) Since 2012, SWIFT has offered Alliance Lite2 including business applications for treasury management systems, bank connectivity providers and in-house banking/payment factory providers. Even though this option is relatively new, it gained popularity very quickly, with corporates looking to externalize bank connectivity whilst keeping total cost of ownership to a minimum.

For corporates having joined SWIFT since January 2018, 64% have opted for the SWIFT Cloud Alliance Lite 2 options. It is likely that the adoption of the embedded Alliance Lite 2 is behind this trend.

SAP Multi-Bank Connectivity

SAP Multi-Bank Connectivity (MBC) is SAP’s offering of a SWIFT connection embedded within Business Applications. SAP MBC is offered as a software-as-a-service solution by SAP. This is a revived form of SAP’s Financial Services network, which was launched in 2015, but with an enhanced offering such as integrated SWIFT connection.

Embedded within the SAP Cloud Platform, it provides capability for exchange of financial messaging with partner banks. As well as connectivity to the SWIFT network through an embedded version of Alliance Lite 2, this integration platform offers connectivity to partner banks through EBICS and H2H connections.

From a technical perspective, SAP MBC can perform transmissions using SFTP, REST, SOAP and AS2. We have seen evidence of corporate group IT policies dictating preferred transmission methods, so it is important that bank connectivity tools accommodate these. The platform has 99% up-time, and various failover mechanisms in place.

SAP MBC is particularly relevant to those corporates who are looking to move towards SAP as a strategic software vendor. With many corporates embarking on S/4 HANA transformation, it is a popular consideration.

We expect to see this offering as strong competition to SWIFT Service Bureaus going forward, especially where corporates are not leveraging the value-add services that SSBs offer.


is now part of Zanders

In a continued effort to ensure we offer our customers the very best in knowledge and skills, Zanders has acquired Fintegral.

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