SAP Treasury Payment Program

Uses of the Treasury Payment Program

People familiar with SAP applications are often familiar with the Accounts Payable (AP) payment program, but not everyone is familiar with the Treasury payment program, although there are features of the Treasury payment program that most companies could use to improve their processes in an SAP system. The Treasury payment program offers a very controlled, best practice process for treasury departments to follow.

Whereas the AP payment program pays AP and accounts receivable (AR) invoices, the Treasury payment program pays payment requests. Payment requests are open items made to the Payment Request Clearing Account, which is a suspense account configured to track Treasury payments. The same Payment Request Clearing Account number should be used across all company codes.

An obvious advantage of using the Treasury payment program is that the accounting entries for Treasury payments are made by the SAP system before the payment is executed at the bank, which is a more controlled and compliance-friendly process. Another advantage is the straight-through processing of the payment, meaning the payment details, such as the routing number and account number, are entered just once and flow through the SAP system before being sent to the banks. A third advantage is to have the system enforce strict controls around Treasury payments.

There are seven types of payments that could be run through the Treasury payment program (F111). They are:

1. Bank-to-bank transfers
2. Free form payments
3. Business partner repetitive code payments
4. Trade-related payments
5. In-house cash (IHC) payments
6. Loans Management (FS CML) payments
7. Payments to customers and vendors

(Note: When you are making payments to customers and vendors using the Treasury payment program, the customer and vendor bank details are used, but the open invoice is not cleared.)

The IHC payments, payments to customers and vendors using the Treasury payment program, and Loans Management modules are not as frequently used as the other types of payments listed above.

(Note: The functionality described in this article is included in SAP ERP Central Component [SAP ECC], although licensing may be required to use the SAP Treasury and Risk Management module. SAP’s Transaction Manager module tracks Treasury trades through their full life cycle: from trade entry to payments to month-end processing to maturity of the trades. All accounting entries related to the trades are triggered by the trades and are posted directly to the SAP General Ledger. The article also mentions aspects of the SAP Bank Communication Management module, which may also require additional licensing.)

Creating Payment Requests

Repetitive Payments

Repetitive payments are bank-to-bank transfers or payments to a business partner that take place regularly using the same set of payment instructions. There are two types of repetitive payments in the SAP system: bank-to-bank transfers and business partner repetitives. The SAP system uses repetitive codes to process repetitive payments. A repetitive code in the SAP system is a 20-character key that designates a set of payment standing instructions that do not and cannot be changed ad hoc. This includes the sender bank, sender account, recipient bank, recipient account, payment method, and currency. The only details that can be changed when the payment is made are the payment amount, value date, and reference text. There are multiple advantages gained by using repetitive codes in the SAP system. Some of the advantages include increased security, faster entry, and risk mitigation against user error.

Bank-to-Bank Transfers

The most common type of repetitive payment is the bank-to-bank transfer. Bank-to-bank transfers are used to make repetitive payments from one house bank account to another. Both accounts must be defined in the SAP system as house bank accounts. Keep in mind that when the two accounts are in different company codes, this type of repetitive payment creates an intercompany posting document (the payment posting posts to the intercompany due to /due from accounts) posting. (Bank-to-bank transfers can be done between any two accounts as long as the FI configuration has enabled cross-company code postings between the two entities.)

Business Partner Repetitive

Business partner repetitive are repetitive payments made from a house bank account to a business partner bank account.

Before you can execute a bank-to-bank repetitive code or business partner payment, you need to create a repetitive code template. The repetitive code template defines details of the payment that will be executed. The two aspects of the payment that are not included in the repetitive code template are the amount and the value date.

Both bank-to-bank repetitive code and business partner repetitive code templates are created using the Edit Repetitive Codes program (transaction code OT81). After you execute transaction code OT81 or follow menu path Accounting > Financial Accounting > Banks > Master Data > Repetitive codes > Repetitive Codes, the Edit Repetitive Codes screen appears (Figure 1). To create the repetitive code template, enter a value for the sending company code in the Paying CoCd (paying company code) field and enter the name of the house bank in the House bank field.

Figure 1

