F-43 — Enter Vendor Invoice, Classic Posting Key Entry

F-43 posts a vendor invoice document by building it line by line through explicit posting keys rather than a single enjoy-style entry screen. The vendor line uses posting key 31 (invoice, credit) and each offsetting line uses a posting key such as 40 for a GL debit. The structural fact that explains most confusion: the posting key chosen on one screen determines which fields appear and which are mandatory on the next screen, and it also determines the debit/credit direction and the account type (vendor, GL, customer, asset) that screen expects. Get the posting key wrong and the whole line has to be deleted and re-entered, not just corrected. F-43 also permits multiple vendor lines in a single document, something FB60 cannot do.

F-43 sits in the accounts payable invoice-to-pay process at the point an invoice with no purchase order reference, or one that cannot be handled through logistics invoice verification, needs to be booked to the vendor. It is chosen over FB60 when the invoice must post to more than one vendor account in the same document, when a special GL indicator or posting key outside FB60's simplified field layout is required, or in environments where consultants and end users are still trained on the classic posting-key screens rather than the enjoy transactions. On S/4HANA the Fiori app for creating a supplier invoice covers the same ground for the common case; F-43 remains the fallback for edge cases the app does not model well.

Pull BKPF for the company code and document number range, filter on document type KR, then join to BSEG on company code, document number, and fiscal year. Check KOART to separate vendor lines (K) from GL lines (S), confirm LIFNR is populated on the vendor line and HKONT on the GL line, and check that BSCHL matches what was intended (31 vendor invoice, 40 GL debit, or 21/50 for credit-side variants). Sum WRBTR by document; it must net to zero. Cross-check BSAK versus BSIK to see whether the vendor line is still open or already cleared.

F-43 still runs on S/4HANA for backward compatibility and behaves the same way from a posting-key perspective. BSEG remains available as a compatibility view over the universal journal table, so the transaction's behavior at the screen level is unchanged even though reporting underneath now runs off the single line item table. The Fiori app for supplier invoice entry is the preferred route for new implementations and for users who never learned the posting-key workflow, but it does not fully replace F-43 for multi-vendor or multi-GL-line documents.

This is a functional AP issue in almost every case: wrong posting key, wrong field status, wrong special GL indicator, or a genuine duplicate invoice. Basis involvement is limited to authorization failures on the transaction or company code. ABAP gets involved only if a validation, substitution, or user exit is rejecting the document. A good handover includes the document number (if posted) or the exact error message and screen (if not), the company code, and the intended posting keys.

FB60 is the enjoy-screen equivalent for the common single-vendor invoice case and is worth comparing directly against F-43 to understand why the multi-line, multi-vendor scenario needs the older transaction. FB65 handles the credit memo counterpart. F-53 clears the open item this posting creates, so tracing a payment back to its invoice runs through both transactions. FBL1N and FK10N are the read-side tools for confirming what F-43 actually wrote to the vendor account, open item by open item or balance by balance.