LFA1 table — LFA1 Vendor Master General Data

One row in LFA1 represents a single vendor account number at the general data level: name, address, country, language, search terms, tax numbers, bank reference indicator, and account group. This data is shared across every company code and purchasing organization that vendor is later extended into. LFA1 does not carry payment terms, reconciliation account, or purchasing conditions; those are org-dependent and sit in LFB1 (company code) and LFM1 (purchasing organization). A vendor number existing in LFA1 only means the business partner has been created centrally, not that it can be used on a purchase order or an invoice in a given company code. Central blocking and deletion flags also live here, which is why a vendor can be usable in one company code but centrally blocked from all new postings everywhere.

Always restrict on MANDT first, though most reporting tools set this implicitly. LIFNR is the natural key and is highly selective when known; selecting by NAME1 or LAND1 without a company code filter returns noisy, duplicate-prone results because the same legal entity can appear under several vendor numbers. LFA1 alone is a small, fast table to scan by primary key, but it says nothing about whether the vendor is usable anywhere; do not conclude from a clean LFA1 row that the vendor can post. Before treating a vendor as fully set up, the company code extension in LFB1 and the purchasing organization extension in LFM1 both have to be checked separately.

Symptom: a buyer reports the vendor cannot be selected when creating a purchase order for a given purchasing organization. Select LFA1 by LIFNR to confirm the vendor exists centrally and that SPERR and LOEVM are blank. Then select LFM1 by the same LIFNR and the purchasing organization in question. If no row comes back, the vendor was created centrally but never extended to that purchasing organization, which is the actual cause, not a master data corruption in LFA1.

In S/4HANA, vendor master data is technically stored through the business partner model, with LFA1 retained as a compatibility view over the underlying business partner tables so that existing reports and custom code using LIFNR continue to work. Reads against LFA1 still function; new vendor creation is expected to go through business partner maintenance rather than the classic vendor transactions. Field content and behavior for general data are largely unchanged from a reporting perspective, though the source of truth has moved.

Vendor master data governance sits with the MM master data or vendor maintenance team, often a shared service function, not with the requester or buyer. Extension to new company codes or purchasing organizations typically requires a formal request through that team, since it touches reconciliation account assignment and payment terms that finance also has to agree to.

LFB1 carries the company code segment written when a vendor is extended for accounting purposes. LFM1 carries the purchasing organization segment written during purchasing extension. EKKO and RBKP reference LFA1-LIFNR directly on purchase orders and incoming invoices. Vendor master maintenance and extension are performed through the standard vendor master transactions rather than direct table edits.