F110 — Automatic Payment Program for Vendor and Customer Runs

F110 selects open items from vendor and customer accounts that fall due for payment or debit and either proposes a payment run for review or executes it, clearing the open items and creating payment documents. The one structural fact that explains most confusion: a payment run has two separate phases, the proposal run and the payment run itself, and they are not the same execution. The proposal run only simulates selection and produces a proposal list with an exception log; nothing is posted. The payment run, executed against a proposal, is what actually clears items, posts the payment document, and triggers the payment medium program. Consultants who rerun a 'payment run' expecting it to pick up new items are actually rerunning the proposal, and the confusion between 'proposal date' and 'next posting date' parameters is the single most common configuration mistake in day-to-day use.

F110 sits at the end of the procure-to-pay and order-to-cash cycles, after invoices are posted and due, and before bank reconciliation. It is used for batch settlement of open items rather than one-off manual payments, which go through FB50, F-53 or F-28 instead. A consultant reaches for F110 when a company code needs to clear a population of due invoices in one run, typically daily, weekly, or on a fixed treasury calendar, and needs the resulting payment medium file (DME, IDoc, or SEPA) generated automatically. It is also the transaction used to diagnose why a specific invoice was or was not paid on a given run date, since the exception log and proposal list are only visible inside F110's own screens, not from the invoice document itself.

To confirm whether an item was included or excluded from a specific run, query REGUP filtered on the run date and identification, joined to REGUH on the same keys, and read the exception reason field on REGUP for excluded items. To confirm whether a run actually posted, check REGUV for the run's status flags rather than assuming the payment run completed just because it was scheduled. Cross-check the clearing document referenced on REGUH against BKPF to confirm it exists and is not reversed, and check PAYR to confirm the payment medium file was actually generated after clearing.

F110 itself is unchanged in structure on S/4HANA; the two-phase proposal-then-payment logic, REGUH/REGUP, and the exception log all work the same way. S/4HANA adds a Fiori app for scheduling and monitoring payment runs and, in some releases, an advanced payment management capability for more complex bank integration scenarios, but the classic transaction remains the primary tool most consultants use for day-to-day runs and is still the fastest way to read an exception list.

Functional FI/AP-AR territory for parameter setup, house bank configuration, and exception diagnosis. Basis involvement is needed only for background job scheduling, parallel processing performance, or spool/print server issues affecting the payment medium output. A clean handover includes the run identification and date, the exception reason codes observed, and whether the failure is in the proposal phase or the payment phase, since those point to entirely different owners.

F150 is the dunning-side counterpart and worth understanding for contrast, since it shares the same open-item selection logic but never clears anything. FS00 and OB52 matter because house bank and posting period configuration are frequent root causes of exclusion from a run. FK02 and FD10n are the master data screens to check first when a payment method or bank details issue is suspected on a vendor or customer. FBRA is useful when a payment run's clearing needs to be reset after a mistaken run.