Field Status Blocking Document Posting

An accountant or AP clerk reports that a specific invoice or journal entry simply will not save. The screen throws an error naming a field - cost center, profit center, assignment, text, business area - saying it is either required and empty, or filled in but not allowed. The user insists nothing has changed on their side: they posted the same type of document yesterday. Sometimes it only happens for one GL account, sometimes for one posting key, sometimes only in one company code. The complaint usually lands as 'the system won't let me post this invoice, it says something about a field I don't normally fill in' rather than as a technical description, and it often surfaces right after a chart of accounts change, a new GL account creation, or a transport that nobody flagged as posting-related.

Pull FBL3N or FAGLL03 for the GL account named in the error and check whether other documents posted successfully to the same account with the same posting key in the recent past, which narrows the window for when the field status changed. Cross-check the field status group assigned to the account against other accounts sharing that group in SKB1, to see whether the failure is isolated to one account or will hit an entire account family.

If the conflict is a genuine mismatch between the posting key's field status and the account's field status group, the fix is a configuration change in OBC4 or OB41 and must go through transport; it cannot be corrected on the live document. Before changing a field status group, check every other GL account assigned to that same group, since the change is not account-specific and can silently open or close a field on unrelated accounts. If the account was created by copying a template and inherited the wrong field status group, the fix is a master data correction in FS00 for that account only, reassigning it to the correct group - this is a data fix, not a transport. If the problem is a newly mandatory CO dimension colliding with a suppressed field, the field status group needs to move that field from suppressed to optional or required so the derivation or the user can populate it; this again is a transportable config change and should be tested against every document type that posts to that account. If a validation is deriving into a suppressed field, either adjust the field status group or scope the validation to exclude that account or company code.

The reflex fix is to open the field status group in OBC4 and set the offending field to optional across the board, or to relax the posting key field status instead of the account. This makes the immediate error disappear but removes a control that was often there for a reason: a required cost center enforced for CO postings, a required text field for audit trail, a suppressed field kept off certain accounts to stop a document splitting derivation error downstream. The document posts, but reporting gaps or CO reconciliation breaks appear weeks later, and by then nobody connects it back to the field status change.

Field status variant and posting key configuration sit with the FI configuration team; GL account master data, including the field status group assignment on individual accounts, sits with FI master data. The handover note should carry the exact field name from the error, the GL account and posting key combination that failed, the field status group involved, and a note on whether the fix is scoped to one account or requires impact analysis across every account sharing that group.