F_BKPF_KOA — Account Type Authorization for FI Document Posting
F_BKPF_KOA controls whether a user can post, park, or display a document line item against a given account type - asset, customer, vendor, material, or G/L. It is checked per line item, so a single document touching several account types needs the corresponding KOART value for each one, independent of company code or master data authorization.
This page covers the F_BKPF_KOA authorization object, which restricts FI document posting activity by account type (KOART) rather than by company code or specific account. It explains where the check fires, how to trace a failure with SU53 and the authorization trace, and the recurring confusion between this object and the separate master-data authorizations on vendor, customer, and G/L accounts.
Published 16 Sept 2026· 878 words
What it protects
F_BKPF_KOA guards the ability to create, change, park, or display an accounting document line item belonging to a specific account type: asset (A), customer (D), vendor (K), material (M), or G/L account (S). The structural fact that causes most confusion is that this object says nothing about which account, company code, or business area the line item belongs to - it only cares about the account type category. A user can be fully authorized for KOART K and still be blocked from posting to a particular vendor if the vendor master carries an authorization group the user lacks, or blocked entirely if company code authorization is missing. Because a single FI document commonly contains several account types in one posting (a vendor invoice line plus tax and G/L expense lines, for example), the check fires once per distinct account type present, not once per document.
Fields checked
- ACTVT - the activity being performed: typically 01 (create), 02 (change), 03 (display), or equivalent values for park and reverse. Missing the correct activity value is the most common single-field failure.
- KOART - the account type of the line item being posted: A for asset, D for customer, K for vendor, M for material, S for G/L account. A role scoped to only KOART S will fail the moment a document line touches a vendor or customer account, even if every other authorization is correct.
Where it is checked
- FB01, FB50, FB60, FB70, F-02, F-22, F-28, F-53 and the other classic FI entry transactions - checked at the point each line item is added to the document buffer, before simulation and before final save.
- Document parking transactions such as FBV0 - the check fires on park as well as on post, using the activity matching the action taken.
- Any custom or standard program that routes through the standard FI posting interface, including postings generated from MM invoice verification (MIRO) once the accounting document is built, and postings created via BAPI_ACC_DOCUMENT_POST or similar posting APIs.
- Batch input and background jobs that create FI documents - the check runs under the executing user's authorization, not the job scheduler's, which is a frequent surprise in interface failures.
How to trace a failed check
Start with SU53 run immediately after the failed posting attempt, in the same session, before doing anything else - it only captures the last failed check. Confirm the object shown is F_BKPF_KOA and note which field failed: usually KOART, occasionally ACTVT. If SU53 comes back empty or shows an unrelated object, the check may have failed in a background work process or a prior step already cleared the buffer; in that case run the authorization trace (ST01 on older releases, STAUTHTRACE on current ones) filtered to the user ID and the transaction, then reproduce the posting. Read the trace for every F_BKPF_KOA entry, not just the first, since a multi-line document generates one check per account type. Hand the security team the user ID, the transaction or program, the exact KOART value that failed, the activity, the company code involved, and the document type - not just 'access denied posting an invoice'. Vague tickets get vague fixes.
Whose problem this is
This sits with security once the missing value is identified, but functional needs to do the identification first: which account type, which activity, and whether the business actually wants that user posting to that account type at all. A good ticket names the failed KOART and ACTVT values from SU53 or the trace, the transaction used, and confirms the business justification, rather than asking security to 'give the user full posting rights'.
Common pitfalls
- Role looks correct because KOART S is maintained, but the failing document has a vendor or customer line - the tester used FB50 (G/L only) to validate the role and missed the account types actually used in production.
- Automatically generated lines - tax, cash discount, exchange rate difference, clearing - introduce account types the initiating user did not expect, so a manually reviewed 'authorized' document still fails when the system adds a line behind the scenes.
- Composite or derived roles merge organizational values incorrectly, leaving KOART restricted to a subset even though the individual roles each look fine in isolation - the merge, not either source role, is the actual defect.
- A failed F_BKPF_KOA check is wrongly diagnosed as a company code or business area problem, prompting an unnecessary change to F_BKPF_BUK or F_BKPF_GSB that does not fix anything and obscures the real gap.
- Granting KOART for every account type as a blanket fix to close a ticket quickly, which passes audit scrutiny poorly since it removes the intended segregation between, say, vendor posting and asset posting authority.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/f-bkpf-koaERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.