Configuring Account Determination: Valuation Classes, Transaction Keys, and OBYC

Explanation

At the intermediate level, consultants must understand the concrete configuration structure that implements automatic account determination, most commonly accessed and reviewed through the OBYC transaction (Configure Automatic Postings). This configuration links four dimensions together: the chart of accounts, the valuation grouping code (also referred to as valuation modification, which groups plants sharing the same account determination logic), the valuation class assigned on the material master's accounting view, and the transaction/event key that represents the type of posting occurring (for example, stock postings, GR/IR clearing, price differences, or consumption postings). A transaction key is a short code that represents a specific accounting event tied to a movement type or invoice scenario. Common transaction keys include one for inventory postings (debiting or crediting stock accounts during goods movements), one for the GR/IR clearing account (used to bridge goods receipt and invoice receipt timing differences), one for price differences (when actual invoice price differs from the standard or moving average price and the material cannot absorb the full difference), and one for consumption postings tied to cost centers or orders. Each transaction key can be configured with rules indicating which of the four dimensions are relevant; some keys require only the valuation class, others require the valuation class plus a general modification key, especially where multiple postings within the same transaction key must be distinguished, such as separate accounts for different types of price variances. When a movement type is posted, the system does not read GL accounts from the movement type directly. Instead, it uses the movement type to determine which transaction key(s) apply (this mapping is standard delivered SAP logic combined with configuration), then uses the material's valuation class and the plant's valuation grouping code to look up the specific GL account configured for that transaction key. This is why two materials with different valuation classes, moved with the identical movement type in the same plant, can post to entirely different inventory accounts: the movement type determines the transaction key, but the valuation class determines the actual account. A critical configuration decision is how granular to make the valuation grouping code structure. Some organizations use very few valuation grouping codes, meaning many plants share the same account determination rules; others assign a unique grouping code per plant or region when local statutory or chart of accounts requirements diverge. This decision has long-term maintenance implications: fewer grouping codes reduce configuration volume but increase the blast radius of any account changes, while more grouping codes give flexibility but increase configuration maintenance effort as new plants are added. Another important structural element is the general modification (sometimes needed within certain transaction keys, particularly around price difference and offsetting accounts) which allows further differentiation beyond valuation class alone, useful when a single valuation class must post variances to different accounts depending on business scenario. Consultants configuring these areas must work carefully because incorrect combinations can either block postings entirely (account determination error at runtime) or, more dangerously, post silently to an unintended but technically valid account, which is much harder to detect and typically surfaces only during reconciliation or audit. From an integration perspective, this configuration is the single point where MM movement types, the material valuation method (standard price versus moving average), and FI/CO general ledger structure intersect. Any change to this configuration in a productive system must go through careful change management, because it retroactively affects the accounting behavior of every future transaction using that valuation class and transaction key combination, and can create inconsistencies with historical postings if not communicated to reporting and reconciliation teams.

Code example

Configuration structure example (illustrative, not a code artifact): Chart of Accounts: INTValuation Grouping Code: 0001 (assigned to Plant 1000, 1100)Valuation Class: 3000 (Raw Materials)Transaction Key: BSX (Inventory posting) -> GL Account: 310000 (Raw Materials Inventory) Valuation Class: 3000Transaction Key: WRX (GR/IR clearing) -> GL Account: 210100 (GR/IR Clearing - Raw Materials) Valuation Class: 7900 (Trading Goods)Transaction Key: BSX -> GL Account: 320000 (Trading Goods Inventory) Note: When a goods receipt is posted for a material with valuation class 3000 in plant 1000,the system resolves valuation grouping code 0001, transaction key BSX, and valuation class 3000to derive GL account 310000 automatically, without manual account entry at posting time.

Real project scenario

A manufacturing client wanted to separate accounting for two sub-categories of raw materials that had previously shared one valuation class, because Finance needed distinct inventory accounts for reporting purposes. The consultant proposed introducing a new valuation class, updating the account determination configuration to map the new valuation class to a new GL account for the inventory transaction key, and then running a controlled mass change of the material master valuation class for the affected material group during a change window, followed by validation goods receipts in a test client before replicating the change to production.

Common mistakes

• Assuming a single transaction key change is isolated, when in fact many movement types and invoice scenarios can route through the same transaction key and are all affected simultaneously. • Overlooking that some transaction keys require a general modification for correct differentiation, leading to postings hitting a default or incorrect account. • Changing valuation grouping code assignments for a plant without recognizing this immediately changes account determination outcomes for all materials moved in that plant going forward. • Failing to test both goods movement and invoice verification postings after a configuration change, since some transaction keys only trigger during invoice processing.

Best practices

• Maintain a documented mapping of valuation classes to their intended material categories and corresponding GL accounts for audit traceability. • Before changing valuation grouping code or valuation class assignments in production, assess the full list of transaction keys and movement types impacted. • Test both goods movement postings and invoice verification postings after any account determination configuration change. • Coordinate configuration changes with FI/CO teams and reconciliation owners, since historical postings will not retroactively change but future postings will.

Interview angle

Interviewers frequently probe whether a candidate understands that GL accounts are derived from valuation class plus transaction key plus valuation grouping code, not directly from the movement type. Being able to explain the difference between BSX-type inventory postings and WRX-type GR/IR postings, and why price difference postings sometimes require a general modification, signals genuine configuration-level understanding rather than surface familiarity.