FK02 — Change Vendor Master FI View

FK02 maintains the accounts payable view of a vendor master record: general data held once per client (name, address, control data, bank details at general level) and company-code data held once per company code (reconciliation account, payment terms, payment methods, dunning procedure, withholding tax indicators). The structural fact that explains most confusion is that a vendor is not one flat record but three layered segments -- general, company code, and purchasing organization -- and FK02 only ever touches the first two. Purchasing organization data (order currency, incoterms, purchasing block) is maintained through MM transactions or the combined vendor transactions, never through FK02. A vendor can look fully maintained in one company code and completely absent in another because extension is per segment, not automatic.

FK02 is reached for whenever an existing vendor's finance attributes need updating without going through the purchasing department: new bank account after a vendor changes banks, correction of payment terms after a contract renegotiation, adding a company code extension is done separately in FK01, updating withholding tax indicators before a payment run, or unblocking a specific field for payment. It sits squarely in the master data maintenance step of the procure-to-pay cycle, upstream of invoice posting and the payment run. In an environment where MM is active and the vendor is also a supplier for purchasing, the combined transaction covering all three segments is used instead so purchasing and finance data stay in sync; FK02 alone is the right tool when the vendor is finance-only or when the requester has no MM authorization.

To confirm what a vendor actually has stored, run SE16 on LFB1 filtered by vendor number and company code and compare the reconciliation account, payment terms, and payment block fields against what the user reports seeing on screen. To trace who changed a value and when, run SE16 on CDHDR filtered by object class for vendor master and object value equal to the vendor number, then join to CDPOS on the change document number to see the old and new field values and whether the change is still pending confirmation. Absence of an LFB1 record for the company code proves the vendor was never extended there.

In S/4HANA, vendor master data is technically stored as a Business Partner with vendor role, and LFA1/LFB1 are kept in sync automatically underneath. FK02 remains usable and often redirects internally to the Business Partner transaction depending on system configuration. The standard forward-looking entry point is the Fiori app for maintaining Business Partners, which presents general, company code, and purchasing data together in one role-based screen rather than the separate FI-only view FK02 offers.

This is functional territory, owned by the FI/AP master data team or accounts payable process owner. Field status group and account group configuration issues route to the FI configuration consultant. Basis is only involved for authorization object assignment. A good handover includes the vendor number, company code, the exact field changed, and the CDHDR/CDPOS extract showing old versus new value and confirmation status.

FK01 is the natural predecessor for creating or extending a vendor before FK02 can touch a given company code segment. FK03 is the display-only counterpart, useful for confirming what changed without risking a further edit. FS10n and FBL1n are worth reading next to see how the reconciliation account and vendor line items behave once the master data change is live, since a wrong reconciliation account only shows up as a posting error downstream.