SAP TRM Payment Program F111 vs. F110: When to Use What in Treasury Workflows

Introduction — Two Payment Programs, One Critical Decision

Within the realm of SAP Treasury and Risk Management (TRM) , the execution of payments is not an afterthought in the back office. It is the last, high-risk stage in the lifecycle of every financial transaction. From settlements for foreign exchange to interest rate swap coupons, every treasury transaction will eventually require one crucial query from the team that implements it and the Treasury architect:

Do you think this payment should be made via F110 rather than F111?

On the surface, both appear to perform similar tasks — they process the transfer of funds, make bank transfers, and send accounting documents. But underneath, the two programs run with different fundamental concepts, serve different trigger objects, and yield different downstream outcomes in your SAP world.

The wrong software does not only result in incorrect postings. It causes reconciliation to be broken, alters your cash position, skews your cash forecast, and in more regulated settings it can result in audit findings that are hard and expensive to unravel.

This blog is intended for SAP TRM specialists, architects of treasury, and professionals in finance who require a comprehensive technical guide for knowing when, why, and how to apply F111 instead of F110 in a treasury setting — and the ramifications for making the wrong decision.

Why Payment Program Selection Matters in Treasury

Treasury is not accounts payable. This distinction is clear; however, the majority of SAP implementations — particularly older ones — treat the execution of treasury payments as part of an AP payments run. This is done by directing settlements of financial transactions through F110 because it is already set up and accustomed.

The repercussions from this design shortcut can be profound and extensive:

• Incorrect G/L Post-Payments: The F110 program is intended to clear out unpaid FI line items. When applied to Treasury deal settlements, it deviates from the TRM account determination system completely and results in postings to incorrect G/L accounts, disrupting the accounting object-level financial reliability that SAP TRM relies on.
• Cash Position Misalignment: SAP Cash Management reads payment requests made by TRM to predict future cash flows and outflows. If F110 is used in place of F111, these payments are not properly processed, resulting in empty positions in your forecast of liquidity and degrading real-time cash visibility.
• Settlement Status Failures: Within Transaction Manager, each financial transaction moves through a predetermined activity status — from entry to settlement and finally accounting. F111 is the sole software which accurately updates the settlement status of a TRM deal. F110 leaves the transaction unresolved, requiring manual corrections that create operational risk.
• Netting Problems: Treasury netting of counterparties — where the buy and sell parts of FX contracts are rebalanced prior to settlement — is supported only by F111's netting framework. Routing these payments through F110 complicates settlement, increases exposure to counterparties, and defeats the goal of netting agreements.

Functional Overview — What Each Program Actually Does

Before examining the differences, it is important to know the purpose each program was designed to accomplish, how it interprets data, and what it creates at the end of a run.

F110 — Automatic Payment Programme: F110 was developed to work with Accounts Payable and Receivable. Its primary purpose is to scan unread FI line items — invoices from vendors, credit memos from customers, and inter-company payables. It applies payment techniques and bank ranking rules, creates a payment proposal, and issues clearing documents that offset unpaid items to a subaccount. It retrieves information directly from FI tables, applies FBZP configurations, and is entirely document-driven. It is unaware of financial transactions in TRM deals, deal patterns, flow types, or payment requests.

F111 — Payment Programme for Payment Requests: F111 was designed specifically for use with SAP Treasury and Risk Management. Its main function is to analyze payment requests — the structured payment objects generated automatically through the settlement of financial transactions in TRM — and transform them into accounting postings and bank transfers. It reads directly from TRM tables, complies with the TRM account determination framework, tracks deal status, and supports treasury-specific functions such as netting, multi-currency settlement, and SWIFT message generation. It cannot clear open FI line items.

This architectural separation is clear and deliberate. SAP developed the programs to operate within non-overlapping domains.

Understanding F111 — Payment Program for Payment Requests

F111 is the primary payment engine in SAP Transaction Manager. Understanding its internal mechanisms is crucial to any TRM implementation.

The Payment Request as the Central Object

Each financial transaction within SAP TRM — whether a money market account, FX forward, interest rate swap, or external loan — generates payment requests at the time of settlement. These payment requests are structured objects containing all the data required to execute a payment: amount, currency, value date, paying company code, house bank, payment method, counterparty bank information, and the originating deal reference.

Payment requests follow a specific lifecycle of statuses:

• Open — Created, awaiting F111 pickup
• Blocked — Held by workflow approval, limit violation, or manual block
• In Process — Selected through an F111 payment proposal
• Paid — Successfully settled and posted
• Reversed — Reset and cancelled to allow reprocessing

F111 reads only open payment requests matching the selected parameters at runtime (company code, payment date, currency, and business relationship). It does not access closed FI items and does not attempt to process them.

Flow Type to Payment Request Mapping

Payment generation is triggered by the flow type configuration in TRM. Every flow type represents a particular cash movement — such as a principal payment, interest repayment, or FX settlement leg — and can be configured to create a payment request immediately following settlement, or to require manual creation. This configuration is available in TRM Customizing under Transaction Manager General Settings Payment Details.

