Managing Advanced Payment Management (4MT)

Payments are typically initiated in local systems of the affiliates, subsidiaries or lines of business. These local system can be SAP or non-SAP and can be on-premise or cloud solutions. Therefore their capabilities to handle payments in a flexible way might be more sophisticated or less, but they certainly do not provide a centralized view of global cash positions or status monitoring and typically do not provide features to handle exceptions or to optimize payment execution including bank determination. In the SAP reference architecture all systems of such a heterogenous landscape submit their payment to a centralized payment factory (SAP S/4HANA Finance for advanced payment management). This can be achieved using web services (APIs), IDocs, or even physical files.

In advanced payment management the payments are converted to an internal format and are processed based on the configured rules potentially resulting in updates to SAP Cash Management, postings to GL, or even SAP In-House Cash. During processing the solution leverages the bank account management information to determine the bank to be used and triggers the final approval via Bank Communication Management. Once approved the external payment format is generated, leveraging DMEEX, and is passed via the standard integration to SAP Multi-Bank Connectivity. The bank integration via SAP Multi-Bank Connectivity is fully API-based and therefore adds another layer of security and removes batch processes for file-based integration.

SAP S/4HANA Finance provides functionality to process four different types of payment scenarios. Two of the them are related to the payments in name of setup.

The subsidiary sends a payment with one or more beneficiary transactions and already fully specifies how this should be executed and which bank account should be used. In this scenario advanced payment management can validate the payment information and might enrich missing information, but does not optimize the bank account determination or how a payment is batched. Cash Management is updated and after the final approval the external format is generated, which might be different to what the subsidiary initially provided.

Select the play button to watch the video on of a forwarding scenario in the SAP S/4HANA Cloud, public edition.

Companies looking for a payment factory can have multiple drivers. Some just want to centralize payment processes from a visibility perspective, some would like to optimize payment processes, and some focus on the entire automation of the payment process. All in all these are some of the main benefits of running a central payment factory based on SAP S/4HANA.

Payment centralization is the key step towards lowering cost for payment execution, optimizing payment processing, and increasing cash visibility. With this solution you gain full flexibility to centralize all payments including payments in name of, payments on behalf of, and internal payments in one solution. The focus is to bring companies into a position to be able to quickly change payment processes based on master data settings instead of technical configuration.

Payments are moving quickly towards being real-time, which requires a system that is able to interact with the bank integration channel like SAP Multi-Bank Connectivity in real time. The SAP payment factory supports real-time processing, but it also provides user interfaces to trigger real-time actions allowing a business user to easily request a cancellation of a payment, reprioritize payments ad hoc, or prevent payments to go out in the case of a critical situation of a bank, currency, or country.

To lower rejection rates from banks, companies can validate payments already in the payment factory. During validation erroneous payments (such as incorrect IBAN or BIC code) and duplicates can be detected before the payments are submitted to the bank. To increase data quality, missing information can be enriched to increase the STP rates at the bank and therefore reduce costs reduce.

Payment volumes are significantly increasing, specifically in the B2C business. SAP S/4HANA Finance for advanced payment management is prepared to manage high-volumes of payments in all payment scenarios, and also covering classical scenarios with FI-CA as the initiating system.

SAP S/4HANA Finance for advanced payment management can handle error situations in a very flexible way. If an error is detected in the solution or a bank rejects a payment, the error situation can either be handled manually via a repair function, or handled completely automatically by reversing payments and informing the respective subsidiary or applying automatic corrections which are determined based on machine learning and earlier manual corrections. During manual repair, users can either change certain attributes or change other settings and reprocess payments without the need to reverse the entire process flow.

To provide full visibility, SAP provides various levels of information within the payment factory. You can view detailed information on a single transaction and its entire lifecycle, visualized in a graphical process flow. The solution also provides high-level monitors of all payments and their statuses, leading towards analytical apps which allow business users to execute ad-hoc queries on the payments executed in the system. The analytical apps provide insights into questions such as how many transactions have been executed towards a specific bank (account), in which currency, or by which payment instrument, based on a snapshot or throughout a period of time.

