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.

Why does this aim matter? Well, in this age of digitization, almost every aspect of the business has a digital footprint. Some significantly more than the others. This presents a unique opportunity where potentially all information can be reliably processed to take tactical and strategic decisions from a position of knowledge. Good data can facilitate hedging, forecasting and other key corporate activities. Having said all that, care must also be taken to not drown in the data lake¹ and become over-burdened with useless information. Take the example of Amazon in 2006 when it reported that cross-selling attributed for 35% of their revenue². This strategy looked at data from shopping carts and recommended other items that may be of interest to the consumer. The uplift in sales was achieved only because Amazon made the best use of their data.

Treasury is no exception. It too can become data-driven thanks to its access to multiple functions and information flows. There are numerous ways to access and assess multiple sets of data (see Figure 1), thereby finding solutions to some of the perennial problems facing any organization that wants to mitigate or harness risk, study behavior, or optimize its finances and cashflow to better shape its future.

Time is money

The practical business use cases that can be realized by harnessing data in the Treasury often revolve around mastering the time function. Cash optimization, pooling for interest and so on often depend on a good understanding of time – even risk hedging strategies can depend on the seasons, for instance, if we’re talking about energy usage.

When we look at the same set of data from a time perspective, it can be used for three different purposes:
I.       Understand the ‘The Past’ – to determine what transpired,
II.     Ascertain ‘The Present’ situation,
III.   Predict ‘The Future’ based on probable scenarios and business projections.

I – The Past

“Study the past if you would define the future”

Confucius

The data in an organization is the undeniable proof of what transpired in the past. This fact makes it ideal to perform analysis through Key Performance Indicators (KPIs), perform statistical analysis on bank wallet distribution & fee costs, and it can also help to find the root cause of any irregularities in the payments arena. Harnessing historical data can also positively impact hedging strategies.

II – The Present

“The future depends on what we do in the present”

M Gandhi

Data when analyzed in real-time can keep stakeholders updated and more importantly provide a substantial basis for taking better informed tactical decisions. Things like exposure, limits & exceptions management, intra-day cash visibility or near real-time insight/access to global cash positions all benefit, as does payment statuses which are particularly important for day-to-day treasury operations.

III – The Future

“The best way to predict the future is to create it.”

Abraham Lincoln

There are various areas where an organization would like to know how it would perform under changing conditions. Simulating outcomes and running future probable scenarios can help firms prepare better for the near and long-term future.

These forecast analyses broadly fall under two categories:

Historical data: assumes that history repeats itself. Predictive analytics on forecast models therefore deliver results.

Probabilistic modelling: this creates scenarios for the future based on the best available knowledge in the present.

Some of the more standard uses of forecasting capabilities include:

• risk scenarios analysis,
• sensitivity analysis,
• stress testing,
• analysis of tax implications on cash management structures across countries,
• & collateral management based on predictive cash forecasting, adjusted for different currencies.

Working capital forecasting is also relevant, but has typically been a complex process. The predication accuracy can be improved by analyzing historical trends and business projections of variables like receivables, liabilities, payments, collections, sales, and so on. These can feed the forecasting algorithms. In conjunction with analysis of cash requirements in each business through studying the trends in key variables like balances, intercompany payments and receipts, variance between forecasts and actuals, this approach can lead to more accurate working capital management.

How to become a data-driven organization

“Data is a precious thing and will last longer than the systems themselves.”

Tim Berners-Lee

There can be many uses of data. Some may not be linked directly to the workings of the treasury or may not even have immediate tangible benefits, although they might in the future for comparative purposes. That is why data is like a gold mine that is waiting to be explored. However, accessing it and making it usable is a challenging proposition. It needs a roadmap.

The most important thing that can be done in the beginning is to perform a gap analysis of the data ecosystem in an organization and to develop a data strategy, which would embed importance of data into the organization’s culture. This would then act as a catalyst for treasury and organizational transformation to reach the target state of being data-driven.

The below roadmap offers a path to corporates that want to consistently make the best use of one of their most critical and under-appreciated resources – namely, data.

We have seen examples like Amazon and countless others where organizations have become data- driven and are reaping the benefits. The same can be said about some of the best treasury departments we at Zanders have interacted with. They are already creating substantial value by analyzing and making the optimum use of their digital footprint. The best part is that they are still on their journey to find better uses of data and have never stopped innovating.

The only thing that one should be asking now is: “Do we have opportunities to look at our digital footprint and create value (like Amazon did), and how soon can we act on it?”

