FK03 — Display Vendor Master (FI View)

FK03 opens a vendor master record for viewing only, restricted to the accounting-relevant segments: general data (name, address, control data, bank details) and company code data (reconciliation account, payment terms, dunning data, withholding tax indicators). It does not show purchasing organization data such as order currency, incoterms, or purchasing blocks; that segment belongs to the purchasing view and is reached through MK03 or the combined XK03. The structural fact that explains most support tickets: a vendor is not one flat record. It is general data in LFA1 plus one company code segment per LFB1 entry, and a vendor can exist centrally without ever being extended to the company code someone is trying to post against, which FK03 will report as an error rather than an empty screen.

Reached for whenever someone needs to confirm what is actually stored on a vendor before troubleshooting a posting, a payment run rejection, or a duplicate-vendor suspicion, without risking an accidental change. Typical scenario: an invoice in FB60 fails with a withholding tax or payment terms error, and FK03 is the fastest way to check what is actually configured on the vendor rather than trusting what the requester says. Also used during vendor master audits, bank detail verification before a payment run, and cross-checking a vendor's block status. Where the purchasing view matters as well, XK03 or MK03 is the right call instead, since FK03 will simply omit that data with no warning that it exists elsewhere.

Start in SE16 on LFB1 with LIFNR and BUKRS as filters to confirm the company code segment actually exists; a missing row here, not a display bug, is the usual cause of 'vendor not defined for company code' errors. Cross-check LFA1 on the same LIFNR for SPERR (central block) and LOEVM (central deletion flag), then LFB1 for its own SPERR and LOEVM at company code level. For bank detail complaints, filter LFBK by LIFNR and BANKS/BANKL to see how many bank details exist and which one carries the default indicator.

On S/4HANA the vendor master is technically a Business Partner with a vendor role (commonly role FLVN01), maintained through the BP transaction. LFA1 and LFB1 are retained as compatibility views populated automatically from the Business Partner, so FK03 still displays correct data and remains functional for read access. The Fiori equivalent for display and maintenance is the Manage Business Partner Master Data app. FK01 and FK02 for create and change are the ones actually deprecated in favor of BP; FK03 as a pure display transaction is the least affected member of the FK* family.

Functional FI ownership, shared with MM/procurement for the general and bank data segments since the vendor master is common master data. A clean handover states the LIFNR, the company code involved, whether the issue is a missing extension, a block, or a duplicate suspicion, and includes the LFA1/LFB1 field values already checked. Basis involvement is limited to authorization object assignment when the symptom is restricted rather than missing data.

FK01 and FK02 are the create and change counterparts and the transactions to escalate to once FK03 confirms a missing extension or an incorrect field rather than a genuine posting error. FS00 is worth cross-checking when the vendor's reconciliation account itself seems misconfigured. FBL1N is the natural next stop once the master data is confirmed correct and the question shifts to actual open items and line item history for that vendor. FD10N and FK10N provide balance views once the master record is no longer in doubt.