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. All functionality described in this article is standard SAP system functionality. 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

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.  

Creating Payment Requests

  In this section, I describe the more commonly executed Treasury payments in detail.  

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 Repetitives

  Business partner repetitives 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. 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. For this example, select the Bank radio button and then click the enter icon . This action displays the screen in Figure 3. 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. 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. 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 . 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. The Release Status for the repetitive code template now is green, indicating it is available to be used to execute a payment (Figure 7). 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. 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). 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. 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. At this point, the payment request’s status is released, as shown in Figure 12.

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. 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 15 shows the payment request number created and the FI document number created. Click the enter icon (not shown). 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. Enter the known fields and click the execute icon . This action displays a pop-up screen with a message (Figure 17). 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 acknowledgment files into the SAP system.

Step	Transaction code, program, or how to run the process	Description
Initiate Treasury payment request	Free form payment (RVND), repetitive code payment (FRFT), post trade flows (TBB1)	Treasury initiates the payment request. This can be done by initiating a free form payment or a bank-to-bank transfer or by posting a Treasury trade to the SAP General Ledger.
Treasury payment program	Scheduled or manually executed (F111)	The payment accounting documents are created in this step, but the payment file is not created. The payment file is not created until the payment processing and approval are successfully completed.
Merge payments	Scheduled (FBPM1)	(SAP Bank Communication Management) Starts the process of merging payments. This step triggers the workflow approval messages.
Approve payments	Approve Bank Payments (BNK_APP)	(SAP Bank Communication Management) Payment file creation will be held until the payments are approved. The payment file is created upon approval of the payments.
Payment file is delivered to the bank	N/A	The payment file is created. The payment file is now transmitted to the bank. The status of the batch is now payment medium created.
File level acknowledgment	N/A	A file level acknowledgment file acknowledges the bank has the received payment file. The file level acknowledgment lets the company know the bank has received the payment, although it does not confirm that the payments within the payment file will all pass through the payment system correctly. (It would be the transaction- level acknowledgment that tells the company the payment transactions have been successfully processed at the bank.)
Transaction level acknowledgment	N/A	The transaction level acknowledgment file provides successful or rejected acknowledgment at the payment level.

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).

Step	Description
Enter parameters	This is where users tell the SAP system what they want to pay.
Proposal run	This is where the SAP system tells the user what payments will be made based on the parameters entered.
Payment run	In this step, postings for the payment are made to the SAP General Ledger. Create payment medium Create a payment file.

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. 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. The first step is to enter the parameters. This is done by clicking the Parameters button. This action opens the screen in Figure 19. 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

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. 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. 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. 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. 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). 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.) 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. 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.  

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).  

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.  

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. 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. 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. 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. 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. 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. 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. 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. 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.

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.

Table 3 summarizes the transaction codes covered in this article.

Transaction code	Use
BP	Create or change business partner
OT81	Create repetitive code template
FRFT_TR	BP repetitive
FRFT_B	Bank-to-bank repetitive
TBB1	Post treasury cash flows
RVND	Create free form payments
F8REL	Release payments
F111	Treasury payment program
FBPM1	Merge payments
BNK_MONI	Batch and payment monitor report