Practical Guide to SAP Payment Runs with SAP S/4HANA

2.1 Classic payment reports in S/4HANA

In SAP, there are two different payment reports designed for processing payments, depending on the type of payment that needs to be made:

1. The standard payment report—in S/4HANA, this is the Schedule Automatic Payments Fiori app (app ID F110), which is identical to SAP GUI transaction code F110. This report is primarily used for payments to vendors and customers. The report selects payment-relevant items based on open items in Accounts Payable and Accounts Receivable.

2. The payment request report—in S/4HANA, this is the Automatic Payment Transactions for Payment Requests Fiori app (F111), the same as GUI transaction code F111. This app is typically used for more specialized payments, such as internal payments (e.g., Inhouse Cash) or when handling complex payment structures such as treasury transactions. This application enables single payments to be manually created without an existing purchase-related vendor posting, and also enables the settlement of G/L postings (e.g., bank-to bank transactions). F111 always selects the relevant items based on payment requests, which must be created beforehand (see Figure 2.1).

Figure 2.1: F110 and F111—a comparison

2.1.1 “Schedule Automatic Payments” app

If you do not have a specific payments or accounting role defined for the SAP Fiori launchpad, the easiest way to find the Schedule Automatic Payments app (GUI transaction F110) is to look for it by navigating to the search bar located at the top of the SAP Launchpad screen (see Figure 2.2).

Figure 2.2: Searching for the “Schedule Automatic Payments” app

This search bar can be found in the header section of the screen , and enables you to search for various apps and functions. In this example, we enter the old transaction code F110 or type in keywords such as schedule automatic payments.

Once you have entered the search query, you initiate the search by either clicking on the search icon (magnifying glass) next to the search bar or by pressing Enter on your keyboard. The system then displays the relevant results, listing any applications that match your query. Make sure that you are on the Apps tab to view the available applications.

Look for the app titled Schedule Automatic Payments in the search results, and click on that app tile to open it . You can then begin the process of scheduling automatic payments.

Let us now take a closer look at the app itself.

The app screen contains the Run Date and Identification fields and several tabs (see Figure 2.3). Before any parameters have been set up, the Status screen shows the message No parameters entered as yet. Note that the screen is quite empty at the top.

Figure 2.3: “Schedule Automatic Payments” app—entry view

First, fill in the Run Date and Identification fields. Contrary to what many SAP users believe, a payment run’s run date and ID only play a minor role in the payment run itself.

The Run Date impacts the suggested posting date on the Parameter tab. However, this date can still be manually adjusted before proceeding—the significance of this Run Date is therefore limited because it is merely an initial suggestion, and not necessarily the final date for the actual payment run itself.

The primary purpose of the Run Date field is to catalog all the payment runs. The Identification field enables you to distinguish between multiple payment runs on the same day.

“Parameter” tab

You can now define the settings that are entered on the Parameter tab, as shown in Figure 2.4.

Figure 2.4: “Parameter” tab

The Posting Date and the Docs Entered up to fields are influenced by the previously defined Run Date. They initially default to the run date entered on the status tab, but can be adjusted as needed. This is particularly important if you need to post the payment documents on a different posting date or include/exclude documents which were created on specific dates.

The Customer Items Due By date is optional. With this field, you can control the due date up to which outstanding items from customers should be considered in this payment run. This is particularly useful for direct debits, because it enables the inclusion of documents in the payment run that might not yet be due. This ensures that payments are credited to the account on time, maintaining a smooth cash flow and preventing any delays in payment processing.

In the Payment Control section you have the ability to limit the Company Codes that will be included in payment processing. You can instruct payments for one or more Company Codes in a single run. Under Pmt Meths, you can define the payment method(s) to be used in the payment run.

Note that SAP selects payment methods based on the order they are entered.

The Next PstDate (next posting date) is important for determining due dates. This date is used by the SAP system to decide whether a payment needs to be settled in the current payment run or if it should be paid in the next payment run. The calculation also includes any discounts that apply, which are managed via the customizing options in the system.