A centralization really makes sense if it is easy to integrate with the central system and you increase the level of automation. This is fully achieved by implementing advanced payment management as the solution has an open architecture allowing subsidiaries to integrate via various channels with the solution. Other non-SAP solutions can also be easily integrated based on an API layer which has predefined integrations to SAP solutions, and can also work with third-party products integrated into the payment process.

A cornerstone of optimizing payment processing is adding flexibility to the payment routing. With the solution this payment routing is based on a flexible ruleset defined as master data. Users can define simple rules based on attributes of a payment like currency, payment type, and beneficiary bank, and rules can also include more sophisticated attributes like cut-off times, available amounts, percentage of business/share of wallet, and so on.

In an heterogeneous system landscape it becomes very challenging to keep each system up to date to generate the bank-specific payment format locally. Based on that, SAP's approach is to generate the target payment format in a central payment factory leveraging the information provided in the original payment format which has be sent to SAP S/4HANA Finance for advanced payment management, potentially with real-time lookups into the local systems for enrichment if required. With this the company has full control over the payment format generation, but only has one central place where the conversion takes place. For the format generation the standard mechanism via DMEEX is used. This is integrated into the solution.

Payment processing needs to be automated as much as possible. Within the solution the entire payment process can be automated, including rerouting and reacting to exceptions, which leverages machine-learning-based automatic repair functionalities.

In a heterogeneous corporate system landscape of payment initiating systems, advanced payment management offers strong integration capabilities. This includes integration with subsidiaries systems, fraud and sanction list screening applications, bank account management, cash management, and bank integration channels.

Subsidiary runs an automatic payment run (F110) creating an outbound message to one determined external bank account. The paid items are cleared out by an FI posting.

• Transfer of outbound message (XML, IDoc, CSV, and so on) to payment factory via web service, ALE, or physical file
• Input manager of the payment factory converts inbound format into a meta format representing the payment
• (Optional) approval workflow
• Enrichment & Validation (E&V)
  • Validate payment correctness (for example, detect duplicates, validate data, or validate internal cut-off times)
  • Enrich missing data (such as subsidiary specific processing rules or BIC codes)
  • Return status message for received payment message/file to subsidiary (such as PAIN.002)

• Routing

  • Option 1: Forward payment as is to house bank (no rebulking, no bank account determination)
  • Option 2: Regroup and/or reroute payments to accounts of subsidiary (PINO)
  • Option 3: Regroup and/or reroute payments to central group accounts (POBO)
  • Option 4: Internal Transfer
  • Retrieve and validate bank account details maintained in BAM (Bank Account Management)

• Clearing

  • Update of Cash Management flows
  • In case of rerouting - update accounting/in-house bank

• Outgoing enrichment and validation

  Payment release/authorization via SAP Bank Communication Management

• Output Manager

  • Create target payment format leveraging existing DMEE trees
  • Trigger bank communication directly via SAP Multi-Bank Connectivity

This decision tree shows which actions are triggered towards Cash Management, General Ledger, and In-house Cash for each payment scenario.

1. In the scenario of a Payment in Name of - Forwarding, the solution just triggers an update to central Cash Management for the debit towards the defined house bank account.
2. In the scenario of a Payment in Name of - Routing, postings are triggered as the payment factory optimizes when and from where a payment is executed. Typically the initiator of the payment defined in the subsidiary system is just a routing account which is posted by a payment run in the sending system. In the payment factory this account is balanced again with the debit side of the payment order. After routing all transactions, the external credits determined their house bank account from which they will get paid and post individually to the assigned clearing account of that house bank account in General Ledger.
3. In the scenario of an Internal Payment, both sides of a payment order in advanced payment management are posted to In-House Cash to represent the internal movement of funds. This is done via two separate IHC payment orders triggered by advanced payment management which is always balanced to an internal clearing account to handle internal reconciliation.
4. In the scenario of a Payment on Behalf of, the debit side of a credit transfer representing the initiator is posted to In-House Cash to handle the movement of funds from the subsidiary to the headquarters. The external recipient transactions determine their house bank account via routing and finally post to the assigned bank clearing account in General Ledger.

In general, all postings triggered by advanced payment management can be configured as individual postings or as bulk/consolidated postings.

Note

In the current SAP S/4HANA Cloud version, only the Payment in the Name of is supported.

Integration of subsidiary systems (SAP or non-SAP) can be done via the following methods:

