F_SKA1_BUK — G/L Account Company Code Authorization

What it protects

Fields checked

• BUKRS - the company code whose G/L account segment is being accessed; restricts which company codes' account data the user can see or maintain, usually held as a list or range in the role.
• ACTVT - the activity being performed against the segment; the standard CRUD values apply, typically 01 for create, 02 for change, 03 for display, and 06 for delete, and a role often grants display broadly while restricting create and delete to a small set of company codes or excluding them entirely.

Where it is checked

• FS00 (centrally, with chart-of-accounts and company code tabs combined) - the check fires when the company code tab is opened, changed, or saved, independently of the chart-of-accounts check on the same screen.
• FSS0, FSS1, FSS2, FSS3 - the company-code-only maintenance transactions; every call is a direct hit on F_SKA1_BUK for the entered company code and the activity implied by the transaction (create, change, display).
• Mass maintenance and batch tools such as batch input sessions, LSMW, or migration cockpit loads that create or update G/L account company code segments - the check runs per company code inside the load, so a load spanning several company codes can partially succeed and partially fail depending on which BUKRS values are missing from the executing user's role.
• Background jobs and interfaces that programmatically extend an account to a new company code also trigger the check under the job's execution user, not the requester's user, which is a frequent source of mismatched expectations.

How to trace a failed check

Whose problem this is

Common pitfalls

• Role includes BUKRS as a range or list that was set up before a new company code went live, so the account extension to that company code fails even though the same user maintains accounts fine in every older company code.
• ACTVT 02 (change) is granted without ACTVT 01 (create), so the user can edit existing accounts in a company code but cannot extend a new account into it, and the resulting error is easy to misread as a missing BUKRS entry rather than a missing activity.
• The failure is blamed entirely on F_SKA1_BUK when the actual blocking object is the parallel chart-of-accounts check; adding company codes to this object's field values does nothing if the chart-of-accounts segment check is what is failing.
• SU53 only reflects the last check in the session, so after fixing the object it displayed, the same action can fail again on a different, earlier-in-sequence object that SU53 never showed, leading to a false conclusion that the fix did not work.
• Mass loads and interfaces run under a service or background user whose role was scoped narrower than the dialog user's role, so a load that works fine when triggered manually fails intermittently when scheduled, and the difference is invisible unless the trace is taken against the correct execution user.