F_BKPF_BUK — Authorization Object F_BKPF_BUK - Accounting Document Company Code
F_BKPF_BUK controls whether a user can post, change, or display an FI accounting document for a specific company code. It checks the BUKRS value on the document header against the activity attempted (create, change, display). Failures usually trace to a missing company code value in the role or a cross-company code document touching a code the user is not authorized for.
This page covers the F_BKPF_BUK authorization object used to control access to FI accounting documents at company code level. It focuses on where the check fires in the posting and display flow, how to trace a failed check with SU53 and the authorization trace, and the recurring pitfalls around cross-company code documents and activity mismatches.
Published 16 Sept 2026· 906 words
What it protects
F_BKPF_BUK guards every create, change, and display action against an FI accounting document, checked per company code rather than per document. The structural fact that causes most confusion: a single accounting document can carry line items in more than one company code through cross-company code posting, and the check runs once for every distinct BUKRS that appears in that document, not just for the company code the user typed into the entry screen. A user fully authorized for company code 1000 can still be blocked posting a routine invoice if the automatic cross-company code line generates a posting into company code 2000 and the role has no entry for it. This object sits alongside F_BKPF_KOA (account type) and F_BKPF_GSB (business area) as one of the standard document-level checks called from the same posting kernel logic, but it is checked independently and a failure in one does not imply a failure in another.
Fields checked
- BUKRS - the company code of the accounting document being posted, changed, or displayed. Roles typically restrict this to specific values or lists of values rather than a wildcard.
- ACTVT - the activity attempted against the document: 01 for create, 02 for change, 03 for display are the values most commonly assigned. A role with only 03 for a given BUKRS allows display but blocks posting or reversal into that company code.
Where it is checked
- Document entry and posting transactions such as FB01, FB50, FB60, FB70, and the corresponding park-and-post variants check this object at simulate and at save.
- Display and change transactions FB02 and FB03 check it before rendering the document, using ACTVT 02 or 03 respectively.
- Clearing and payment transactions such as F-28, F-32, and F-44 check it for every company code touched by the clearing document, including the offsetting side.
- Logistics-triggered postings, notably MIRO for invoice verification and goods movement postings that generate FI documents, call the check indirectly through the accounting document posting interface.
- Programmatic postings through the standard accounting document posting BAPI and IDoc-based postings run the same check, so batch and interface failures show up here as often as dialog transaction failures.
How to trace a failed check
Start with SU53 immediately after the failure occurs, in the same session, before doing anything else, because SU53 only shows the last authorization check that failed and any intervening action overwrites it. Look for F_BKPF_BUK in the SU53 output and note which BUKRS and ACTVT combination is marked as missing against the user's actual role values. If SU53 is empty or shows an unrelated object, the real check may have happened earlier in the call stack or in a background step; switch to the full authorization trace (started and stopped around the failing action) and filter for F_BKPF_BUK entries with a return code other than zero. Capture the user ID, the exact BUKRS value involved (including any secondary company code from a cross-company code line), the ACTVT attempted, the transaction or program, and the timestamp. Hand this exact set to security rather than a screenshot of the generic error message, since the message text alone does not distinguish a BUKRS mismatch from an ACTVT mismatch.
Whose problem this is
This is a shared ticket. The functional consultant identifies which company code and which activity the process legitimately requires, including any secondary company codes from cross-company code postings. Security owns the role change itself. A complete request states the user ID, the transaction or program, the BUKRS value(s) in question, and the ACTVT needed, sourced from the trace rather than guessed from the business requirement.
Common pitfalls
- The role holds the correct BUKRS but only ACTVT 03, so the user can display the document that triggered a support ticket but still cannot post the correction, and the second failure looks unrelated to the first.
- A cross-company code posting fails on the secondary company code even though the user has full access to the company code they entered on the initial screen; the reflex fix of widening the primary company code value does nothing because the missing value is a different BUKRS entirely.
- Composite or derived roles carry the organizational value at the parent role level but the derived role for the user's actual company code was never generated or was generated before a new company code existed, leaving a gap that looks identical to a missing authorization from the user's perspective.
- A failed F_BKPF_BUK check gets misread as a problem with F_BKPF_KOA or F_BKPF_GSB because the posting error message on screen does not name the specific object; checking the wrong object first wastes a cycle with security.
- SU53 shows a clean result because the actual failing check happened in an earlier call in the same transaction, for example a background validation, leading to the false conclusion that authorization is not the cause when a full trace would have shown otherwise.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Learn this properly
Lessons and topics
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/f-bkpf-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.