References:

1. https://zandersgroup.com/en/latest-insights/data-analytics-for-treasury-dont-drown-in-the-data-lake/
2. https://www.forbes.com/sites/chuckcohn/2015/05/15/a-beginners-guide-to-upselling-and-cross-selling/?sh=395a58042912

Since the first sustainability-linked derivative was executed in 2019, market participants have entered into a variety of ESG-related derivatives and products. In this article we provide you with an overview of the different ESG derivatives. We will touch upon the regulatory and valuation implications of this relatively new derivative class in a subsequent article, which will be published later this year.

Types of ESG-related derivatives products

Driven by regulatory pressure and public scrutiny, corporates have been increasingly looking for ways to manage their sustainability footprint. As a result of a blooming ESG funding market, the role of derivatives to help meet sustainability goals has grown. ESG-related derivatives cover a broad spectrum of derivative products such as forwards, futures and swaps. Five types (see figure 1) of derivatives related to ESG can be identified; of which three are currently deemed most relevant from an ESG perspective.

The first category consists of traditional derivatives such as interest rate swaps or cross currency swaps that are linked to a sustainable funding instrument. The derivative as such does not contain a sustainability element.

Sustainability-linked derivatives

Sustainability-linked derivatives are agreements between two counterparties (let’s assume a bank and a corporate) which contain a commitment of the corporate counterparty to achieve specific sustainability performance targets. When the sustainability performance targets are met by the corporate during the lifetime of the derivative, a discount is applied by the bank to the hedging instrument. When the targets are not met, a premium is added. Usually, banks invest the premium they receive in sustainable projects or investments. Sustainability-linked derivative transactions are highly customizable and use tailor-made KPIs to determine sustainability goals. Sustainability-linked derivatives provide market participants with a financial incentive to improve their ESG performance. An example is Enel’s sustainability-linked cross currency swap, which was executed in July 2021 to hedge their USD/EUR exchange rate and interest rate exposures.

Emission trading derivatives

Other ESG-related derivatives support meeting sustainable business models and consist of trading carbon offsets, emission trading derivatives, and renewable energy and renewable fuels derivatives, amongst others. Contrary to sustainability-linked derivatives, the use of proceeds of ESG-related derivatives are allocated to specific ESG-related purposes. For example, emissions trading is a market-based approach to reduce pollution by setting a (geographical) limit on the amount of greenhouse gases that can be emitted. It consists of a limit or cap on pollution and tradable instruments that authorize holders to emit a specific quantity of the respective greenhouse gas. Market participants can trade derivatives based on emission allowances on exchanges or OTC markets as spots, forwards, futures and option contracts. The market consists of mandatory compliance schemes and voluntary emission reduction programs.

Renewable energy and fuel derivatives

Another type of ESG-related derivatives are renewable energy and renewable fuel hedging transactions, which are a valuable tool for market participants to hedge risks associated with fluctuations in renewable energy production. These ESG-related credit derivatives encourage more capital to be contributed to renewable energy projects. Examples are Power Purchase Agreements (PPAs), Renewable Energy Certificate (REC) futures, wind index futures and low carbon fuel standard futures.

ESG related credit derivatives

ESG-related CDS products can be used to manage the credit risk of a counterparty when financial results may be impacted by climate change or, more indirectly, if results are affected due to substitution of a specific product/service. An example of this could be in the airline industry where short-haul flights may be replaced by train travel. Popularity of ESG-related CDS products will probably increase with the rising perception that companies with high ESG ratings exhibit low credit risk.

Catastrophe and weather derivatives

Catastrophe and weather derivatives are insurance-like products as well. Both markets have existed for several decades and are used to hedge exposures to weather or natural disasters. Catastrophe derivatives are financial instruments that allow for transferral of natural disaster risk between market participants. These derivatives are traded on OTC markets and enable protection from enormous potential losses following from natural disasters such as earthquakes to be obtained. The World Bank has designed catastrophe swaps that support the transfer of risks related to natural disasters by emerging countries to capital markets. An example if this is the swap issued for the Philippines in 2017. Weather derivatives are financial instruments that derive their value from weather-related factors such as temperature and wind. There derivatives are used to mitigate risks associated with adverse or unexpected weather conditions and are most commonly used in the food and agriculture industry.

What’s old, what’s new and what’s next?

