SAP F110

It runs the automatic payment program, selecting due open items (vendor invoices) and creating payments (e.g. bank transfers), the workhorse of accounts-payable payment.

• Run date and identification.
• Parameters: company codes, payment methods, vendors, next payment date.
• Proposal (preview of what will be paid) then payment run.
• Payment media (files/forms) generation.

F110 is not one action, it is four, and each is reversible until the last one is not. Knowing which step you are on is the difference between a routine correction and a call to the bank.

1. Parameters. You define the run: company codes, payment methods, next payment date, and which vendors are in scope. Nothing has been selected yet. Fully editable.
2. Proposal. The program selects the open items that meet the parameters and shows what it intends to pay. Nothing has posted. The proposal can be edited item by item, and it can be deleted and rerun.
3. Payment run. The payments are posted. Documents are created, items are cleared, and this is the step that is not casually undone.
4. Payment medium. The file or forms for the bank are generated. Once that file has been sent, the money is somebody else's problem to recall.

So the rule that keeps accounts payable calm is simple: everything before step three is free, and nothing after it is. The proposal exists precisely so that somebody looks before the money moves.

• Always review the proposal before the actual run.
• Correct payment method/bank determination is essential.
• Exceptions/blocks show why an item was not paid.

Two more that matter operationally. Only one run per identification per day, so the run date and identification pair has to be managed rather than typed at random. And a proposal left undeleted locks the items it selected, so an abandoned proposal quietly stops those invoices being paid by anybody else's run.

Most F110 problems are configuration rather than the run, and it sits in a small number of places.

• FBZP is the payment program configuration: paying company codes, payment methods per country and per company code, bank determination and house banks.
• The vendor master carries the permitted payment methods and the bank details. A vendor with no payment method valid for the country will never be selected.
• The open item itself carries a payment block and a payment method that override the vendor default.
• House bank and account determination decide which bank account pays and which G/L account is posted.

The tables to know are REGUH and REGUP, which hold the run's payment data at header and item level, and BKPF with BSEG for the accounting documents once the run posts. An exception in the proposal log names the item and the reason, and it is almost always one of the four bullets above.

• Items not selected (payment block, wrong due date, missing bank data).
• No valid payment method for the vendor/country.
• House-bank/bank-determination configuration errors.

Around the transaction: FB60 enters the vendor invoices this run pays, FB70 is its customer side, and FB50 posts a G/L document directly. Understanding where the open items came from is usually the fastest route to understanding why one was not selected.

Version note: the transaction and its configuration are unchanged on S/4HANA. What changed underneath is that the line items now live in the Universal Journal, so reconciliation between the sub ledger and the general ledger is not a separate exercise. The payment program itself, FBZP, and the REGUH and REGUP tables behave as they always have. See ME21N for where the payables originate.

• Running the payment run when you meant the proposal. The buttons sit next to each other and only one of them is reversible. If you are not sure which step you are on, you are on the one that posts.
• Leaving an abandoned proposal in place. It locks the items it selected, so those invoices are quietly excluded from everybody else's run until somebody deletes it.
• Reusing a run identification on the same date. One run per date and identification pair, so the naming has to be managed rather than typed at random.
• Generating the payment medium twice. The posting is idempotent and the file is not. Two files sent to a bank are two payments.
• Reading the exception list as an error list. Most exceptions are correct behaviour: a blocked item, a vendor with no valid payment method, an invoice not yet due. The question is which ones should not be there.