Create a repetitive code template

Click the create icon

 to create a repetitive code template.

The system then displays the pop-up screen shown in Figure 2. To create a business partner repetitive template, select the Central Business Partner radio button. To create a bank-to-bank repetitive code template select the Bank radio button.

Figure 2

Select the type of repetitive code template

For this example, select the Bank radio button and then click the enter icon

. This action displays the screen in Figure 3.

Figure 3

Define a bank-to-bank repetitive code template

In the Repetitive Code field at the top of the screen, enter a name (up to 20 characters) for the repetitive code template. In the Processing Bank Data section, enter details for the house bank account from which the funds will be sent when the repetitive code payment is executed. In the Target Bank section, enter details for the house bank account to which the funds will be sent. In the Bank chain ID field, you can specify an intermediary bank. Enter the payment method and currency of the payment. In the Reference text: field, enter the reference information that should be sent along with the payment. This text typically describes the payment. The Individual pmnt (individual payment) indicator should be selected if you do not want the payment to net with any other payment when you run the Treasury payment program. By selecting the Individual pmnt indicator, the payment is sent as an individual payment.

(Note: When the Treasury payment program is run, it nets payments that have the same value date, source house bank account, target house bank account, payment method, and currency, and that do not have the Individual pmnt indicator set.)]

After you enter the details for the bank-to-bank repetitive code template, click the save icon

. This action displays a pop-up screen similar to the one in Figure 4. Click the enter icon.

Figure 4

Save the bank-to-bank repetitive code template

At this point, you have defined the repetitive code template, but you cannot use it yet. Before you can use it to execute a payment, you must release it. To release the repetitive code template, open the Edit Repetitive Codes screen (see the instructions before Figure 1), select the tab to the left of the repetitive code as shown in Figure 5, and click the release icon

 .

Figure 5

Release the repetitive code template

This action displays the pop-up screen shown in Figure 6. Click the enter icon and then click the save icon (Figure 5) to save the release.

Figure 6

Save the release

The Release Status for the repetitive code template now is green, indicating it is available to be used to execute a payment (Figure 7).

Figure 7

Released bank-to-bank repetitive code template

To execute a bank-to-bank repetitive code payment, go to the Fast Entry with Repetitive Codes (Bank-to-Bank Transfer) program (transaction code FRFT_B), follow menu path Accounting > Financial Accounting > Banks > Outgoings > Payments with Repetitive Code > Carry Forward Bank Accounts, and press Enter. (There are no required fields when running this program.) This action displays the screen in Figure 8.

Figure 8

Execute a bank-to-bank payment

Enter the amount of the payment in the field under the Amount paid column. The reference text defaults from the repetitive code definition, but can be changed here. Click the Create Payment Request button to create the payment request. A message showing the payment request number is displayed in the next screen (Figure 9).

Figure 9

Payment request generated

At this point, the payment request is unreleased. If you run the Treasury payment program at this point, the system would not pay the payment request created above because the payment request has not been released. To release the payment request, you need to select the payment request in the lower window then click the Release button at the bottom of the screen, as shown in Figure 10.

Figure 10

Release the payment request

After you click the Release button, the system displays a message similar to the one in Figure 11. Click the enter icon to display the screen shown in Figure 12. At this point, the Treasury payment program can be run.

Figure 11

Payment request has been released.

At this point, the payment request’s status is released, as shown in Figure 12.

Figure 12

Payment request Release Status is updated

(Note: The steps for executing a business partner repetitive code template are the same as when executing a bank-to-bank repetitive payment except that the Fast Entry with Repetitive Codes (Treasury Partner) program (transaction code FRFT_TR) is used. Transaction code FRFT_TR can be found by following SAP menu path Accounting > Financial Accounting > Banks > Outgoings > Payments with Repetitive Code > Payments to Business Partners.)

Free Form Payments

Before moving on to the steps to execute the Treasury payment program, I first describe the steps to execute a free form payment.

A treasury department needs to be able to make urgent payments on an as-needed basis. The SAP system provides this functionality with the free form payments transaction. Treasury staff can make payments from any bank account in any company code configured in the system to any external bank account. These payments, including the bank details, are keyed in manually by a treasury user.