• Web service (SAP Multi-Bank Connectivity Service)
• IDoc
• File

For the three channels, there is the possibility of online or batch execution of the imported payments.

• Conversion from any format into a central meta format aligned with ISO20022 and an ISO20022 representation
• Code-based mappings leveraging an internal framework
• Multiple formats pre-delivered, such as ISO20022 and MT101

The Input Manager receives the payment formats from the incoming channel and maps the external format to an internal meta-format and an ISO20022 representation.

The input format converter is determined based on the following attributes:

• Format: Which format is sent, for example ISO, MT, or CSV
• Medium: How a payment is received, for example, file (loaded from application or local server), Multi-Bank Connectivity, user interface, or internally created payment
• Channel: Which system initiated the message, for example, subsidiary ERPs, Financial Accounting, Human Resources, Treasury Management System, internal, or in the case of status messages, the bank.

The Manual Upload of Payment Files with Incoming Payments feature allows you to upload payment files manually to Advanced Payment Management. This enables the integration of incoming payments initiated from the systems that are not fully integrated with Advanced Payment Management or where the monthly volume of payments does not justify automated processes.

In the Manage Incoming Payment Files app on your SAP Fiori launchpad, choose the option Payment File for Advanced Payment Management to import a file.

Once the file is uploaded, you can display general information and log details for the upload.

This way, your company gets full visibility on all payments, irrespective of the source and volume of the payments.

The mapping of incoming customer-specific formats can be done in the following two ways:

• The external format is mapped directly to the meta format of SAP S/4HANA Finance for advanced payment management. This requires that this meta format is well known to the customer or the partner implementing a customer-specific mapping.
• The external format is mapped to an ISO 20022 (PAIN.001 for credit transfers or PAIN.008 for collections). In the next step, the embedded transformation from ISO 20022 to the internal meta format is triggered. In this setup, the customer or partner only needs to know how the fields of the customer-specific format are represented in an ISO 20022 format which is a well-known standard in the payments industry.

You can also combine these two approaches. This means that a few attributes can be mapped directly to the meta format and the rest are mapped via the internal ISO 20022.

Leveraging the converter framework of advanced payment management, customers get out-of-the-box schema validation and automatic handover to exception control for assigned objects. Processing of large files is done via flexible parallel processing.

The framework works based on an internal XML structure which also works perfectly for plain text files. In that scenario, a simple transformation of a text file into an XML representation is required. For this, a so-called text adapter needs to be defined. This moves the various fields of a text file into an XML representation. For an example, see the MT101 converter that is delivered with the product in standard.

Business objects resulting from an inbound conversion are mostly payment order and payment items.

All related business objects of a payment order are mutually referenced.

An incoming file is represented by an object list (OL). As a file could contain multiple payment orders (POs), those all reference the object list. In a payment order, there is always at least one ordering item (ORP) and one or many recipient party item(s) (RCPs).

If an incoming payment file or message contains multiple currencies, a payment order will contain multiple ordering items – one per currency.

The inbound format can be validated for correctness (such as fields missing or values not permitted). Errors detected during conversion are collected and logged at the affected business object.

Some examples of errors include the following:

• Incorrect formatting of fields
• Incorrect characters
• Missing mandatory fields
• Invalid combination of fields

The transfer to exception handling is triggered in the enrichment and validation component. Field-specific validations such as validation of a BIC code can be performed in specific field checking routines in enrichment and validation and are not executed during format conversion already.

The original format is stored with the payment in the internal format in SAP S/4HANA Finance for advanced payment management. The File Handler database (FHDB) is filled with data from the original incoming format and an ISO20022 representation.

The inbound format converter converts only the necessary data of the imported payment to the internal meta-format of the solution. The Input Manager uses the FHDB to store data that is not required for further processing of the payment transactions, but maybe for later outbound format generation. The data stored in FHDB can be displayed any time via the user interface in order to investigate what has been sent originally.

Once a payment is ready to be sent out, the Output Manager converts the processed information to the target format and adds the data stored in the ISO20022 representation to the outgoing payment if required. FHDB ensures that no information is lost during conversion.

Payments created in the solution can be validated and enriched using pre-defined validations like checking for duplicates, validating account information, or validating submission cut-off times. Alternatively, payments can be validated and enriched using entirely new checks added by customers based on extensions.

