FK01 — FK01 Create Vendor Accounting View

FK01 creates a vendor master record but only touches two of the three data layers: general data (name, address, control data, one instance per vendor across all company codes) and company code data (reconciliation account, payment terms, dunning, bank details, withholding tax indicators, specific to one company code). It deliberately skips the purchasing organization segment that lives on the vendor master alongside these. The structural fact that explains most confusion: a vendor created purely through FK01 exists and can receive FI postings, but it is invisible to MM until someone runs MK01 (purchasing view only) or XK01 (all views at once) to add the purchasing data. Consultants who assume FK01 produces a fully usable vendor get surprised when a purchase order or RFQ refuses to accept the vendor number.

FK01 is reached for when the vendor is finance-only: a landlord, a tax authority, a one-time payee for an FI invoice, a business partner that will only ever be paid through direct FI postings and never referenced on a purchase order. It sits early in the vendor onboarding process, before any procurement activity, and is typically owned by the AP or GL team rather than procurement. If the vendor will ever be used for purchasing, XK01 is the correct entry point because it creates general, company code, and purchasing data together in one session instead of leaving a partial record that someone has to complete later. On S/4HANA the equivalent activity increasingly runs through the Business Partner transaction with the vendor role, not through FK01 directly.

In SE16, check LFB1 filtered on LIFNR and BUKRS to confirm the company code segment exists and to read the reconciliation account and payment terms actually stored. Join to LFA1 on LIFNR to confirm general data exists and matches expectations. Check LFBK on LIFNR for bank detail rows if a payment run is failing to find a bank. If the vendor should also be usable in procurement, absence of a purchasing organization data row (checked through the purchasing view in the vendor master display, not LFB1) confirms the FK01-only creation is the cause.

On S/4HANA the vendor master is technically a Business Partner with a vendor role; FK01 is retained mainly as a compatibility transaction and, depending on system configuration, either transparently creates the Business Partner behind the scenes through Customer/Vendor Integration or is blocked in favor of the Business Partner transaction with the vendor role assigned directly. The recommended entry point going forward is Business Partner maintenance, not FK01, XK01, or MK01, though the classic transactions may still be reachable for reference or in systems that have not fully cut over.

This is a functional FI issue: account group design, reconciliation account setup, withholding tax configuration, and field status all belong to the FI/AP consultant. Basis is only involved for number range technical issues or authorization objects. A good handover includes the vendor number, company code, account group used, and whether the purchasing view exists, so the receiving consultant does not have to reverse-engineer which segment is missing.

FK02 and FK03 are the natural next stops for changing or displaying what FK01 created. FS00 is where the reconciliation account assigned in FK01 must be checked if postings fail. FK10n shows the balance and transaction history once the vendor is live. FB60 is the transaction most likely to expose a badly configured vendor master, since invoice posting is where missing withholding tax data or a wrong reconciliation account first surfaces as an error rather than a silent gap.