F_LFA1_BUK — Vendor Master Company Code Authorization
F_LFA1_BUK controls access to the company code segment of the vendor master record (LFA1/LFB1 data), checked by company code and activity whenever a user creates, changes, displays, or blocks a vendor's accounting data. A failed check almost always means the role is missing the specific company code value, not that the vendor master authorization concept itself is broken.
This page covers what F_LFA1_BUK actually restricts in vendor master maintenance, the fields it checks, where in the transaction flow SAP fires the check, and how to isolate a failed authorization from the more common general-data and purchasing-org checks that get confused with it. It also lists the pitfalls that make an apparently correct role still fail for one company code but not another.
Published 16 Sept 2026· 871 words
What it protects
F_LFA1_BUK guards access to the company code-dependent portion of a vendor master record: reconciliation account, payment terms, dunning data, withholding tax indicators at company code level, and the ability to block or delete a vendor for a given company code. It does not cover the vendor's general data (name, address, search terms) or the purchasing organization data - those sit behind separate objects. The structural fact that explains most confusion: a vendor master record is a single object spanning three segments (general, company code, purchasing organization), each independently authorized. A user can have full access to general data and still be blocked from seeing or maintaining the company code segment for a specific company code, which looks like a broken vendor display but is actually a narrower, correctly working authorization boundary.
Fields checked
- BUKRS - the company code being accessed; must match a value assigned in the user's role for the check to pass, checked per company code independently of any other segment
- ACTVT - the activity being performed against the company code segment, typically create (01), change (02), display (03), and block/mark for deletion (varies by activity value assigned in the role)
Where it is checked
- Vendor master maintenance transactions covering the company code view - creating, changing, or displaying the accounting segment of a vendor record fires the check as soon as the user enters or confirms a company code
- Vendor line item and balance display transactions that pull company code-specific vendor data check this object before rendering line items for that company code
- Vendor master mass maintenance and data transfer programs check it per company code processed, so a batch job touching multiple company codes can fail partway through on the first one the user lacks
- Automatic payment program and dunning runs that read or update company code vendor master fields (payment block, dunning block) rely on the same check when triggered interactively rather than via background job under a technical user
How to trace a failed check
Start with SU53 run immediately after the failure, while the session state is still current - it shows the last failed authorization check, but only if no other check has succeeded and overwritten the buffer since. If SU53 is empty or ambiguous, or the user reports the issue after the session ended, switch to the authorization trace (ST01 or the newer trace transaction) recording the exact user, client, and time window, then reproduce the failure and read the trace for F_LFA1_BUK specifically, noting the BUKRS and ACTVT values SAP actually checked. Confirm the vendor's company code segment genuinely exists for that company code - a missing extension looks identical to a missing authorization in some transactions. Hand the security team the object name, the exact BUKRS value that failed, the ACTVT value, the transaction code, and the trace timestamp - not a screenshot of a generic 'no authorization' message, which omits the field values needed to fix the role.
Whose problem this is
This sits with the security team once the functional side has confirmed the vendor's company code segment actually exists and the business case for access is legitimate. A good request states the vendor account group or the specific company code range needed, the activity (display versus change versus block), and whether the need is ongoing or a one-off correction, since company code scope is usually the most tightly controlled dimension in vendor master roles.
Common pitfalls
- A role granted with BUKRS as a wildcard or org-level value in one system transports to another environment where company code assignments differ, so the role looks unchanged but fails for company codes added after go-live
- Users conclude the vendor master itself is broken when the real issue is that the company code segment was never created for that vendor - F_LFA1_BUK correctly denies access to a segment that does not exist, and no authorization change will fix a missing extension
- Display access is granted but change access is scoped to a narrower set of company codes, so a user can see the vendor everywhere but only edit it in a subset, which reads as inconsistent behavior rather than a deliberate role design
- Composite roles built by merging multiple single roles can end up with two different BUKRS value lists for the same object if the merge was not reviewed, silently dropping a company code that was present in one of the source roles
- Testing is done as an admin or superuser account, passes cleanly, and the ticket is closed, only for the same failure to reappear for the actual business user whose role was never touched
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/f-lfa1-bukERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.