Payment Proposal Picks the Wrong Vendor Bank Account

Accounts payable reports that a vendor called to say the payment landed in an account they no longer use, or the vendor's remittance team flags that funds went to a closed account. Sometimes it surfaces earlier, in the payment proposal review, when the treasury team notices a supplier is being paid from a house bank that does not match the currency of the invoice, or the same vendor is split across two different bank accounts in one run with no obvious reason. Occasionally the complaint comes from the bank itself, rejecting the payment file because the account and beneficiary name do not match. The common thread is that the amount and the vendor are correct, only the destination account is wrong, which points straight at bank determination rather than at the invoice itself.

Pull the open item line from BSEG for the invoice in question and read the partner bank type field, then pull all bank account records for the vendor from the vendor bank table and match the type key. Cross-reference against the vendor master change history to see if the account was added or altered between invoice posting date and payment run date. If several invoices for the same vendor show different partner bank type keys with no business reason, that is the pattern confirming inconsistent entry rather than a one-off mistake.

If the issue is a missing or wrong partner bank type on the open item, this is a data correction: the field can be corrected before the payment run either on the document itself where still possible, or by editing the payment proposal directly to force the correct bank account for that line, then regenerating the proposal. If the vendor master bank details are outdated or duplicated, the fix is master data cleanup, removing or correcting the stale bank entry and confirming which account should carry the default flag; this needs the standard vendor master change process, including any dual-control approval where bank changes are gated for fraud prevention. If the house bank ranking in FBZP is structurally wrong, that is a configuration change requiring a transport through the normal change path, and it should be tested against a sample proposal before being moved to production because ranking changes affect every vendor paid through that payment method, not just the one that raised the complaint. Interface mapping errors are corrected at the interface layer, not in FI, and should be retested with a controlled inbound file before the next live run.

The common reflex is to manually overwrite the bank account in the payment proposal edit screen for the affected line and let the run proceed, treating it as a one-off. This clears the immediate payment but leaves the wrong partner bank type on the open item and the stale or incorrect entry in the vendor master untouched, so the same vendor reappears with the same problem on the next invoice or the next payment run. It also creates an inconsistency between what is recorded on the cleared document and what the vendor's actual banking arrangement is, which complicates any later audit of why a particular payment went where it did.

Accounts payable owns invoice-level correction of the partner bank type. Vendor master data governance owns the bank account records and their default flags, including enforcing dual control on bank changes. Configuration changes to house bank ranking belong to the FI configuration team and go through change management. The handover note should state the vendor number, the partner bank type in question, whether the cause was data or ranking configuration, and whether the vendor's bank change was verified as legitimate.