OKB9 — OKB9 default account assignment for CO objects

OKB9 stores the default CO object - cost center, internal order, WBS element or profit center - that the system inserts automatically when a document is posted to a profit and loss account without the user or interface supplying account assignment. It only applies to accounts that exist as primary cost elements in Controlling; balance sheet accounts never appear here because they carry no CO relevance. The structural fact that causes most confusion is the specificity hierarchy: an entry keyed to a specific company code and G/L account takes precedence over a global entry made with the company code field left blank for that same account. Consultants who add a company-code-specific line assuming it 'adds to' the global one are often surprised when the global entry keeps firing for other company codes, or the specific entry silently overrides a global one they forgot existed.

OKB9 gets configured when a new profit and loss account is created and needs a fallback cost object, when a new company code is onboarded and inherits accounts that already have global defaults, or reactively when a posting - manual FI entry, MM invoice, bank statement, or asset transaction - fails with a message about missing CO account assignment. It sits in the customizing layer, reached via the IMG path for Controlling account assignment or called directly by transaction code, not through a Fiori app, because it is not a transactional object with its own document number. A consultant reaches for OKB9 rather than the G/L account master (FS00) when the question is 'where does this cost land by default', and reaches for the cost center master (KS03) afterward to confirm the target object is actually open for posting.

There is no reliable ad hoc table browse for this configuration because the underlying customizing table name is not exposed consistently across releases; the safe recipe is to open OKB9 in display mode, filter by the G/L account and company code from the failing document, and note whether a company-code-specific line exists in addition to a blank-company-code line. Cross-check the cost center named there in the cost center master to confirm its validity dates cover the posting date and its status is not blocked. Then look at the failing document's line item to confirm no manual account assignment was entered that would have bypassed OKB9 entirely.

OKB9 is unchanged on S/4HANA; it remains a customizing transaction reached the same way, and no Fiori app replaces it since it has no transactional data of its own. What has shifted around it is the weight of profit center derivation, since the universal journal and document splitting make the profit center outcome more visible and more consequential when OKB9 and cost center master profit center assignments disagree. The underlying logic of company-code-specific versus global entries is identical to ECC.

Functional Controlling or FI consultant territory; this is customizing, not development, and Basis has no role beyond transport release. A good handover includes the G/L account, company code, the exact error message text from the failing posting, the posting transaction that triggered it, and whether a manual account assignment was attempted on the document.

Read the G/L account master next to confirm the account's cost element status and account type. Read the cost center master to check validity periods and the assigned profit center, since both drive whether an OKB9 default actually posts cleanly. Look at the FI posting transactions that most often surface the missing-account-assignment error, since that is where the symptom is reported even though the fix lives in OKB9 or in the master data behind it.