To execute a free form payment, run the Online Payment program found under Accounting > Financial Supply Chain Management > Cash and Liquidity Management > Planning > Generate Payment Request > Using USA Control Program > Online Payment, or execute transaction code RVND. In the initial screen that the system opens, select the Free Form Payment button (not shown). This action displays the screen in Figure 13.

Figure 13

The Free Form Payment screen

Enter the information related to the payment, as shown in Figure 14. In the Payee section, enter the name and bank account information for the beneficiary of the payment. By clicking the address icon

, you can enter an address for the beneficiary (not shown). In the Posting Data section, the debit side of the posting is specified when generating the payment request. In the House Bank section of the Payment Data tab, specify the bank account to be used for payment, and in the Payment Data section, specify the amount and currency of the payment, the payment method, and the value date. In the Reference text: field, enter the reason for payment. This text is sent to the bank along with the payment. When you have entered all your data, click the Payments button. This action displays the screen in Figure 15.

Figure 14

Enter details in the Free Form Payment screen

Figure 15 shows the payment request number created and the FI document number created. Click the enter icon (not shown).

Figure 15

Free form payment request created

Before a free form payment can be paid, a user with the authorization to release free form payments must release it. Approving the free form payment at this point is critical because the bank account details have been entered manually into the SAP system. To release the free form payment, execute transaction code F8REL. (This transaction code is not in the SAP menu.) This action opens the screen in Figure 16.

Figure 16

Release free form payments

Enter the known fields and click the execute icon

. This action displays a pop-up screen with a message (Figure 17).

(Note: With dual control, the user who initiated the payment is not able to release his or her own free form payment.)

Figure 17

Dual control on free form payments

The bank details are entered in the Free Form Payment screen (transaction code RVND). Before a free form payment can be paid, it must be released by a user with the authorization to execute transaction code F8REL.

After the F8REL program runs, select the indicator to the left of the free form payment to be released, click the Prebook button, and then click the Payments button to release the payment (the screen in which you complete this step is not shown).

Trade-Related Payments

Treasury trade-related payments flow directly from the treasury trade to a payment request. No rekeying of the data is required. The bank account information is determined from the house bank accounts assigned to the trade and business partner data referenced in the trade creation process.

The SAP system supports the full life cycle of a trade in the Transaction Manager sub-module. All payments related to Treasury trades can be made straight through from the trade, through the Treasury payment program and then to the bank. The bank accounts to which the funds will be sent or received for specific business partners are entered in business partner standing instructions and default into the trade at creation.

Table 1 summarizes the steps of an end-to-end Treasury payment process flow. The Monitor Batches and Payments report (BNK_MONI) gives centralized payment reporting and includes the statuses on the payment from importing the acknowledgement files into the SAP system.

Table 1

End-to-end process flow for Treasury payments with SAP Bank Communication Management

Running the Treasury Payment Program

The steps to running the Treasury payment program are the same as the steps for running the AP payment program (Table 2).

Table 2

Steps to run the Treasury payment program

As with the AP payment program, there are roughly four steps to running the Treasury payment program. The first step is entering the parameters, which entails specifying which payment requests the user wants to pay. After you enter the parameters, you execute the proposal run. In the proposal run, the SAP system informs the user what payment requests, based on the parameters entered, will be paid. In the third, and typically final step, both the accounting entries are made and the payment medium is created. (These final two steps can be made separately or together.) The payment medium is the payment file, such as an XML formatted file, that would be transferred to the bank.

(Note: If you are using the SAP Bank Communication Management module for payment approvals, the payment file creation will be held until the payments are approved.)

Like the AP payment program, the Treasury payment program can be run only for legal entities in the same country. (To determine the country of a legal entity, check the T001 table.) This can be an issue for global companies with a centralized Treasury department because the payment program may need to be run multiple times. To get around having to execute many different payment runs when the company codes are in many different countries, the payment programs can be scheduled once the treasury department is comfortable with the process.