Figure 2.5: Next posting date—example

In the Accounts section on the Parameters tab, you need to select the relevant customers and vendors for the payment run. Users often opt to select all accounts for both Supplier and Customer by entering the entire existing account number range because the SAP system will automatically assess which items are due. Alternatively, you can choose to specify individual accounts or account number ranges. Exclusion of specific accounts or account number ranges is also possible, providing greater control over transactions that need to be included in the payment run.

Finally, you need to save your settings by clicking on the Save Parameters button at the bottom of the screen .

“Free selection” tab

On the Free selection tab, you can apply a variety of filters (see Figure 2.6). These filters include fields from the document itself, such as Document Type or special general ledger indicators, and fields from the customer and vendor master data, such as the country. To help with field selection, the F4 help function ( icon) is also available .

Figure 2.6: “Free selection” tab—parameters

After selecting the fields, you can define the relevant Values which need to be considered for the payment run .

If necessary, you can exclude specific values by selecting the Exclude values checkbox . This gives you additional flexibility in defining the criteria for your payment run.

Finally, remember to save your settings by clicking on the Save Parameters button .

“Additional Log” tab

The Additional Log tab is probably the most underestimated in SAP’s payment run process (see Figure 2.7). It is often overlooked because the information entered on this tab does not directly affect the result of the payment run. If the selection process for the payment run works flawlessly, then generating this log is considered unimportant and is therefore rarely prioritized.

Figure 2.7: “Additional Log” tab

It is quite common for users to question why a specific item was not included in a payment run. In such cases, the Additional Log provides valuable information about the reason for the exclusion. Only in rare exceptions does the log fail to offer an explanation, which makes it a useful tool for troubleshooting and understanding the payment process. There are instances where a relevant item has not been selected by the payment run at all. In these cases, the payment run bypasses these items entirely, because they have been excluded by the system configuration.

To ensure you receive all the relevant information, you should always select the Due Date Check, Payment Method Selection in All Cases, and Line Items of the Payment Documents checkboxes (see in Figure 2.7).

In the Accounts required section , select the range by specifying an interval. This approach provides a comprehensive view of the payment process, enabling you to identify any issues or exclusions that might occur.

“Printout/data medium” tab

The Printout/data medium tab manages the output for payment files and forms (e.g., payment advice), that need to be generated (see Figure 2.8). This tab determines how the system handles the creation and distribution of payment data, based on the settings for the selected payment method.

Figure 2.8: “Printout/data medium” tab

For all PMW payment methods, the creation of payment media is managed via a different transaction (OBPM4) in the customization settings. More information on this can be found in Section 3.3.4.

For all other reports, a Variant must be maintained in this section. This ensures that the necessary settings and parameters are saved in order to consistently generate the required output.

The RFFOAVIS_FPAYM program is displayed for all PMW payment methods and must be filled in if payment advices are to be generated with the payment run. In addition, the functionality in business transaction events BTE 2040 and BTE 2050 provide options to set up email dispatch for these forms, which enhances the communication process associated with the payment run (further details can be found in Section 2.10).

If payment information needs to be transmitted via IDOC (intermediate document) to recipient company codes or systems, the RFFOEDI1 program can be used. This program facilitates the integration of payment data into external systems, thereby ensuring seamless communication and processing across different platforms.

This is particularly relevant for scenarios such as in-house cash bank or other cross-company code payments. These topics are very complex and therefore will not be covered further in this book.

2.1.2 Executing the payment proposal

After parameters for the payment run have been set up, you will see that the Status tab now shows the message Parameters have been entered, and extra buttons now appear at the top of the screen (see Figure 2.9). When all the necessary parameters have been configured, you can proceed to the next step in the payment run process—the payment proposal.

Click on the Proposal button on the Status screen.

Figure 2.9: Executing payment proposal