ESG-related credit derivatives would be best applied by organizations with credit exposures to certain industries and financial institutions. Despite the link to an environmental element, we do not consider catastrophe bonds and weather derivatives as a sustainability-linked derivative. Neither is it an innovative, new product that is applicable to corporates in various sectors.

Truly innovative products are sustainability-linked derivatives, voluntary emissions trading and renewable energy and fuel derivatives. These products strengthen a corporate’s commitment to meet sustainability targets or support investments in sustainable initiatives. A lack of sustainability regulation for derivatives raises the question to what extent these innovative products are sustainable on their own? An explicit incentive for financial institutions to execute ESG-related derivatives, such as a capital relief, is currently absent. This implies that any price advantage will be driven by supply and demand.

Corporate Treasury should ensure they consider the implications of using ESG-related derivatives that affect the cashflows of derivatives transactions. Examples of possible regulatory obligations consist of valuation requirements, dispute resolution and reporting requirements. Since ESG-related derivatives and products are here to stay, Zanders recommends that corporate treasurers closely monitor the added value of specific instruments, as well as the regulatory, tax and accounting implications. Part II of this series, later in the year, will focus on the regulatory and valuation implications of this relatively new derivative class.

For more information on ESG issues, please contact Sander van Tol.

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.

Whilst over the previous years, many corporates have endeavoured to move towards a single ERP system. There are many corporates who operate in a multi-ERP landscape and will continue to do so. This is particularly the case amongst corporates who have grown rapidly, potentially through acquisitions, or that operate across different business areas. SAP’s Central Finance caters for centralized financial reporting for these multi-ERP businesses. SAP’s APM similarly caters for businesses with a range of payment sources, centralizing into a single payment channel.

SAP APM acts as a central payment processing engine, connecting with SAP Bank Communication Management and Multi-Bank Connectivity for sending of external payment Instructions. For internal payments & payments-on-behalf-of, data is fed to SAP In-House Cash. Whilst at the same time, data is transmitted to S/4 HANA Cash Management to give centralized cash forecast data.

Figure 1 – SAP S/4 HANA Advanced Payment Management – Credit SAP

The framework of this product was built up as SAP Payment Engine, which is used for the processing of payment instructions at banking institutions. On this basis, it is a robust product, and will cater for the key requirements of corporate payment hubs, and much more beyond.

Building a business case

When building a business case for a centralized payment hub, it is important to look at the full range of the payment sources. This can include accounts payable/receivable (AP/AR) payments, but should also consider one-off (manual) payments, Treasury payments, as well as HR payments such as payroll. Whilst payroll is often outsourced, SAP APM can be a good opportunity to integrate payroll into a corporate’s own payment landscape (with the necessary controls of course!).

Using a centralized payment hub will help to reduce implementation time for new payment sources, which may be different ERPs. In particular, the ability of SAP APMs Input Manager to consume non-standard payment file formats helps to make this a smooth implementation process.

SAP APM applies a level of consistency across all payments and allows for a common payment control framework to be applied across the full range of payment sources.

A strength of the product is its flexible payment routing, which allows for payment routing to be adjusted according to the business need. This does not require specialist IT configuration or re-routing. It enables corporates to change their payment framework according to the need of the business, without the dependency on configuration and technology changes.
A central payment hub means no more direct bank integrations. This is particularly important for those businesses that operate in a multi-ERP environment, where the burden can be particularly heavy.

Lastly, as with most SAP products, this product benefits from native integration into modules that corporates may already be using. Payment data can be transferred directly into SAP In-House Cash using standard functionality in order to reflect intercompany positions. The richest level of data is presented to S/4 HANA Cash Management to provide accurate and up-to-date cash forecast data for Treasury front office.

Scenarios

SAP APM accommodates four different scenarios:

A Working Example – Payment-on-behalf-of

An ERP sends a payment instruction to the APM system via iDoc. This is consumed by the input manager, creating a payment order that is ready to be processed.

Figure 3 – Creation of Incoming Payment Order in APM

The payment order will normally be automatically processed immediately upon receipt. First the enrichment & validation checks are executed, which validate the integrity of the payment Instruction.

The payment routing is then executed for each payment item, according to the source payment data. The Payment Routing importantly selects the appropriate house bank account for payment and can be used to determine the prioritization of payments, as well as the method of clearing.

In the case of a payment-on-behalf-of, an external route will be used for the credit payment item to the third party vendor, whilst an internal route will be used to update SAP In-House Cash for the intercompany position.

Figure 4 – Maintenance of Routes

