Cost Centre Missing on FI Document Line
The FI document posts without a cost centre on a cost-relevant line, usually because the GL account has no default account assignment in the automatic account determination table, no substitution rule fires for that company code, or the cost centre master record is not valid on the posting date. The line either posts blank or the document fails with a message asking for a CO object.
Covers the recurring case where an FI posting to a P&L account goes through without a cost centre, or is blocked because no cost centre can be derived. Walks through the default account assignment, substitution, cost element, and master data validity checks in the order they should be examined, and separates the config fixes from the master data corrections.
Published 16 Sept 2026· 1,113 words
The business symptom
Controlling reports the cost centre balance is short, or a line item appears with no cost centre at all when the report is drilled into. Sometimes the complaint arrives the other way round: an accounts payable clerk cannot post an invoice because the system throws an error demanding a cost centre or CO object on a line the clerk never expected to need one, for an account that has always posted cleanly before. A third variant, common at month end, is a batch interface or recurring entry run that used to populate the cost centre automatically and has quietly stopped doing so, so a whole batch of postings lands unassigned and reconciliation between FI and CO breaks for the period.
The configuration behind it
- No default cost centre maintained for the GL account in the automatic account assignment table (transaction OKB9). This is the single most common cause: the account is cost-relevant but has no default cost centre, business area, or profit centre fallback configured, and no other source supplies one.
- Substitution rule missing, inactive, or not assigned to the company code. A substitution that used to derive the cost centre from a combination of fields (order type, business area, movement type) has been deactivated, has a step sequence problem, or was never transported to the company code now posting.
- Cost centre master record not valid on the posting date. The cost centre exists but its validity period ended, or a new one starts later than the document date, so the system cannot use it even though it is entered manually or derived.
- GL account is not flagged as a primary cost element, or the cost element category is wrong, so the account is technically not CO-relevant and no derivation logic is triggered even though the account behaves like an expense account in reporting.
- Field status group on the account or the posting key suppresses the cost centre field, so a value that would otherwise be entered or derived is blanked out or the field is not offered at all.
- Conflicting OKB9 entries at different levels (company code only, versus company code plus business area or valuation area) where a more specific entry that should win is missing or was deleted, leaving a generic and wrong default in place.
- Interface or batch posting program bypasses standard account assignment logic entirely, populating BAPI or IDoc segments directly without passing through the substitution exit, so any manual maintenance of OKB9 or substitution rules has no effect on that channel.
What to check
- Check the GL account master in FS00 or the cost element master to confirm the account is flagged as a primary cost element with the correct category.
- Check OKB9 for the company code, and for any more specific combination (business area, plant, order type) that should apply before the generic entry.
- Check active substitutions for the company code in the substitution configuration and step through the rule logic to see whether the condition that should fire actually matches the posting data.
- Check the cost centre master in KS03 for validity dates against the posting date of the failing document.
- Check the field status group assigned to the posting key and to the account in OBC4 to confirm the cost centre field is not suppressed.
- Display the actual document in FB03 and look at the line item detail to see whether a cost centre was proposed and overwritten, or never proposed at all.
- For batch or interface postings, check the source program or IDoc segment to see whether it passes a cost centre explicitly, bypassing standard derivation.
How to prove it in the data
Pull a line item report on the GL account for the period in question and filter for entries with a blank cost centre field, or run a CO line item report (such as KSB1) restricted to the account and compare the count against the FI line item count for the same account and period. A gap between the two counts is the unassigned population; the posting dates on those lines usually cluster right after a substitution or OKB9 change went live.
Resolution path
Config-only fixes needing transport: adding or correcting an OKB9 default account assignment entry, creating or repairing a substitution rule, changing a field status group, or correcting the cost element category on the account. All of these move through development and quality before production. Data-only fixes, no transport required: extending the validity period of a cost centre master record, or correcting a wrong cost centre on an individual open document via a CO repost if the document has already posted incorrectly. If a batch of documents has already posted without a cost centre, the correction is a CO transfer posting or account assignment change, not a reversal and repost of the FI document, unless the FI posting itself is also wrong. Where an interface bypasses derivation entirely, the fix sits with the interface development team, not with FI/CO configuration, and needs the interface to be extended to call the same substitution or default logic used by manual entry.
The fix people try first (and why it fails)
The common reflex is to enter a cost centre manually on every affected document as it comes up, or to create a dummy or suspense cost centre and route everything unassigned through it via a periodic assessment. Both mask the underlying gap rather than close it. Manual entry does not scale and depends on the person posting knowing the correct value, which they usually do not. The dummy cost centre approach makes CO reporting appear complete while quietly corrupting the cost centre balances the rest of the organisation relies on for allocations and settlement.
Whose problem this is
Ownership sits with FI/CO configuration, since the fix is almost always in OKB9, substitution, or field status settings rather than in the posting transaction itself. The handover note should list the account and company code affected, the OKB9 or substitution entry that is missing or wrong, and whether any documents already posted without a cost centre need a CO correction posting before the config fix is applied.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-functional-issues/cost-centre-not-derived-on-the-fi-postingERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.