To execute the Treasury payment program, follow menu path Accounting > Financial Supply Chain Management > Cash and Liquidity Management > Cash Management > Planning > Payment Program > Payment Requests, or execute transaction code F111. The system then displays a screen similar to the one in Figure 18. Enter the current date in the Run Date field, and a unique identifier for the payment run in the Identification field. It is best to follow a consistent naming convention for the Identification field so that when you are looking through executed payment runs, it is clear by the Identification field what is included in the payment run.

Figure 18

Treasury payment program input screen

The first step is to enter the parameters. This is done by clicking the Parameters button. This action opens the screen in Figure 19.

Figure 19

Enter details in the Parameters screen

The date entered in the Posting Date field drives the posting date of the FI document created by the payment program. The Next payment run on date should be set to the date when the Treasury payment program will be run next. This information drives the payment requests picked up by the payment run in that any payment request that is due before the next payment run date is included (assuming the other inputs also include the payment request). Enter the company code and Treasury payment method, which is typically a wire transfer. (The number 1 is the Treasury wire payment method in the SAP system I am using.)

After you click the Additional Log button, you can specify the maximum logging of messages in the payment log files. To see the maximum logging, which is most helpful when diagnosing an issue, use the settings shown in Figure 20.

• Select Payment method selection in all cases
• Select Line items of the payment documents
• Select Due date check

Figure 20

Additional log settings

After you click the enter icon (not shown in Figure 20), the message log created for all accounts is displayed (this screen is not shown). This message indicates that logging will be tracked on all payments.

After you click the Dynamic Selections button (see Figure 19), you can specify the specific payment requests that should be selected in the screen the system displays (Figure 21). For my example, enter the bank-to-bank repetitive code payment request number because this is the only payment request you want to pay for illustration purposes. The Key number is the payment request number. Notice that it is possible to filter on many of the payment fields, if required. This is shown in Figure 21.

Figure 21

Enter dynamic selections to filter on specific payments

Click the save icon on the Dynamic selections pop-up screen (not shown). And then click the save icon in the define parameters screen (not shown) to save the parameters entered.

You are then taken to the screen in Figure 22 that includes a message in the Status section indicating that the parameters for the payment run have been entered.

Figure 22

Parameters have been entered

The next step is to run the proposal run. The proposal run tells you what payment requests will be paid based on the parameters entered. To start the proposal run, click the Proposal button in Figure 22.

This action opens a pop-up screen (Figure 23) in which you can either select to start the proposal run immediately or schedule when the proposal run should be run. In most cases, the proposal is run immediately. Press the enter icon in the pop-up screen.

Figure 23

Start the proposal run

After the proposal run is complete, the following message is displayed in the Status section of the next screen (Figure 24): Payment proposal has been created.

Figure 24

Proposal run has completed

You should evaluate the proposal run by clicking the Proposal button or by selecting Edit > Proposal > Proposal List from the drop-down menu. In the List Variant pop-up screen that the system displays (not shown), press the Enter key on your keyboard. The system then displays the Payment List report (Figure 25).

Figure 25

The payment list report

All the details of the payment are displayed. The payment document number displays as F111*00001 because the posting has not been made yet. The business user should validate the details of the payment and then click the back icon (the green arrow) to go back one screen when complete.

If there are any issues with the payment run, the first place to check is in the Proposal log. To view this log, click the Proposal button (refer back to Figure 24). (Figure 26 shows only part of the Proposal log.)

Figure 26

Viewing the proposal log for details in the case of issues

The last step is to execute the payment run by clicking the Pmnt run button in the screen shown in Figure 24. The payment run makes the postings to the SAP General Ledger for the payment(s), and can also create the payment medium for the payment. The payment medium is typically a payment file, such as an XML file, for an SAP Treasury department.

After you click the Pmnt run button, the system displays a pop-up screen (Figure 27). As with the pop-up screen displayed in Figure 23 for the proposal run, you either select to start the payment run immediately or schedule when the payment run should be run. In most cases, the payment run will be run immediately. For the payment run, there is the option to create the payment medium. This indicator should be selected so that a payment file or payment output is created. After you enter your data and select the Create payment medium indicator, click the enter icon.

Figure 27

Schedule payment options