Netting in F111

One of F111's most effective features is its treasury-specific counterparty netting. When two payment requests are placed against the same company code and counterparty — such as the sell leg and buy leg in an FX swap — F111 can net the transactions against each other, resulting in one net payment. This reduces the number of settlements and counterparty exposure. Netting methods are configured in TRM Customizing and tied to netting agreements in the business partner master.

Key Technical Differences — F111 vs. F110 Side by Side

The following details highlight the fundamental technical differences between the two programs across every dimension relevant to treasury implementation:

Treasury Use Cases — When to Use F111

F111 is recommended for any payment that results from a financial transaction managed in TRM. The following are the most common scenarios:

Money Market Transactions

• Repayment and placement of fixed-term loans
• Commercial paper redemption and issuance
• Settlements on Certificates of Deposit
• Automated rollover payments for term and overnight deposits

Foreign Exchange Transactions

• Settlement of FX spot deals — both buy leg and sell leg
• FX forward deal settlement on value date
• Settlement of FX swap near and far legs
• Non-deliverable forward (NDF) cash settlement

Securities Transactions

• Principal redemptions
• Settlement for purchase and sale of securities
• Dividends earned from equity positions managed by TRM

Loans and Debt Management

• Receipts for drawdowns on external loans and repayments
• Settlement of loan interest payments
• Intercompany loan settlements, including In-House Cash

Interest Rate Swap Coupon Payment Settlement via F111

Interest rate swap (IRS) settlement is among the most technically demanding scenarios for F111 and is often misconfigured in SAP TRM implementations.

An interest rate swap generates two payment legs at the settlement date — a fixed coupon payment and a floating coupon receipt (or the reverse, depending on swap direction). Depending on the netting arrangement with the counterparty, settlement can be gross (two distinct payments) or net (one net payment reflecting the difference).

How F111 handles IRS settlement:

1. At settlement, the system calculates fixed and floating coupon amounts using the notional principal, applicable rate, and day count convention.
2. Settlement posting creates two payment requests — one for the fixed leg outflow and one for the floating leg inflow (or reverse).
3. If a netting arrangement exists, F111 combines them into one net payment request.
4. F111 processes the net payment request, executes the bank transfer, and posts through TRM account determination.
5. The IRS deal status is updated to reflect coupon settlement, maintaining the deal lifecycle for future coupon periods.

Key Configuration Points for IRS in F111:

• Flow types for fixed and floating coupons must be configured to trigger payment requests.
• The day count convention (ACT/360, ACT/365, 30/360) must be correctly assigned to the flow type.
• Netting procedures must align with the counterparty agreement.
• Account determination must correctly differentiate interest G/L accounts from the settlement bank account.

Common Error — Accrual vs. Settlement Posting Confusion: A frequent misconfiguration in IRS F111 setup is conflating accrual postings (periodic interest accrual journal entries) with settlement postings (actual cash payments). Accrual postings are triggered by the period-end accrual program and do not generate payment requests. Settlement postings on the actual coupon payment date are the trigger for F111. Misconfiguring flow types causes either missing payment requests or duplicate postings.

Treasury Use Cases — When F110 Is Still Relevant in a TRM Context

Although F111 is the correct program for settling TRM deals, F110 remains relevant in a limited range of treasury-adjacent situations:

• Brokerage and Intermediary Fee Payments: Broker commissions for FX or derivative transactions are usually invoiced as vendor documents in FI. F110 is appropriate because these originate from AP, not TRM.
• Custodian and Clearing Fee Invoices: Periodic fees imposed by clearing houses, custodians, or prime brokers are billed as vendor invoices. F110 is the correct program for these cases.
• Treasury-Originated Manual Journal Entries: Where treasury teams post manual FI documents for adjustments or corrections and those items require clearing, F110 handles them appropriately.
• Withholding Tax Payments on Treasury Income: Tax authority payments related to withholding tax on income, when treated as FI documents, go through F110.

The guiding principle is straightforward: if the payment originates from an FI document (invoice, credit memo, or manual journal), use F110. If it originates from a TRM payment request, use F111.

Why Some Pre-S/4HANA Implementations Use F110 for Treasury

This is among the most persistent patterns in SAP Treasury implementations. Understanding its origin helps prevent the issue from carrying over into S/4HANA migrations.

Historical Context

In early SAP ECC implementations, F111 was not well known among all SAP FI consultants. Many implementations were managed by FI/CO specialists familiar with F110 but with limited TRM expertise. Rather than investing in F111 configuration, teams devised workarounds that allowed TRM deal settlements to post via FI documents, which F110 could then clear.

The Workaround Architecture

The typical approach was to configure TRM deal settlements to post vendor or customer line items instead of using native TRM account determination. This produced open items in the FI subledger that F110 could process. While bank postings appeared correct, several structural problems resulted:

