FB65 — Vendor Credit Memo Posting

FB65 creates a vendor credit memo, a document that reduces the amount owed to a vendor. Structurally it is the mirror image of FB60: where a vendor invoice credits the vendor account and debits expense, a credit memo debits the vendor account and credits expense or the relevant G/L accounts. The single fact that causes most confusion is that a credit memo is not a negative invoice line entered in FB60 with a minus sign; it is its own document type with reversed debit/credit indicators on every line. Entering it the wrong way produces a document that balances numerically but posts to the wrong side of the vendor account, doubling the payable instead of reducing it. FB65 only posts in FI; it has no link to a purchase order, goods receipt, or invoice verification document unless one is manually referenced in the text or assignment field.

FB65 is reached for when a credit needs to be recorded against a vendor and there is no purchase order or MM invoice verification document behind it, for example a rebate, a freight correction, a manually agreed price adjustment, or a return processed outside logistics. If the credit relates to a purchase order and a prior invoice verification document, the correct tool is a subsequent credit in MIRO, not FB65, because MIRO keeps the purchase order history and account assignment consistent. FB65 sits in the accounts payable sub-ledger alongside FB60 for invoices and F-53 or F110 for payment; it is the entry point a consultant uses when the credit is a pure finance transaction with no logistics footprint to preserve.

To confirm a credit memo posted correctly, pull the document from BKPF using company code and document number, then join to BSEG on the same keys and filter for account type K (vendor). The vendor line should show a debit posting key (typically 21) and a positive debit amount, not a credit. Cross-check against BSIK or BSAK for the same vendor and document number to confirm whether it is still open or has already cleared against an invoice.

FB65 remains available on S/4HANA and the underlying posting logic is unchanged. The vendor master sits on the Business Partner model rather than the classic vendor master transactions, but that affects master data maintenance, not the FB65 posting screen itself. A Fiori app exists for creating supplier invoices and credit memos as an alternative front end, but the GUI transaction is still fully supported and commonly used by AP teams who work directly in the backend.

This is an accounts payable functional issue. A good handover includes the company code, vendor number, document number and fiscal year, the exact symptom seen in BSEG or BSIK/BSAK, and whether the credit memo was meant to reference an existing invoice. Involve ABAP only if a custom validation or substitution rule is suspected of forcing the wrong posting key; involve Basis only for authorization failures blocking the posting itself.

Read FB60 first to understand the invoice-side posting logic that FB65 mirrors, since most FB65 errors are a misunderstanding of that mirror relationship. FB70 and FB75 are the customer-side equivalents and worth comparing for the same debit/credit reasoning. FB08 is the correct tool for reversing a wrongly entered credit memo rather than trying to post a compensating entry. FBL1N is the standard way to review the vendor's open and cleared items to confirm a credit memo cleared as intended, and FS00 is useful for checking the G/L accounts used on the offset lines.