SAP F110 — Automatic Payment Program
Paying suppliers one at a time does not scale. F110, the Automatic Payment Program (often just "the payment run" or APP), does it in bulk: you define the rules once, and it finds every invoice that qualifies, groups them per vendor, posts the payments and produces the file your bank actually receives.
The thing that makes F110 feel harder than it is: it is not one screen, it is a four-stage process you step through in order, and each stage can be undone before the next. Parameters (who and what to pay) → Proposal (a dry run you can edit) → Payment run (posts the documents) → Printout (produces the bank medium).
The proposal stage is the safety net and the reason F110 is safe to learn. Nothing is posted, nothing leaves your bank, and you can inspect every line, block individual invoices, and delete the whole thing and start again. The payment run is the point of no return.
One field decides almost everything about what gets selected, and it is not the one people expect. It is Next payment date — read the field notes below before your first run.
When you would actually use F110
- The routine weekly or fortnightly supplier payment cycle.
- Paying a specific batch of invoices ahead of a deadline or to capture early-settlement discount.
- Producing a payment file (SEPA, BACS, ACH) for upload to the bank.
- Any time paying invoices one by one with F-53 would take longer than defining a rule.
What the screen looks like
Run identification
Selection
| Vendor | Name | Doc. no. | Net due | Amount EUR | PM | Status |
|---|---|---|---|---|---|---|
| 100214 | Office Supplies Co | 1800000123 | 13.07.2026 | 1,190.00 | T | Will be paid |
| 100214 | Office Supplies Co | 1800000188 | 01.08.2026 | 480.00 | T | Will be paid |
| 100902 | Baltic Timber Ltd | 1800000201 | 10.08.2026 | 6,400.00 | Exception |
The fields, in plain English
Together these name the run so you can come back to it. The Run Date is just a label — it does NOT schedule anything and does not have to be today. Identification is any five characters; a convention like WK32 or 0805A saves confusion later.
Watch out: Reusing an existing Run Date + Identification picks up that old run, parameters and all. If a run behaves strangely, check you have not resurrected last week's.
The date the payment documents are posted on, and therefore the period they land in. Must be in an open period.
An entry-date cut-off. Invoices entered into SAP after this date are ignored, even if they are due. Useful for freezing a run against a moving target.
The single most important and most misunderstood field. SAP does NOT simply pay what is due today. It selects every open item that would become overdue **before the next run**, so it can pay it now rather than let it go late. Setting this to two weeks out selects two weeks of upcoming invoices; setting it to tomorrow selects almost nothing.
Watch out: The usual "why did it pick up invoices that are not due yet?" and "why did it select nothing?" both trace back to this field. Set it to the date of your NEXT payment run, not this one.
Which methods this run may use — T for bank transfer, C for cheque, and so on, configured per country. Listing several sets an order of preference.
Watch out: A method listed here must also exist on the vendor master AND be permitted in company code configuration. A mismatch is the number one cause of exceptions.
Which entities to pay from. Several can be paid in one run if cross-company payment is configured.
Extra filters beyond the main parameters — document number range, business area, an assignment value. This is how you pay one specific batch without touching the standard rules.
Switches on detailed logging: due-date check, payment method selection, per-line messages. Off by default because it is verbose.
Watch out: Turn it on the moment something is unexpectedly excluded. The log names the exact reason per invoice and saves an hour of guessing.
Step by step
- 1Enter a Run Date and Identification, then go to the Parameter tab.
- 2Fill in posting date, company codes, payment methods, vendor range — and set Next payment date to the date of your next run.That last field decides what gets selected. Nothing else matters as much.
- 3Save the parameters. The Status tab now reads "Parameters have been entered".
- 4Click Proposal and schedule it immediately. Nothing is posted at this stage.
- 5Open Display Proposal and review it. Check the exception list first — those are the invoices that will NOT be paid.
- 6Edit the proposal if needed: block a line, change a payment method, adjust an amount.
- 7When the proposal is right, click Payment Run. This posts the payment documents and clears the invoices.Point of no return. Reversing means resetting each clearing with FBRA.
- 8Run the Printout to produce the payment medium (the bank file or cheques).
- 9Confirm in FBL1N that the paid invoices now show a clearing document.
Errors you will hit, and what they mean
No valid payment method found
Why: The most common F110 exception, and it has five possible causes: the payment method is missing from the vendor master, it is not permitted in the company code configuration, the vendor has no bank details for a transfer method, the amount falls outside the method's minimum/maximum limits, or the invoice carries a payment block.
Fix: Switch on the Additional log and re-run the proposal — it names the specific reason per vendor. Work down that list rather than guessing.
The proposal contains invoices that are not due yet
Why: Working as designed. Next payment date is set far enough ahead that these would fall overdue before the following run.
Fix: Bring Next payment date closer if you want a tighter selection. Do not "fix" this by blocking lines individually every run.
Proposal has already been created for this run
Why: You are trying to re-run a proposal that already exists.
Fix: Delete the proposal (Edit → Proposal → Delete) and create it again. Parameters can be changed only while no proposal exists.
Payment run posted but no bank file produced
Why: The Printout/data medium tab has no variant assigned for the payment medium program.
Fix: Assign a variant on that tab and run the printout step. The payments are posted regardless — only the file is missing.
An invoice was skipped with a payment block
Why: The line carries a payment block, set manually or by invoice verification (a price or quantity discrepancy from MIRO).
Fix: Resolve the underlying block. If it came from invoice verification, the discrepancy needs settling — not overriding.
Common questions
What is the difference between F110 and F-53?
F-53 posts one outgoing payment manually, for one vendor, now. F110 selects and pays many invoices across many vendors by rule, and produces the bank file. Use F-53 for a one-off, F110 for the cycle.
Can I undo a payment run?
The proposal, yes — delete it and nothing has happened. A completed payment run, not easily: each clearing must be reset with FBRA and the payment documents reversed with FB08. And if the bank file has already been transmitted, the money has moved regardless of what you do in SAP. Review at proposal stage.
Why did my payment run select nothing at all?
Almost always Next payment date set too close, so no invoice falls overdue before it. After that, check the company code, payment method and vendor range actually match live data.
What does the exception list mean?
Invoices F110 considered and rejected. They are not paid and no document is created. The exception list is the first thing to read in any proposal — it is where the problems are.
Does F110 pay customers too?
Yes, for refunds or customers in credit — that is what "Customer items due by" is for. The vast majority of runs are vendor payments.
Transactions that go with F110
Reading about it only gets you so far
Practise SAP transactions in a safe simulated environment and keep what you learn.
Practise SAP transactions hands-on
Interactive modules, games, and an AI tutor — free to start.
Get started free →