• Deal activity status in Transaction Manager was never properly updated.
• TRM reporting failed because the system could not reconcile settlements.
• Cash Management position updates were either inaccurate or duplicated.
• Hedge accounting documentation was incomplete because settlement postings lacked TRM object references.
• Reversals required complex manual intervention in both TRM and FI.

The S/4HANA Migration Risk

When these implementations are migrated to S/4HANA, the F110-based treasury payment structure becomes a significant risk. S/4HANA's simplified data model for treasury and the enhanced TRM capabilities within S/4HANA Finance expect F111 as the settlement program. Carrying over F110-based treasury payments without remediation can lead to:

• Incompatibility with the updated Cash Management structure (FSCM-CM)
• Broken integration with Advanced Payment Management
• Inability to use AI-powered cash forecasting
• Non-compliance with SAP TRM best practice templates

The recommended remediation approach is a planned transition from F110-based treasury settlement to native F111 within the S/4HANA project, treated as a functional improvement rather than a purely technical migration task.

Integration Architecture — F111 in the Broader TRM Ecosystem

F111 does not function independently. It sits at the center of a tightly connected treasury payment system within SAP. Understanding its integration points is essential for designing a robust treasury architecture.

F111 and SAP Cash Management

Payment requests generated by TRM settlement are immediately visible in SAP Cash Management as planned cash flows within the liquidity forecast. When F111 executes a payment run and posts the settlement, the planned cash flows are consumed and replaced with actual bank statement entries upon bank reconciliation. This real-time integration ensures treasury teams have an accurate view of the current cash position.

F111 and In-House Cash (IHC)

In multilateral treasury structures where an In-House Bank operates as an internal payment facility, F111 integrates with IHC to route intercompany treasury payments internally rather than externally. IHC determines whether a request should go to an external bank or be handled as an internal IHC transfer, significantly reducing external bank transactions and associated fees.

F111 and Bank Communication Management (BCM)

For organizations using SAP BCM as their payment hub, F111 forwards approved payments to BCM, which then handles format conversion, digital signing, and transmission to the bank via SWIFT, host-to-host, or EBAM channels. This provides centralized payment monitoring, approval workflows for large-value treasury payments, and a unified audit trail for all outbound bank communications.

F111 and SAP Analytics Cloud (SAC)

Settlement data produced by F111 payment runs feeds directly into SAP Analytics Cloud treasury dashboards, enabling real-time reporting on settlement volumes, counterparty exposure, and cash consumption by deal type. This integration requires correct TRM account determination so that SAC reports can distinguish between instrument types at the G/L level.

F111 and SWIFT MT103/MT202

For direct SWIFT connectivity, F111 generates ISO 20022-compliant or SWIFT MT-format payment messages depending on configuration. The MT103 format is used for customer credit transfers (counterparty payments), and the MT202 format is used for bank-to-bank transfers (correspondent banking settlements). The correct message type is determined by the payment method and bank partner configuration in TRM.

Configuration Checklist — Setting Up F111 for Treasury Payments

Use this checklist as a structured guide when configuring F111 in a new SAP TRM implementation or validating an existing one.

Prerequisites — Master Data

• Paying company code set up in FBZP with the Treasury flag activated
• House bank and bank account data maintained in FI12
• Payment methods configured by country and currency in FBZP
• Business partner (counterparty) bank details maintained with correct IBAN/BIC
• Payment details maintained on every TRM financial transaction (paying company code, payment method, house bank)
• Netting agreements maintained in business partner master (if netting is required)

Prerequisites — TRM Configuration

• Flow types configured to generate payment requests with request generation flags activated
• Account determination framework configured — account symbols, determination keys, G/L assignments
• Netting procedures defined and assigned to transaction types (if applicable)
• Settlement activity types designed for each financial instrument category
• Correspondence and confirmation settings configured for counterparty deal confirmations

Prerequisites — Payment Medium

• Payment Medium Workbench (PMW) format configured for all required bank formats
• DMEE tree assigned to the payment method (if applicable)
• BCM integration configured (if SAP BCM is in use)
• SWIFT message type assigned to payment method (MT103/MT202 where applicable)

F111 Execution Steps

1. Transaction F111 — Enter the payment run ID (date and identification string)
2. Define selection parameters (company code, payment date, currency filter)
3. Run the payment proposal and review individual payment requests and exceptions
4. Unblock held requests and correct insufficient payment information
5. Execute the payment run — post settlement documents, generate payment medium for the bank
6. Review the payment log — confirm all payment requests have moved to Paid status
7. Verify activity status in Transaction Manager — confirm transactions show Settled
8. Reconcile cash position in FSCM Cash Management — verify planned items have been consumed

Post-Run Validation

• Confirm bank subaccount postings align with expected settlement amounts
• Verify G/L account assignments match the TRM account determination design
• Confirm the liquidity forecast in Cash Management reflects the updated position
• Verify SWIFT or bank file was generated and successfully transmitted
• Archive payment run documentation for the audit trail