Checks can reach out to external applications like SAP Business Integrity Screening or non-SAP systems.

Checking can be synchronous or asynchronous. If checking is asynchronous the respective payment is parked until a response is received.

Checks can raise functional errors which are passed to exception handling once all checks are executed

Checks are clustered into the following groups:

• Payment order checks
• Ordering item checks
• Recipient item checks
• Cross-item checks.

In addition, this component can be used to trigger status notifications or correspondences (such as email) to sending subsidiaries on their payments to inform the sending organization that a payment has been received, processed successfully, rejected, or similar.

One specific check in the component creates a first, unqualified, cash management update which is already done before the actual bank account is known.

Checks are assigned to check sets which are determined for each object to be checked during enrichment and validation.

The check set for payment orders and the cross-item check set are found via the payment order type on the basis of the Customizing activities Define Payment Order Group for E&V and Maintain Enrichment and Validation Sets for Order Types. A payment order type is assigned to a payment type group for enrichment and validation. This type group could be used to distinguish between different check sets.

The check set for ordering items and recipient items is determined via the transaction type on basis of the Customizing activities Transaction Types and Transaction Type Groups and Maintain Enrichment and Validation Set for Payment Items. A transaction type is assigned to a transaction type group for enrichment and validation. This type group could be used to distinguish between different check sets.

In simple scenarios you can just define one common check set per object type which allows you to skip the configuration of a payment order type group or transaction type group for enrichment and validation.

Process description in more detail:

1. The system reads the payment orders that are pending processing in Payment Engine.
2. The system determines the service level agreement (SLA) based on the default bank code number and the account number in the ordering party item of the payment order.
3. The system enriches the payment order with the required information for the clearing area SLA and performs the necessary formal and material checks.
4. The system checks whether a corresponding customer SLA, customer group SLA, or customer segment SLA exists.

   If a match is found, the system:

   1. Performs the necessary formal and material checks that are defined in the customer SLA, customer group SLA, or customer segment SLA.
   2. Enriches the payment order or payment item with the required information.
5. The system determines the processing program.

   You can define that the system runs standard checks and special checks on payment orders and payment items in Customizing based on the payment order type and on the transaction types of the individual payment items.

6. The system performs validation checks in the following sequence:
   1. Payment order checks

      The system checks the payment order based on the processing program that was determined in step 5. If the system detects any errors, it flags the payment order with an individual error and continues checking the payment order.

   2. Ordering party item checks
      • If the system successfully checks the payment order or if no errors were detected, the system checks the original unsplit ordering party item.
      • If the system detects any errors, it flags the ordering party item with an individual error and continues checking the ordering party item. It is therefore not possible to transfer the complete payment order to Exception Control based on the errors detected in the ordering party item.
   3. Recipient item checks
      • The system validates the recipient items of the payment order only if no severe errors have occurred in the process so far.
      • If the system detects any errors, it flags the recipient item with an individual error and continues checking the recipient item.
   4. Cross-item checks

      The system cross-validates all payment item types.

7. The system transfers the ordering party items of successfully validated payment orders to Routing Control, provided that the execution date of a payment order is not in the future.

The results of the validation checks are listed in the logs of the corresponding business objects:

• The results of payment order checks and cross-item checks are listed in the log of the payment order.
• The results of checks on ordering party items and recipient items are listed in the corresponding payment item logs.

SLAs are agreements/contracts between the central payment factory and the participating subsidiaries (its customers) that define various conditions for senders of payments. SLAs have the following features:

• SLAs can be defined at the customer level for subsidiaries with special conditions when it comes to the payment services they use. Some subsidiaries may not have special conditions, thus they do not need individual SLAs.
• For such customers segment SLAs (such as North American or European subsidiaries) or customer group SLAs can be defined. If even these are not required, there is a general SLA for all participants.
• Settings of the SLAs are integrated in enrichment and validation checks.
• Should any condition of a matching SLA not be fulfilled, the validations automatically trigger exception handling to evaluate the preferred reaction to the error situation.

You can define the following settings for SLAs:

• Splitting of payment orders (create one-to-one payment orders per transaction for an original bulk payments)
• Duplicate checking
• Required correspondences
• Requested status notifications
• Submission cut-off times (validation and/or adjustments)
• Allowed submission of formats, payment types, amounts, and so on
• Threshold handling for transaction errors triggering a payment batch error
• Allowed/disallowed target countries

These settings use (in most cases) rulesets which provide a high level of flexibility.

There is a clear hierarchy in the SLAs that are determined for payment items which is applied to all the attributes checked in the process of enrichment and validation. The root of the hierarchy is the clearing area SLA. The highest level in the hierarchy is the customer SLA where limits and attributes are defined specifically for the customer (a customer in this case is an affiliate participating in the payment factory).

The hierarchy is applied for all the values maintained on the SLA. If for a specific SLA level no matching entry is found, the next lower-level SLA category is considered. If for example no customer SLA is found, the customer group SLA is checked.

Routing payments to banks and bank accounts is based on configured business rules (master data).

Business rules can use all attributes of a payment like amount, currency, country, payment type, and priority, and additional attributes like time and percentage distribution of payments.

The following options are available for routing:

• Forward payment as is to the predefined bank (no rebulking, no bank account determination)
• Regroup and/or reroute payments to accounts of subsidiary (PINO)
• Regroup and/or reroute payments to central group accounts (POBO)

Determined clearing agreement defines rules like the type of transaction (single or bulk), target payment format, accounting rules, cut-off times, and so on.

Configured bank accounts are retrieved from Bank Account Management (BAM) and a linked to a certain clearing agreement.

Within routing there are two main master data objects: routes and clearing agreements.

A route is a master data object that indicates whether a payment item is to be posted internally or externally. Internal routes point towards an accounting system like GL or IHC. External routes can be assigned to a company code and/or a specific bank account and act as a grouping of clearing agreements.

In the route determination an appropriate route is found and attributed for each payment item using corresponding checks against a rule set.

A route can also be locked to prevent outgoing payment orders within this route from being sent out (for example, to stop all payments for company code 1000). Payment items in a locked route are not released via this route and are retained in a waiting status in a queue until they are explicitly (manually) released.

Multiple routes can lead to the same account management system and can be used just as grouping criteria.

A clearing agreement (CA) contains all the information that are necessary for further processing of the transactions.

One clearing agreement always belongs to one route and like the route, it is either internal or external. In an internal route there are only internal clearing agreements, and in an external route only external clearing agreements.

Clearing agreements can be locked to disable further processing. However, an alternative clearing agreement can be defined on the locked clearing agreement to allow further processing.

One route can have one or many clearing agreement(s).

In the example Route 1 has two clearing agreements leading to the same Account Management system. The difference could be a different way of processing defined in the clearing agreements (for example, bulk posting and single transaction posting). Every clearing channel or corresponding bank has one or more clearing agreements defined in SAP S/4HANA Finance for advanced payment management.

In order to determine a route and clearing agreement, rules with rule sets need to be defined. These rule sets are also used in other areas of the product and behave the same way. Rules are analyzed in a defined way, from top to bottom.

On the basis of payment order and payment item information, routes, clearing agreements, or other settings are determined for a payment item.

The following operators are defined for this:

• Equality operators
• Interval check
• Pattern matching (with so called wildcards „+" and „*")
• Comparisons operators (=, ≥, ≤, >, <, ≠)
• List membership check (several comparison values can be used within an individual rule)

The following additional features are available:

• Meta-format-based rules
• Activation/deactivation of rules
• Rule validity timeframes

Each rule consists of a set of attributes which are typically rule-set-specific. Generally, all attributes of the meta format can be used to define the rules within a rule set. If the meta format is enhanced during the implementation project, the customer can integrate customer-specific fields or attributes in the rule sets. A rule matches if all attributes of an object are matching the attributes of the rule. As soon as the first matching rule has been found, the search is finished and the result (business object) is assigned to the payment item.

The table above details all 7 scenarios available in clearing.

Payment batches or queues can have the following different functional statuses:

• Open: Items can be added to the payment batch/queue
• Closed: No new items can be added to that specific payment batch
• Processed: Outgoing order is generated and posting to clearing account is performed

There are other intermediary statuses like In Processing which are not visible during processing or in error situations.