After the payment run is complete, the payment program screen should look like the screen in Figure 28. Note that this screen includes a message indicating that the payment run has been carried out (successfully). At this point, the payment request has been cleared, the posting for the payment has been made to the SAP General Ledger, and assuming the payments have not been routing to the SAP Bank Communication Management module, the payment file has been created.

Figure 28

Payment run has been executed successfully

Payment Controls

Treasury payments are typically wires for large dollar amounts, so payment controls are key. Payment controls are in place to accomplish the following:

1. Avoid making mistakes in transmitting wires─such as dollar amount, bank account detail, and reference field.
2. Avoid having individuals make payments to third parties that should not have been made (whether by processing an invalid payment request or intentionally making an invalid payment).

Throughout the payment process in the SAP system, there are a number of places where dual controls can be activated. The definition of dual control related to payments is that a person other than the initiator of the payment must approve the payment before it moves forward in the process. For example, if a business partner is created and bank details are entered in the business partner master record, a dual control workflow process can be activated that blocks the business partner from being used in a payment before the business partner changes have been approved by a person other than the person who created or changed the business partner.

The following are dual controls that can be put along the payment process flow:

1. Business partner creation/update approval
2. Free form payment approval
3. Repetitive code template creation approval
4. Payment approval (batch level approval). This approval is role based. It is not technically a dual control in that the person who initiated the wire is able to approve the wire.

The diagram in Figure 29 summarizes the different types of payments that are made through the Treasury payment program and shows where bank account information can be entered (in blue) and where dual controls can be put (in red).

Figure 29

Points of possible payment controls

Payment Approvals

The SAP Bank Communication Management module offers the following:

• SAP Bank Communication Management can be used to efficiently manage inbound (current day reports, prior day reports, payment file, and transaction-level acknowledgments) and outbound (AP, HR, and Treasury payments) communications with banking partners.
• SAP Bank Communication Management provides additional capabilities such as payment batching, approval capabilities using standard workflow in the SAP system, digital signature, and payment status tracking.

Another advantage of using the SAP Bank Communication Management module is that the SAP system does not create the payment file until after the payments have been approved. This eliminates the possibility that someone could maliciously update the payment file while it is sitting on the file server waiting to be approved.

The diagram in Figure 30 shows the processes for payment approvals in SAP Bank Communication Management.

Figure 30

Payment approvals in SAP Bank Communication Management

How to Configure the Treasury Payment Program

Now I outline the configuration steps for the Treasury payment program.

The first step in configuring the Treasury payment program is to define unique payment methods to be used by the payment program. It is helpful if the payment methods used for the Treasury payment program are different from the AP payment program payment methods because then the system can clearly distinguish the payment methods that are to be used with the AP payment program versus the payment methods for the Treasury payment program. One way to easily distinguish the Treasury payment program payment methods from the AP payment program payment methods is to use the numbers 1-9 for treasury payment methods and A-Z for the AP payment methods.

To get to the payment method configuration, follow IMG menu path Financial Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments > Automatic Outgoing Payments > Payment Method/Bank Selection for Payment Program or use transaction code FBZP.

The payment methods are defined at the country level and at the company code level. Add a new payment method to the appropriate countries. Add a new payment method to your company code.

For my use case scenario, the following payment method needs to be defined as shown in Figure 31: 1 – Treasury External Wire.

Payment method 1 is the payment method to be used for Treasury wire payments. In other words, the number 1 is the payment method to be used for Treasury wire payments in the SAP system I am using.

Figure 31

Define the Treasury payment method – country-specific settings

In the company code-specific settings under the Pmnt methods in company code button from FBZP shown in Figure 32, select the Foreign business partner allowed, Foreign currency allowed, and Cust/vendor bank abroad allowed? indicators, assuming these types of payments are included in the project scope.

Figure 32

Define the Treasury payment method – company code settings

The next step is to assign the general ledger (G/L) account that will be the payment request clearing account used to track the payment requests. The payment requests are the payments that will be sent to the external banks. All payments sent through the Treasury payment program queue up to the payment request clearing account. This G/L account should be the same G/L account across all company codes. To assign the G/L account follow IMG menu path Financial Supply Chain Management > Treasury and Risk Management > Transaction Manager > General Settings > Payment Management > Payment Requests > Define Clearing Account for Payment Requests.

