OB52 — Posting Period Variant Configuration

OB52 maintains permitted posting periods per posting period variant and account type. Each row defines two period ranges: a normal range covering periods 1 through 12 (or however many the fiscal year variant defines), and a second range reserved for special periods used for year-end adjustments. Rows can be entered against a specific account type (A assets, D customers, K vendors, M materials, S G/L accounts) or against the wildcard account type plus, which applies to all types not given their own row. The one fact that explains most of the confusion around OB52: it configures the posting period variant, a standalone object, not the company code. The company code only holds a pointer to a variant, and that pointer is maintained elsewhere. Several company codes commonly share one variant, so a change made here can lock or unlock periods for more than one company code at once.

OB52 comes up at every period close and every fiscal year opening: closing the current period to stop postings, opening the next period, opening the special periods for year-end adjustment entries, or granting a temporary exception to one account type or one authorization group while the rest of the ledger stays closed. It is also the first stop when a posting fails with a period-not-open error, before anyone touches the posting transaction itself. It is a configuration transaction, not something used during a normal posting run, and it has no Fiori replacement for daily use; closing calendars and period locks are still driven from this table underneath any Fiori close-management app.

Find the posting period variant on the company code record in T001, then browse T001B in SE16 filtered on that variant. Check the row for the specific account type first, then the plus wildcard row, since the specific row wins. Compare the posting date's period against the from-period/to-period columns in both ranges. If the posting sits between the two ranges, or falls in the special-period range without the posting itself being a special-period document, the row is the root cause rather than the posting transaction.

OB52 and the underlying posting period variant concept are unchanged on S/4HANA; the transaction is still the standard way to maintain open periods. Closing-cockpit and financial-close Fiori apps sit on top of this configuration for scheduling and monitoring but do not replace it as the place where the period ranges themselves are defined. Anyone doing hands-on period maintenance still ends up in OB52 or its underlying view.

This is FI functional configuration, owned by the general ledger or financial close process owner, not Basis or ABAP. A handover to a consultant investigating a period error should include the company code, the posting date and period involved, the account type of the document, and whether the same document type posts successfully in a different company code sharing the same variant.

FB50, FB60, FBL1N and similar posting or display transactions are where the period-closed error actually surfaces, so they are the natural first stop before tracing back to OB52. FBRA is relevant because clearing reversals are also blocked by a closed period on the reversal posting date, which is a frequent point of confusion during month-end. FAGLB03 is useful for confirming which periods currently hold balances, which helps decide whether reopening a period is actually safe.