In case of bulking payment items, the separation criteria, defined at clearing agreement level, are taken into account. These define for which items specific payment batches have to be generated.

Examples of separation criteria are:

• Separation by credit/debit
• Separation by item types
• Separation by desired processing date
• Separation by priority

If an open payment batch or queue with the same separation criteria is available, the item is sent into this payment batch. If no corresponding payment batch or queue is available, a new one is generated.

To close a payment batch, these three automatic options exist. In addition, a payment batch can be closed manually.

In same cases it might be required to prioritize a transaction which currently is waiting to be sent out as a bulk payment or to assign it to another bank or bank account manually.

As long as a transaction is in an open payment batch, you can perform one of the following actions manually:

• Assign the transaction to another clearing agreement
• Send the transaction to routing again after the routing rules have been changed

The component clearing executes the settings determined in routing.

The following processing options are available:

• Direct clearing, typically for high priority payments or real-time payments
• Queue payments until a certain point in time, for example for timed/scheduled payments and to warehouse them in advanced payment management
• Bulk payments based on bank, account, currency, payment type, and so on, until a certain time, amount, or maximum number of transactions is reached

Once a payment transaction is released externally, posting to In-house Cash or General Ledger is triggered to update the bank or internal clearing accounts. In addition, the unqualified cash management update is set as inactive and is replaced by an update based on the posting to the bank clearing account.

Any functional or technical error throughout the lifecycle of a payment is attached to the payment batch or transaction and is passed to exception handling.

A reaction to an error is determined based on business rules, which can be based on the type of error, payment type, priority, amount, customer segmentation, or similar.

The following are examples of available reactions:

• Rejection/reversal
• Transaction rejection (including return posting)
• Manual repair via SAP Fiori app
• Automatic repair
• Retry
• Ignore
• Request for cancellation

Using the enhanced exception handling feature out of a central payment factory, you, as a business user, can be notified in case of payment issues.

Thereby, you have the chance to bring payment issues to the attention of the business user more quickly through improved exception handling out of a central payment factory, for instance:

• Negative payment status reports
• Internal error situations such as a screening hit on a sanctioned party list

With the Sanction Screening for Central Payment Factories feature you can assure a high degree of compliance by enabling the sanction screening feature out of a central payment factory. The sanction screening feature enables you to:

• Block the engagement with sanctioned parties for all payments irrespective of the system start-up status
• Make the payments only to the approved third parties
• Leverage the automated system-based screening that keeps compliance expenses at a minimum

There are two ways a payment is classified as a potential hit against the sanctions watchlist.

The first possibility is that the system identifies a certain recipient account holder that can be referenced to the watchlist. In this case, the payment is not directly processed.

The screening hitlist shows the recipient and also the percentage of a hit probability. You can manually set the item as hit and add a comment that this was changed and why, for example.

The second option is an automatic classification of the item through the SAP Cloud Watchlist Screening.

In this case, the payment gets rejected.

A recall or request for cancellation can be created throughout the process of single transactions or entire payment orders (incoming or outgoing).

Processing depends on the status of the payment order or the transaction.

The following options are available:

• Recall of an incoming payment order
  • Incoming order is not yet processed
    • Entire payment order is sent to exception handling
    • Typical reaction is to reject the order and inform the subsidiary, for example by creating PAIN.002 or sending an e-mail notification
  • Incoming order processed
    • Individual transactions can be recalled separately (configuration)
    • See recall of transactions
• Recall of an outgoing payment order
  • Outgoing order is not yet processed
    • Entire payment order sent to exception handling
    • Typical reaction is to trigger transaction reject for all items and inform the subsidiary, for example by creating PAIN.002 or sending an e-mail notification
  • Outgoing order sent out to bank

    CAMT.055, MT192 is generated and sent to the bank to request the bank to stop the payment

• Recall of a single transaction
  • Internal or external transaction is not yet posted/sent out
    • Transaction is sent to exception handling
    • Typical reaction is to trigger transaction reject and inform the subsidiary, for example by creating PAIN.002 or sending an e-mail notification
  • Internal transaction is posted
    • Transaction is sent to exception handling
    • Typical reaction is to trigger transaction reject
  • External transaction is sent out

    CAMT.055, MT192 is generated and sent to the bank to request the bank to stop the single transaction