In the initial screen that the system displays (not shown), click the New Entries button. This action opens the screen shown in Figure 33. Enter the company code and payment request clearing G/L account, then click the save icon.

Figure 33

Define the payment request clearing account

Next, define a number range for the payment request. Payment request numbers, also known as key numbers, go across company codes, meaning each payment request is given a unique number regardless of the company code from which the payment was made. To define the payment request number range, follow IMG menu path Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Payment Request > Define Number Ranges for Payment Requests. Click the Change intervals button (not shown). Click the insert line icon

. Enter a number range 1 to 999999999 for number range 01, as shown in Figure 34. Click the save icon when you are done.

Figure 34

Define a number range for payment requests

Follow IMG menu path Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Payment Handling > Define Global Settings, to enter the Define Global Settings configuration, as shown in Figure 35. In this step, the account types that the Treasury payment program should pay are defined. The account types are (1.) origin of payment, (2.) customers, (3.) vendors, and (4.) G/L accounts. In most cases, only payment requests from the payment request clearing account are needed, so only the G/L accounts indicator should be selected. There is no harm in selecting the other account types.

If you select the Origin check box, the payment program can select payment requests to pay based on the origin of payment. In other words, users are able to pay by origin of the payment. If this is not needed, the origins indicator should be deselected.

To keep the screen less busy and allow minimal options, select just the G/L accounts, as shown in Figure 35, and then click the save icon.

Figure 35

Global settings for payment requests

Next, settings relevant to the Treasury payment program are specified by origin. The origin represents how the payment request was triggered. The origin indicates the application area from which the payments originate (i.e., Cash Management, treasury management, or loans).

The following is set using this configuration:

• If the payment program should check available amounts
• Which configuration should be used to drive the account determination for the Treasury payment program
• If existing attributes of an origin should be used to group payment requests with different origins.
• No exchange rate differences are posted

Follow IMG menu path Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Payment Handling > Enter Origin Indicators to specify the origin settings for the TR-CM-BT origin, as shown in Figure 36.

Figure 36

Specify the origin of payment settings

Next, the account determination for the Treasury payment program is entered. This configuration can be done by currency, house bank account, and /or payment method. In this step, you define when the Treasury payment program is run in this currency, the house bank account, the payment method, and the cash clearing account to which the posting from the payment request clearing account should go. In other words, the payment program uses this table to determine the accounting entries to make when the program is run. Follow IMG menu path Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Payment Handling > Bank clearing account determination >

Define account determination and enter the configuration settings

as specified in Figure 37.

Figure 37

Define the sending bank G/L account

Next, the G/L account for the receiving bank account when executing a bank-to-bank repetitive payment is specified in configuration. Follow IMG menu path Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Payment Request > Define clearing accounts for receiving bank and enter the configuration, as specified in Figure 38.

Figure 38

Define the receiving bank G/L account

A calendar must be defined to determine working days for each currency you will be paying out of the Treasury payment program. This is done using IMG menu path Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Payment Handling > Value Date > Define Factory Calendar per Currency, as shown in Figure 39. Make sure there is a calendar specified for all currencies that will be paid using the Treasury payment program.

Figure 39

Assign a calendar for payment processing to currency

The last configuration step is to set dual control on free form payments (origin FI-BL). Do this by using the IMG menu path Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Online Payments > Define Process Steps, as shown in Figure 40. Select the Dual Control radio button for the origin FI-BL, then click the save icon.

Figure 40

Specify dual control on freeform payments.

Table 3 summarizes the transaction codes covered in this article.

For step by step instructions to configure and test SAP Cash management & Liquidity management, please visit my course below

SAP Cash & Liquidity Management

Please visit previous tutorial on Money Market instruments configuration and Business Process in SAP

Please visit next tutorial on Bank Account Management in S4/HANA

For step by step instruction on Business process, Configuration and Testing in Cash & Liquidity Management in SAP please join my course below

Cash & Liquidity Management