Clearing can be executed in batches, via queues or individual processing. The internal clearing for the debit payment item must be executed into SAP In-House Cash in order to reflect the intercompany position built up. The internal clearing for the credit payment Item can be fed into the general ledger of the paying entity.

Figure 5 – Update of In-House Cash for Payment-On-Behalf or Internal Transfer Scenarios

Outgoing payment orders are created once the routing & clearing is completed. At this stage, any further enrichment & validation can be executed and the data will be delivered to the output manager. The output manager has native integration with SAP’s DMEE Payment Engine, which can be used to produce an ISO20022 payment instruction file.

Figure 6 – Payment Instruction in SAP Bank Communication Management

The outgoing payment instruction is now visible in the centralized payment status monitor in SAP Bank Communication Management.

The full processing status of the payment is visible in SAP APM, including the points of data transfer.

Figure 7 – SAP APM Process Flow

Introduction to Functionality

SAP APM is comprised of 4 key function areas:

• Input manager & output manager
• Enrichment and validation
• Routing
• Transaction clearing

Figure 2 – SAP Advanced Payment Management Framework – Credit SAP

Input Manager

The input manager can flexibly import payment instruction data into APM. Standard converters exist for iDoc Payment Instructions (PEXR2002/PEXR2003 PAYEXT), ISO20022 (Pain.001.01.03) as well as for SWIFT MT101 messages. However, it is possible to configure new input formats that would cater for systems that may only be able to produce flat file formats.

Enrichment and Validation

Enrichment and validation can be used to perform integrity checks on payment items during the processing through APM. These checks could include checks for duplicate payment instructions. This feeds an initial set of data to S/4 HANA Cash Management (prior to routing) and can be used to return payment status messages (Pain.002) to the sending payment system.

Routing

Agreement-based routing is used to determine the selection of external accounts. This payment routing is highly flexible and permits the routing of payments according to criteria such as amounts and, beneficiary countries. The routing incorporates cut-off time logic and determines the priority of the payment as well as the sending bank account. This stage is not used for “forwarding-only” scenarios, where there is no requirement to determine the subsidiaries house bank account in the APM platform.

Clearing

Clearing involves the sending of payment data after routing to S/4 HANA Cash Management, in-house cash and onto the general ledger. According to selected route, payments can be cleared individually, or grouped into batches.

Further enrichment & validation can be performed, and external payments are routed via the output manager, which can re-use DMEE payment engines to produce payment files. These payment files can be monitored in SAP Bank Communication Management and delivered to the bank via SAP Multi-Bank Connectivity.

But one stumbling block was left in the design: each bank account master requires a dedicated set of general ledger (G/L) accounts, on which the balances are reflected (the master account) and through which transactions are posted (clearing accounts). Very often organizations define unique GL account for each house bank account (alternatively, generic G/L accounts are sometimes used, like “USD bank account 1”), so creation of a new bank account in the system involves coordination with two other teams:

1. Financial master data team – managing the chart of accounts centrally, to create the new G/L accounts
2. IT support – updating the usage of the new accounts in the system settings (clearing accounts)

Due to this maintenance process dependency, even with the new BAM, the creation of a new house bank account remained a tedious and lengthy process. Therefore, many organizations still keep the house bank account management within their IT support process also on S/4HANA releases, negating the very idea of BAM as master data.

To overcome this limitation and to put all steps in the bank account management life cycle in the ownership of the treasury team completely, in the most recent S/4HANA release (2009) SAP has introduced a new G/L account type: “Cash account”. G/L accounts of this new bank reconciliation account type are used in the bank account master data in a similar way as the already established reconciliation G/L accounts are used in customer and vendor master data. However, two new specific features had to be introduced to support the new approach:

• Distinction between the Bank sub account (the master account) and the Bank reconciliation account (clearing account): this is reflected in the G/L account definition in the chart of accounts via a new attribute “G/L Account Subtype”.
• In the bank determination (transaction FBZP), the reconciliation account is not directly assigned per house bank and payment method anymore. Instead, Account symbols (automatic bank statement posting settings) can be defined as SIP (self-initiated payment) relevant and these account symbols are available for assignment to payment methods in the bank country in a new customizing activity. This design finally harmonizes the account determination between the area of automatic payments and the area of automatic bank statement processing.

In the same release, there are two other features introduced in the bank account management:

• Individual bank account can be opened or blocked for posting.
• New authorization object F_BKPF_BEB is introduced, enabling to assign bank account authorization group on the level of individual bank accounts in BAM. The user posting to the bank account has to be authorized for the respective authorisation group.

