KI 235 — KI 235 — Account Requires an Assignment to a CO Object

KI 235 is raised when an accounting line is posted to an account that requires a Controlling assignment, but the system cannot determine a valid CO object for that line. Typical CO objects include a cost center, internal order, WBS element, profitability segment or another object accepted by the posting logic. The message is common in direct FI postings, goods movements, invoice verification, asset-related postings and interfaces. The key diagnostic point is that the G/L account and the business process together determine whether a CO assignment is mandatory; the same document type may succeed for one account and fail for another.

The most common cause is simply a missing cost center, order or WBS on a manually entered line. In automatically generated postings the problem is usually upstream: the source transaction does not provide a CO object, OKB9 does not have an appropriate default for the account, a substitution does not fire for that posting path, or account determination selects a cost-relevant account unexpectedly. In logistics scenarios, valuation class, transaction key and account determination can indirectly lead to a cost element that needs CO assignment. Another frequent trap is assuming an OKB9 entry maintained at a detailed level will also work for automatically generated lines that do not carry the same item-level reference.

Start with the exact failing accounting line, not the header message. Identify the G/L account, company code, posting key, amount, source transaction and whether the line is entered manually or generated automatically. Check the account master and cost-element relevance, then inspect whether the expected CO object exists and is valid for the posting date. For direct FI postings, compare a successful document with the failed one. For automatic postings, review OKB9 defaults and any CO substitutions, then trace the source document to see whether cost center, order, WBS or other assignment was available before the FI document was built. In interface or EWM scenarios also inspect the queue payload and the document that created the accounting call.

For a manual posting, enter the correct CO object on the affected line and repost. For an automatic posting, correct the determination logic rather than forcing a value at the final accounting step. Maintain a suitable OKB9 default when the business rule genuinely allows a stable default account assignment. Use substitution only where the derivation rule is deterministic and approved by Finance/Controlling. If the wrong G/L account is being determined, fix the underlying account determination instead. For queues or interfaces, correct the source master data or mapping and then reprocess after validating that the same error will not recur. Always retest reversal and background variants because they may use different posting paths.

A common reaction is to remove the requirement for a CO assignment, change field status, or make the message less strict. That can hide the symptom while creating incomplete CO reporting, incorrect cost allocation or inconsistent behavior between manual and automatic postings. Another weak fix is to hard-code a cost center in an enhancement without checking company code, account, validity dates or business context. That may make one scenario post while sending costs to the wrong object elsewhere. The correct approach is to understand why the account is cost-relevant and where the business process is expected to derive the CO object.

KI 235 is usually a joint FI/CO ownership issue, with MM, SD, Asset Accounting, EWM or integration teams involved when the posting is generated outside FI. FI should confirm the G/L account and accounting-interface behavior; CO should validate the required account assignment and defaulting/substitution design; the source-process team should confirm what assignment data is available. ABAP or integration support is needed only when the expected business data exists but is lost or not transferred into the accounting interface. This ownership split prevents unnecessary code changes for what is often a configuration or master-data issue.

Do not assume that because an account assignment exists somewhere in the source document it is available on the exact accounting line that fails. Do not compare only document headers; compare the generated line items. Check validity dates for cost centers, orders and WBS elements. Be careful with year-end or period changes where an object was valid previously but not for the new posting date. In automated postings, verify the level at which OKB9 is maintained and whether that level is compatible with the generated line. Finally, after fixing the immediate error, validate reporting in CO so that the document is not merely postable but also correctly assigned.