In this post, I’ll provide clear guidance on the utility OKB9 – Default Account assignment in SAP for automatically deriving CO account assignments during accounting document postings.
Doing this helps prevent errors and ensures accuracy, especially in scenarios where system-generated line items require valid controlling information.
In many business processes, SAP automatically creates accounting document line items—most often for income or expense G/L accounts. These G/L accounts are typically defined as cost elements, which makes a CO account assignment mandatory at the time of posting. When posting FI documents manually, users can supply this assignment directly through FI transaction codes. However, this flexibility does not exist when documents stem from integrated processes in other modules, such as goods issue, goods receipt, invoice receipt, SD billing, or even automatic vendor payments.
In such cases, the system must be able to derive the required CO account assignment automatically. Without proper configuration, postings may fail or result in inconsistencies across finance and controlling.
In this process step, you define the automatic additional account assignments for postings to primary cost elements. When a posting is made to a cost-accounting-relevant line item without an explicitly entered CO account assignment (such as a cost center, internal order, or profitability segment), the system determines the assignment automatically during external accounting postings. This situation commonly arises when the system generates the line item automatically rather than through a manual FI posting.
To support this, the transaction provides four distinct sections that can be used to derive CO account assignments automatically. Each of these sections plays a specific role in ensuring accurate and consistent postings across FI and CO. The following subsections describe these options in detail.
This option is typically used in two scenarios. The first is when the system needs to derive a profitability segment.
This applies to G/L accounts or cost elements that fall under various categories of cost of goods sold (COGS) such as price differences, inventory revaluations, or outbound freight—cases where the costs do not require further distribution, allocation, or assessment to other cost objects. Hence, these costs should be reported directly in CO-PA (Profitability Analysis). The cost element 40100, shown in the figure below, illustrates this scenario.
PrfSeg aims to derive the profitability segment for the line item based on available information in the line item. What do I mean by available information here? Consider the following figure. In this example, the profitability segment was derived automatically based on the profit center entered. You can view these types of postings in the KE24 report for costing-based profitability analysis.
The second scenario applies when the cost element falls under the broader category of sales, general, and administrative (SG&A) expenses. This option has two contrasting aspects—much like two sides of a coin. The limitation is that it does not allow the CO object to be derived based on organizational attributes such as plant or profit center. However, the key advantage is its high reliability: it ensures that the cost element in the accounting document always receives a CO account assignment. This consistency can be difficult to achieve when using the remaining two options, which will be discussed later.
In the figure above, the G/L account is set to receive cost center 1720-8000 during the posting. Hence, when you choose G/L account 46314 to post under company code 1700, the cost center 1720-8000 will be derived automatically, as shown in this figure.
To view the details of the relationship based on which CO object is derived, select the relevant entry (cost element 35000 in this case) and double click on “Detail per profit center.”
This option is selected when maintaining cost center accuracy is essential. In scenarios where each profit center (or location) must always be linked to the correct, predefined cost center, this setting ensures consistency. Since users entering documents that involve this G/L account or cost element may accidentally select an incorrect cost center, this option helps prevent such errors by enforcing the appropriate assignment automatically.
As shown above, only the profit center is entered while the cost center field is suppressed through the field status group. This prevents users from accidentally selecting an incorrect cost center during entry. However, the transaction can still be reported against the appropriate cost center, as confirmed by the ACDOCA table entry of the posted document shown below. You can also view these entries in table BSEG.
This distinction is important when determining the CO object during goods movement postings such as inventory posting, consumption, and GR/IR differences, because these postings reference the valuation area—specifically, the plant.
The Substitution tool can also be used to achieve the same purpose as the OKB9 utility; however, it introduces certain challenges. The table below provides a comparison between OKB9 and CO substitution for automatically deriving CO object assignments.
|
Dimension |
OKB9 (Automatic Account Assignment) |
OKC9 (CO Substitution) |
|
Purpose |
Default CO object for G/L accounts in a simple, stable, SAP-standard way |
Override or fill CO fields based on custom, conditional logic |
|
Where SAP Uses It |
FI, MM, SD, material postings, OBYC logic |
FI & CO line-item formation (after initial determination) |
|
Timing in Posting |
Early — before FI/CO line items are created (pre-document logic) |
Later — during CO/FI line-item generation (post-derivation) |
|
Impact Level |
Structural, deep-level defaulting (affects PA segment creation too) |
Surface-level modification of existing fields |
|
Performance |
Very high performance (SAP-delivered logic) |
Slower; can impact high-volume postings |
|
Risk Level |
Very low risk; stable and predictable |
Higher risk; can break PA flows, cause inconsistencies |
|
Supported By |
Fully SAP-standard and recommended |
Semi-custom; must be justified and maintained carefully |
|
Reads/Uses |
Company code, G/L account, valuation area, profit center |
Document fields, custom tables, user exits, sets |
|
Can Create Profitability Segment? |
Yes — OKB9 can trigger PA segment creation |
No — substitution cannot create a PA segment; only fill fields |
|
Works in OBYC Material Flows? |
Perfectly — designed for it |
Limited; can fail in ML/actual costing/post-closing flows |
|
Flexibility |
Medium (valuation area, profit center, cost center defaults) |
Very high (conditional logic, complex rules) |
|
Typical Use Case |
Default cost center/order for expense G/Ls; valuation-area-based defaults |
If business needs rules like: “If vendor group X and doc type Y → cost center Z” |
|
SAP Best Practice Guidance |
Use FIRST for primary defaulting |
Use only if business needs cannot be met via OKB9 |
|
Maintenance Burden |
Very low |
High (logic must be tested across FI/MM/CO/PA) |
|
Troubleshooting Ease |
Very easy (traceable via G/L and valuation settings) |
Harder (logic may sit in sets, exits, rules) |
|
Risk of Misuse |
Minimal |
High — can override needed assignments and cause inconsistencies |
To finish up, knowing these tables will greatly assist you in validating and comparing the configuration on a large scale.
During document posting, SAP executes the OKB9 default account assignment logic at runtime via function module K_ACCOUNT_ASSIGNMENT_GET. Setting a breakpoint in this function module allows consultants to trace how the system evaluates OKB9 configuration and to understand why a CO account assignment was derived (or not derived) for a specific posting.
Automatic account assignment derivation plays a critical role in financial processes, as cost objects are essential attributes for generating reliable financial statements and ensuring an accurate, transparent cost-control system. OKB9 is a powerful functionality that enables the automatic derivation of CO objects based on various attributes. It empowers functional experts to configure and manage these derivations independently—without requiring any technical development effort.