A new window will then open, as shown in Figure 2.10.

Figure 2.10: “Schedule Proposal” window

Enter the scheduling parameters. Payment proposals are typically executed immediately, so select the Start Immediately checkbox and then click on the Schedule button .

The proposal then starts running in the background and the Status tab shows the message Proposal is running (see Figure 2.11).

Figure 2.11 : Proposal running in the background

Depending on the volume of data being processed, it might take a a few minutes for the proposal to be completed.

Once the proposal run has finished, the status changes to Payment proposal has been created, and several new buttons appear at the top of the screen (see Figure 2.12).

Figure 2.12: “Status” screen—payment proposal created

It is recommended to review the proposal before proceeding with the final payment run. To do this, click the Display Proposal button.

The new window displays an overview of all the creditors and debtors relevant for this payment run, and their open items (see Figure 2.13). A color-coded system helps users quickly identify the statuses:

• Green indicates items that can be settled
• Red indicates items that cannot be settled

Figure 2.13: Proposal details

It is normal for some accounts to appear twice, because items are grouped by status—it is possible that some items for a creditor are able to be settled (green), while others will not be included in the payment run (red).

To view individual items and check for error messages, select the relevant line, and double-click on the Supplier account number.

You will then receive an overview of all the individual items for this supplier account with the same status.

Referring to Figure 2.14, double-click on the error message ID in the Err column, and an information window will open. The Note section of the new window shows the exact error message.

Figure 2.14: Proposal—checking open items

For a more detailed analysis of the entire proposal run, click on the Display Proposal Log button on the Status screen. The log is shown in Figure 2.15.

Figure 2.15: Proposal log

It is also possible to edit the proposal for example, you can exclude items from the payment run by setting a payment block. Click on the Edit Proposal button on the Status screen. You will be redirected back to a screen similar to the Display Proposal screen, but this time you can edit individual items.

2.1.3 Executing the payment run

After reviewing all the items, the payment run can be executed. To do this, click on the Payment run button on the Status screen, as shown in Figure 2.16.

Figure 2.16: Scheduling a payment run

A Schedule Payment window then opens. If the payment run is to be executed immediately, select the Start Immediately checkbox . To create a payment file with the payment run, you also need to select the Create Payment Medium option otherwise, you will just be clearing the open items and posting payment documents but not creating any file which can be forwarded to the bank to execute a real payment transaction there. Finally, click on the Schedule button to execute the payment run .

The Status screen displays a new message when the payment run is in progress (see Figure 2.17).

Figure 2.17: Status—“Payment run is running”

When the payment run has been completed, a payment file will be generated (see Figure 2.18).

Figure 2.18: Status—“Payment run has been carried out”

Click on the Payment button to check the payment run log. The log is shown in Figure 2.19.

Figure 2.19: Payment run—job log

In addition to detailed information about the payment documents, errors will also be recorded in the log. As in the proposal log, you can see a Message Class and Message No. for each notification, which is particularly helpful for error analysis.

2.1.4 Creating free form payment requests

To initiate a payment process based on payment requests, you first need a payment request. For single/manual payments, this is efficiently managed using the Create Free Form Payment Fiori app (FIBLFFP)—equivalent to SAP transaction code FIBLFFP. This app facilitates the generation and management of payment requests, serving as a key tool for organizing and tracking financial obligations before executing actual payments.

You can find the app quickly by entering FIBLFFP in the search bar, as shown in Figure 2.20.

Figure 2.20: Search for “Create Free Form Payment” app

Click on the app tile to go into the app. The app screen is shown in Figure 2.21.

Figure 2.21: Free form payment parameters (part 1)

The screen displays a form with different sections and fields that need to be completed.

In the Payee section , fill in the recipient parameters, with bank details as a minimum. For some payment methods, it is mandatory to add the recipient’s address details as well .