The impact of this new design on treasury process efficiency probably makes you already excited. So, what does it take to switch from the old to the new setup?

Luckily, the new approach can be activated on the level of every single bank account in the Bank account management master data, or even not used at all. Related functionalities can follow both old and new approaches side-by-side and you have time to switch the bank accounts to the new setup gradually. The G/L account type cannot be changed on a used account, therefore new G/L accounts have to be created and the balances moved in accounting on the cut-over date. However, this is necessary only for the G/L account masters. Outstanding payments do not prevent the switch, as the payment would follow the new reconciliation account logic upon activation. Specific challenges exist in the cheque payment scenario, but here SAP offers a fallback clearing scenario feature, to make sure the switch to the new design is smooth.

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!

Business margin protection

ARF can be a very efficient hedging instrument when the business margin needs to be protected, namely in the following business scenarios:

• Budgeted sales revenue or budgeted costs of goods sold are incurred with reliable regularity and spread evenly in time. This exposure needs to be hedged against the functional currency.
• The business is run in separate books with different functional currencies, FX exposure is determined and hedged against the respective functional currency of these books. Resulting margin can be budgeted with high degree of reliability and stability, is relatively small and needs to be hedged from the currency of the respective business book to the functional currency of the reporting entity.

Increased complexity

Hedging such FX exposure with conventional FX forwards would lead to a very high number of transactions, as well as data on the side of underlying FX exposure determination, resulting in a data flood and high administrative effort. A hedge accounting according the IFRS 9 rules is almost impossible due to high number of hedge relationships to manage. The complexity increases even more if treasury operations are centralized and the FX exposure has to be concentrated via intercompany FX transactions in the group treasury first.

If the ARF instruments are not directly supported by the used treasury management system (TMS), the users have to resort to replicating the single external ARF deal with a series of conventional FX forwards, creating individual FX forwards for each fixation date of the observation period. As the observation periods are usually long (at least 30 days) and rate fixation periodicity is usually daily, this workaround leads to a high count of fictitious deals with relatively small nominal, leading to an administrative burden described above. Moreover, this workaround prevents automated creation of deals via an interface from a trading platform and automated correspondence exchange based on SWIFT MT3xx messages, resulting in a low automation level of treasury operations.

Add-on for SAP TRM

Currently, the ARF instruments are not supported in SAP Treasury and Risk management system (SAP TRM). In order to bridge the gap and to help the centralized treasury organizations to further streamline their operations, Zanders has developed an add-on for SAP TRM to manage the fixing of the average rate over the observation period, as well as to correctly calculate the fair value of the deals with partially fixed average rate.

The solution consists of dedicated average rate FX forward collective processing report, covering:

• Particular information related to ARF deals, including start and end of the fixation period, currently fixed average rate, fixed portion (percentage), locked-in result for the fixed portion of the deal in the settlement currency.
• Specific functions needed to manage this type of deals: creation, change, display of rate fixation schedule, as well as creating final fixation of the FX deal, once the average rate is fully calculated through the observation period.

Figure 1 Zanders FX Average Rate Forwards Cockpit and the ARF specific key figures

The solution builds on the standard SAP functionality available for FX deal management, meaning all other proven functionalities are available, such as payments, posting via treasury accounting subledger, correspondence, EMIR reporting, calculation of fair value for month-end evaluation and reporting. Through an enhancement, the solution is fully integrated into market risk, credit risk and, if needed, portfolio analyser too. Therefore, correct mark-to-market is always calculated for both the fixed and unfixed portion of the deal.

Figure 2 Integration of Zanders ARF solution into SAP Treasury Transaction manager process flow

The solution builds on the standard SAP functionality available for FX deal management, meaning all other proven functionalities are available, such as payments, posting via treasury accounting subledger, correspondence, EMIR reporting, calculation of fair value for month-end evaluation and reporting. Through an enhancement, the solution is fully integrated into market risk, credit risk and, if needed, portfolio analyser too. Therefore, correct mark-to-market is always calculated for both the fixed and unfixed portion of the deal.

Zanders can support you with the integration of ARF forwards into your FX exposure management process. For more information do not hesitate to contact Michal Šárnik.

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:

• Virtual Account Concepts | How to setup virtual accounts in SAP, Part II
• Why should a Treasury implement virtual accounts? | How to setup virtual accounts in SAP, Part I