Vendor Open Item Missing From F110 Payment Run

Accounts payable reports that a vendor called about a missing payment, or that a specific invoice due last week still shows as open in the vendor account even though the weekly payment run completed without errors. The user checks the vendor line item list and sees the item sitting there with no clearing document. They rerun the payment proposal expecting the item to appear this time, and it still does not show up. Finance sometimes escalates this as a bank interface or payment medium problem before anyone looks at the proposal itself, because the payment run log shows no error and no items in the exception report at first glance, since the item was never selected in the first place rather than selected and rejected.

Start with the proposal itself before touching master data. Open the payment run in F110, go to the edit proposal screen, and check the exception list and log first, since many exclusions are logged there even when the initial complaint says nothing was flagged. Pull the vendor line item list in FBL1N filtered to open items for that vendor and company code, and check the payment block field and the baseline date on the specific document. Display the document in FB03 to confirm the payment method and block indicator stored on the line item itself, which can differ from the master. Check the vendor master payment transactions view in FK03 for allowed payment methods, house bank, and any block flag. Compare the run parameters tab in F110 - company codes, payment methods, currencies, next posting date - against what the item actually needs. Finally check the house bank determination configuration in the payment program setup if nothing on the data side explains it.

Run FBL1N for the vendor and company code, open items only, and note the payment block field, baseline date, and payment method on the specific document. Then open the F110 proposal log for the run in question and check whether the document appears in the exception list with a reason code, or does not appear at all, which points to a selection parameter mismatch rather than a block. The combination of these two views turns 'the vendor was not paid' into a specific, attributable cause.

If the cause is a payment block on the document or vendor master, this is a data fix: remove the block via FB02 mass change or the vendor master change transaction, then rerun the proposal. If the item is genuinely not yet due, no fix is needed, this is correct behaviour, and the business expectation needs correcting instead. If the payment method is missing from the item or master, correcting the master record or reposting with the right method is a data fix; adding the payment method as a valid option at company code level is a configuration change and needs a transport. If the house bank ranking table has no entry for the currency or amount band, that is a configuration gap in the payment program setup and requires a change request and transport, not a one-off data correction. If the item was caught in a stale concurrent proposal, delete that proposal properly in F110 rather than editing the item, which frees it for the next run.

The reflex fix is to delete and recreate the entire payment proposal repeatedly, or to pay the vendor manually outside F110 with a one-off bank transfer, marking the invoice cleared by hand. This does not address why the item was excluded, it just routes around it, and manual clearing without checking the block reason means the same block will silently exclude the next invoice from that vendor too. It also breaks the audit trail linking the payment to a proposal and complicates bank reconciliation.

Accounts payable owns the day to day resolution of blocks and master data corrections. FI configuration owns changes to house bank determination, payment method setup, and minimum amount limits, which require a transport and testing before going live. The handover note should state the vendor, company code, document number, the block or exclusion reason found in the log, and whether the fix applied was a data change or requires a configuration transport.