If the recipient is an existing business partner in your SAP system, you can click on (“get master data” button) and in the next window you select the relevant customer or vendor master data. Parameters such as bank and address details will then be added automatically based on the master data in your system.

In the Posting Data section , you define the posting details for the payment request. It is possible to post to G/L, customer or vendor account.

At the bottom of the form is a sub-tab labelled Payment Data , as shown in Figure 2.22. On this tab, you define the paying company code House Bank details and the Payment Data , including the amount, currency, Payment Method, Value Date, and Posting Date. Optional fields include Payment Ref. and Reference Text as identifiers for both parties.

Figure 2.22: Free form parameters (part 2)

The other sub-tab is labelled Additional (see Figure 2.23) and is only relevant for specific payments where additional details such as Instruction Key, Tax Number or a Bank Chain ID can be selected for this payment request.

Figure 2.23: Free form parameters (part 3)—optional fields

After entering all the relevant parameters, you can finish creating the payment request by clicking on the button at the top of the screen.

A pop-up window displays your payment request’s posting details, as shown in Figure 2.24.

Figure 2.24: Free form payment log

2.1.5 Releasing payment requests

Before you can execute a payment run, you first need to release the free form payments that have been created. This is done using the Process Free Form Payments Fiori app (F2564), as shown in Figure 2.25. In SAP GUI, this is transaction F8REL.

Figure 2.25: “Process Free Form Payments” app

Click on the app tile to open the app. Within the app, you can use different filters to search for payment requests, and click the Go button to execute the search (see Figure 2.26).

Figure 2.26: “Process Free Form Payments” app

The relevant payment requests are then listed. Click on , on the right side of the applicable payment request, to release that payment request. You then need to confirm the release once more by clicking on the Release button in the pop-up window shown in Figure 2.27.

Figure 2.27: Release payment request

Your payment request is now ready for the payment run.

2.1.6 F111—“Automatic Payment Transactions for Payment Requests” app

To execute a payment run for payment requests, you need to use the Automatic Payment Transactions for Payment Requests Fiori app (F111), as shown in Figure 2.28, or SAP transaction F111.

Figure 2.28: Fiori app ID F111

As with the Schedule Automatic Payments app (F110), you need to enter a Run date and Identification number, as shown in Figure 2.29.

Figure 2.29: App F111—defining run date and ID

Next, click on the Parameters button to enter the payment run parameters.

The Parameters screen is shown in Figure 2.30.

Figure 2.30: App F111—“Parameters” screen

The Posting Date is prefilled with the Run Date value but can be amended if necessary. The Next Payment run on field determines the selection based on the due date of each line item, as with the F110 payment run.

In the Payments control section , you define the relevant Company code and Payment methods. In the Selections section , you choose the relevant accounts. In the example shown, we have selected the G/L account from the previous payment request creation.

Save these settings by clicking on the Save button.

If you need payment advices to be printed, or other lists printed, click on the Maintain parameters for payment mediums button and update the entries, as shown in Figure 2.31.

Figure 2.31: App F111—maintaining payment medium parameters

For payment methods relating to the PMW, data medium creation is customized via transaction OBPM4. After saving your settings, the Parameters screen will be shown again.

You should also activate the Additional Log to better understand any failures or issues during the payment run (see Figure 2.32).

Figure 2.32: App F111- Additional Log settings

Under Desired log for payment method selection, the second or third option should be selected . Both checkboxes under Other log options should also be selected . In the Accounts required section , you should consider all the relevant accounts—G/L account 11002020 in our example.

Click on the Dynamic Selections button (see Figure 2.30) to open the Dynamic Selections window, where you have the option to define a free selection based on different field values or ranges at line-item or master data level. This window is shown in Figure 2.33.

Figure 2.33: App F111—“Dynamic Selection” window

After defining your settings, click on Save, and the payment run is then ready for the proposal run (see Figure 2.34).

Figure 2.34: App F111–Ready for proposal run

The proposal run and payment run are similar to the F110 payment run, which was covered earlier.