LFB1 table — Vendor Master Company Code Data
LFB1 holds the company-code-specific extension of the vendor master: reconciliation account, payment terms, payment methods, payment and posting blocks, and the accounting clerk assigned. A vendor exists generally in LFA1 but is only usable for posting and payment in a given company code once a matching row exists in LFB1 for that BUKRS.
LFB1 is the accounting-view extension of the vendor master, one row per vendor per company code. This page covers the fields consultants actually query when a vendor cannot be paid or posted to, how LFB1 joins to LFA1 and purchasing data, and the recurring mistake of treating a missing LFB1 row as a missing vendor.
Published 15 Sept 2026· 1,023 words
What it stores
One row represents the accounting-relevant extension of a vendor for one company code. LFA1 carries the vendor's general, client-wide data - name, address, bank details reference, vendor group - but none of that is enough to post an invoice or run a payment. LFB1 is the record that makes a vendor usable inside a specific company code: it carries the reconciliation account that vendor postings hit in the general ledger, the payment terms and payment methods valid for that entity, any posting or payment block specific to that company code, and the accounting clerk responsible. A vendor can exist in LFA1 for years without ever having an LFB1 row for a given company code, and in that state no invoice can be posted against it there regardless of what purchasing data exists.
Key fields
- MANDT - client
- LIFNR - vendor account number, joins to LFA1
- BUKRS - company code this row applies to
- AKONT - reconciliation account in the general ledger for this vendor in this company code
- ZTERM - payment terms key used to calculate due dates on invoices
- ZWELS - payment methods permitted for this vendor in this company code
- ZAHLS - payment block key applied at company code level
- SPERR - posting block flag for this company code
- LOEVM - deletion flag at company code level
- FDGRV - planning group used by cash management and liquidity forecasting
- BUSAB - accounting clerk assigned to this vendor
How it joins the data model
- LFB1-LIFNR = LFA1-LIFNR to pull the vendor's name, country, and general control data
- LFB1-LIFNR = LFM1-LIFNR when the same vendor also needs to be checked at purchasing organization level
- LFB1-LIFNR = EKKO-LIFNR to confirm which company code a purchase order's vendor is actually extended to
- LFB1-LIFNR = RBKP-LIFNR and LFB1-BUKRS = RBKP-BUKRS to confirm an incoming invoice was posted against a valid vendor-company code combination
- LFB1-AKONT joins conceptually to the general ledger account master, not to any table in this list, and is the field to check first when a vendor posting hits the wrong reconciliation account
How to read it safely
MANDT is the client and must always be restricted, this is a client-dependent table. LIFNR plus BUKRS together are the effective key and both should be specified whenever possible - selecting on LIFNR alone across all company codes is common when a vendor has been extended to several entities with different payment terms, which is itself a frequent source of confusion. The table is not large in absolute terms compared to transactional tables, but production systems can carry tens of thousands of vendor-company code combinations, so an unrestricted BUKRS scan across all company codes is still wasteful and should be avoided outside of mass audits.
How to prove it in the data
Symptom: an invoice for a vendor cannot be posted in a specific company code, with an error about the vendor not existing there. Select LFB1 with LIFNR equal to the vendor number and BUKRS equal to the target company code. No row returned confirms the vendor was never extended to that company code - the fix is extending the vendor master to that BUKRS, not re-entering the invoice.
ECC vs S/4HANA
LFB1 continues to exist as a physical table in S/4HANA and is not deprecated. Vendor master maintenance has moved toward the business partner model with role-based synchronization, and in many S/4HANA implementations LFB1 is kept current automatically through that synchronization rather than maintained directly, but the table itself and its content remain the same as in ECC.
Common pitfalls
- Assuming a vendor problem is a purchasing problem when it is an accounting extension problem: a vendor visible and usable in one company code can be completely absent from LFB1 in another, and the purchase order will still save fine because PO creation checks purchasing data, not company code extension, until the invoice or payment step
- Reading SPERR or the deletion flag at LFB1 level and assuming it applies everywhere: both fields exist at company code level and a vendor can be blocked in one entity and fully active in another
- Changing AKONT directly in LFB1 without checking open items already posted to the old reconciliation account: existing line items keep the account they were posted with, only new postings pick up the change, which produces an apparent inconsistency between the vendor master and the general ledger balance
- Treating ZWELS as the complete answer to which payment method will actually be used: the payment run also considers the payment method entered on the individual line item and the house bank configuration, so LFB1 only defines what is permitted, not what will be selected
- Confusing a payment block set here with a payment block set on the individual invoice line item: clearing the one in LFB1 does not release invoices that were blocked at document level, and vice versa
Whose problem this is
Master data governance or the accounts payable master data team owns changes to LFB1 content such as reconciliation account and payment terms. Functional AP configuration teams own the payment method and block configuration. A consultant investigating a posting or payment failure should confirm the LFB1 state first before escalating, since most extension and block issues are resolved by a master data change rather than a configuration change.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/lfb1ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.