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.

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.

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.

E-banking

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

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:

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.

EBICS

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.