In SAP ERP Central Component most companies use transaction F110 to make payments from their SAP system. This transaction selects open customer and vendor items that are due before the next payment run is made. This program cannot be used to make bank transfers that are not based on customer and vendor open items. For those cases you must use payment requests. In principle a payment request is a document that is used for creating payment media with transaction F111. Payment media are methods to order the bank to make a transfer. Examples are files, checks, and bills of exchange. Learn how to set up repetitive codes, create a transfer using these codes, and customize settings needed to complete bank-to-bank transfers.
Key Concept
For payments not based on open items, such as transfers between banks, you must use payment requests combined with payment transaction F111. To facilitate periodic payments you can use repetitive codes. A repetitive code is a key that determines the payment transfer data that remains unchanged. The repetitive code contains the sender company code, sender bank, sender account, receiving company code, recipient bank, recipient account, payment method, and currency. The only changeable fields are the amount and the note to the payee. The use of repetitive codes and payment requests is part of the bank accounting functionality.
To explain how bank-to-bank transfers work, I first set up a repetitive code and create the transfer using the repetitive code. I then explain the required configuration.
Preparation of the Business Process
As a first step of the business process, you have to create the repetitive codes. You create repetitive codes once. After you create these codes, you can use them over and over again. In principle, a repetitive code is nothing other than a tool to keep sender information, receiver information, and payment information.
You maintain repetitive codes using transaction code OT81. Follow menu path Accounting > Financial Accounting > Banks > Master Data > Repetitive codes. Figure 1 shows the screen of this transaction. When you start it, enter the company code, house bank, and bank account ID for which you want to maintain the repetitive code. As you can see in Figure 1, no repetitive code exists yet. If you want to get a complete list of all available repetitive codes, click the configurable list icon 
at the top of the screen shown in Figure 1.
Figure 1
No repetitive codes exist yet
Because in this example no repetitive code exists yet, you must create one from scratch by clicking the create icon 
. A pop-up screen appears. On this screen you select the category of the repetitive code (Figure 2). Repetitive codes can be used for business partners that are used in the treasury module of SAP, vendors, and bank transfers. For bank-to-bank transfers select Bank.
Figure 2
The pop-up screen to select the repetitive code category
After selecting the category press Enter on your keyboard or click the green check mark to go to the next screen (Figure 3). On this screen you enter the data of the repetitive code. In the Repetitive Code field near the top of the screen, enter the key of the repetitive code. In the middle of the screen enter the target bank data; the target bank is the bank to which the money is sent. Below the target bank enter the payment method and the currency of the transfer. It is also possible to transfer via a bank chain (i.e., a number of banks that are connected through a chain).
Figure 3
The data screen for the repetitive code
When you are ready, save the data by clicking the save icon 
. This step takes you back to the overview screen (Figure 4). The red light indicates that the repetitive code cannot be used yet because it is not released. To release it, click the release icon. The light then changes to green. You can now use the repetitive code for making bank transfers.
Figure 4
Unreleased repetitive code
Repetitive Code Groups
To facilitate the creation of bank-to-bank transfers, you can define the repetitive code groups. A repetitive code group can be used to select specific repetitive codes. To maintain groups, click the Groups button. This step takes you to the overview screen for repetitive code groups (not shown in this article). To create new groups click the New Entries button. You then enter a group name and a group description (Figure 5). Select the repetitive code group for which you want to assign repetitive codes. On the left side of the screen, double-click the Repetitive Code Assignment line. A screen similar to the one shown in Figure 6 appears. On this screen you click the new entries button (this screen is not shown). You then can add new entries as shown in Figure 6. The complete repetitive key with a maximum of 20 characters is visible in Figure 6.
Figure 5
Repetitive code group header
Figure 6
Assign repetitive codes to a repetitive code group
To assign repetitive codes populate the fields under Company Code, House Bank, and Repetitive Code in Figure 6. When you are ready, save your entries by clicking the save icon. This icon is not shown in Figure 6.
Note
You can also maintain repetitive code groups using transaction FIRPGR, but this transaction cannot be found within the user menu.
Making a Bank-to-Bank Transfer Using a Repetitive Code
Start transaction FRFT_B directly or follow menu path Accounting > Financial Accounting > Banks > Outgoings > Payments with Repetitive code > Carry Forward bank accounts. On the screen that appears enter the company code and house bank key (Figure 7). After you press Enter, the system automatically shows all relevant repetitive codes in the Selected Repetitive Codes part of the screen. In the example shown, there is only one repetitive code. Additionally, you can enter a repetitive code group. After pressing Enter you then only see the repetitive codes belonging to this group.
At the top right part of the screen you can enter the value date and posting date to be used in the payment run. This value date is only relevant if you are using cash management. When you leave the posting date blank, the current date is used as the posting date.
At the bottom of the screen in Figure 7 you see the payment request information. In this example it is still empty, but it may also show previously created payment requests. In the example, I enter 50000 for the amount to be transferred from House bank ING account-id EURO to Target bank ING Target account-id USD.
Figure 7
Initial screen transaction FRFT_B
To create a payment request for this transfer, click the Create Payment Request button. The payment request is required as the payment program uses it to create the payment file. The results from clicking this button can be seen in Figure 8. The repetitive code disappears, and a pop-up screen shows that a payment request has been created. At the bottom of the screen you can see the payment request data.
Figure 7
A payment request has been created
The release status is blank, indicating the payment request hasn’t been released yet. An unreleased payment request cannot be used within a payment run. Once you create a payment request, there are several possibilities:
- Reverse the payment request. This option means the request disappears. This option can be necessary in case of a mistake.
- Release the payment request. The request can be used to create a payment media for the payment. As soon as you include a payment request in a payment run and use it to make a payment, the request disappears from the overview in transaction FRFT_B. Releasing and manually including payment requests in a payment run can be useful if you want to combine payment requests originating from different sources in one payment run.
- Pay the payment request. When you click the Pay button, the program automatically creates a payment run and executes the payment run. It is not necessary to first release the payment request. You can select several payment requests to be included in the payment run. After you click the Pay button, a pop-up screen appears to indicate that a payment run has been created (Figure 9). The identification of the payment run consists of a daily serial number followed by an R. The character R is automatically added by the transaction F111. The adding of the R is hard-coded in the program and cannot be changed.
Figure 9
A pop-up screen indicating a payment run has been created
From transaction FRFT_B you can go directly to the payment run in transaction F111. Follow menu path Environment > Payment Run as shown in Figure 10.
Figure 10
Directly go to the payment run in transaction F111
In transaction F111, you see that the payment run has already been executed (Figure 11). In principle, transaction F111 works the same as F110, but the buttons and the screen look a little bit different.
Figure 11
The result in transaction F111
When you use the classic payment medium programs you still have to do one more step: Create the payment medium. The reason is that the program cannot automatically determine the variants to be used for the report programs. Click the Maintain Parameters for the Payment medium button to maintain the variants of the reports that create the payment media. After saving the parameters by pressing the save button, click the Schedule creation of the payment medium button. When you use the payment medium workbench (PMW), you don’t need to create the payment medium. Creation of the payment medium is automatically executed when using the PMW.
Figure 12 shows the financial posting resulting from this transaction. The posting scheme is derived from the customized settings. I discuss these settings next.
Figure 12
Posting of a bank-to-bank transfer
Customizing Settings
You need to customize settings to be able to make bank-to-bank payments. Configuring a standard payment program is also necessary. However, the setting up of F110 is very basic SAP customizing and normally all companies already use F110, so I do not describe these steps in this article.
First, you must set up the number range for the payment requests. Run transaction FB8M directly or follow customizing menu Financial Accounting > Bank Accounting > Business transactions > Payment transactions > Payment request > Define number range for Payment request. It is mandatory to use interval number 01 (Figure 13).
Figure 13
Number range for payment requests
Next, you determine the G/L accounts for the bank-to-bank transfer posting. As you can see in Figure 12, you must define payment in transits accounts for the sending bank and the receiving bank. In the example the sending bank has a credit posting on the payments in transit account 14200, and the receiving bank has a debit posting on payments in transit account 14201.
Make the settings to derive the account for the sending bank by following IMG menu path Financial Accounting > Bank Accounting > Business transactions > Payment transactions > Payment Handling > Bank Clearing Account Determination > Define Account Determination. (You can also make the setting using transaction F11CU or OBVCU.) You see a pop-up screen in which you enter the company code or another code you want to use to maintain the setting. Per house bank, payment method, currency, and bank account ID combination, you define which G/L account is to be used for the posting. In Figure 14 you can see that for bank ING, payment method B, currency EUR, and bank account ID EURO, you want to use G/L account 14200. This number matches the posting in the second line of the financial document shown in Figure 12.
Note
Be aware that you must set up this account determination exactly the same way as you did for the payment program F110. You can check the consistency of the settings with report RFFMB001. You can also start this report with transaction F8BH.
Figure 14
Account determination setting for the sending bank
Finally, you need to set up the G/L account determination for the receiving bank. Follow IMG menu path Financial Accounting > Bank Accounting > Business transactions > Payment transactions > Payment request > Define Clearing Accts for Receiving Bank for Acct. Transfer.
In Figure 15 you can see that for bank ING, payment method B, currency EUR, and bank account ID EURO, you want to use G/L account 14201. This number matches the posting in the first line of the financial document shown in Figure 12.
The Country field has been left blank, but this field should be used for cross-country payments (for example, you not only make payments from a Dutch bank account to another Dutch bank account but also from a German bank account to the Dutch bank account). In this case the system needs to know whether the payment method B belongs to the Dutch bank or to the German bank. The Country field identifies the paying bank. The Currency field can be used to differentiate between transfers in different currencies. This field also refers to the paying bank account.
Figure 15
Account determination setting for the receiving bank
Additional Setting for Cross-Country Code Transfers
You can also make transfers from one country to another country. However, additional settings are required. For technical reasons, you need to define a clearing account. This step is related to the fact that a payment request is also used in the Treasury module of SAP. Do the customizing via the customizing menu Financial Accounting > Bank Accounting > Business transactions > Payment transactions > Payment request > Define Clearing Accounts for Cross-Country Bank Account Transfers. To add new entries, click the New Entries button and enter the company code and account number (Figure 16). When you are ready, save your entries by clicking the save icon.
Figure 16
The technical account for cross-country bank transfers
Additional Setting for Cross-Company Code Transfers
You can also make transfers from one company code to another company code. You need to configure the settings for cross-company code clearing accounts (Figure 17). This step involves the use of standard SAP configuration, and therefore, is outside the scope of this article. The configuration of the clearing accounts can be done with transaction OBYA.
Figure 17
Example settings for cross-company postings
Note
You can also use repetitive codes to make payments to vendors. On the pop-up screen shown in Figure 2, select the category for Vendor, Creditor. Instead of defining a target bank, you select a vendor. In principle, the rest of the steps for defining repetitive codes for payment to vendors is the same. In transaction FIBLAPOP, you can use the repetitive codes for vendors. My article “Create Online Vendor Payments Using Payment Requests” describes transaction FIBLAPOP without the use of repetitive codes. The use of repetitive codes saves the searching for the vendor number and vendor’s bank account.
A third option on the pop-up screen shown in Figure 2 is the Central Business Partner. When you select Central Business Partner, then you must define a business partner instead of a target bank. Business partners are used within the Treasury module of SAP and are not discussed any further in this article.
Kees van Westerop
Kees van Westerop has been working as an SAP consultant for more than 25 years. He has an MBA degree in mathematics and a degree in finance. Kees has been concentrating on the financial modules, especially in general ledger accounting, cost center accounting, and consolidation. He also has a great deal of experience with rollouts of kernel systems and integrating finance and logistics.
You may contact the author at keesvanwesterop@hotmail.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
