SAP F5 060: Posting Only Possible in Periods X and Y
SAP F5 message posting period closed for account type
Also searched as
- SAP error posting only possible in periods 2026/09
- how to open posting period in SAP
- F5 060 period not open SAP fix
Short answer
Message F5 060 fires when a document date falls in a fiscal period that the posting period variant has not opened for that account type. Either change the document/posting date into an open period, or have Finance open the required period and account type in OB52 for the relevant variant.
Applies to: SAP ECC 6.0 and S/4HANA, all releases of FI (Financial Accounting)
Resolve F5 060 period closed
- 1Read the full message text - it names the two open periods (e.g. 2026/09 and 2026/08) and the account type letter (A, D, K, M, S) the posting hit.
- 2Confirm the posting date and document date on your document; the simplest fix is often just correcting a mistyped date into the already-open period.
- 3If the date is correct and the period genuinely needs to be open, identify the posting period variant assigned to the company code via SPRO > Financial Accounting > Financial Accounting Global Settings > Ledgers > Fiscal Year and Posting Periods > Posting Periods > Assign Variants to Company Code, or transaction OBBP.
- 4Open transaction OB52 and locate the variant, account type and period range you need to extend.
- 5Add or edit the row for the relevant account type: A (Assets), D (Customers/AR), K (Vendors/AP), M (Materials), S (G/L accounts), + (all account types), setting From Period 2/Year and To Period 2/Year to cover the posting date.
- 6Save and have the original user retry the posting.
- 7If this is a recurring month-end timing issue, agree a standing calendar with Finance for when periods close so requests do not become ad hoc emergencies.
What the posting period variant actually controls
OB52 does not control periods per company code directly - it controls a posting period variant, which one or more company codes are assigned to via OBBP. Each row in OB52 defines, for a given account type, which period range is open for normal postings (period 1) and which wider range is open for closing/adjustment postings (period 2).
Account type + (all account types) is a shortcut row; if it is absent, each account type (A, D, K, M, S) needs its own explicit row or it defaults closed. That distinction trips up a lot of period-close tickets where G/L (S) was opened but AP (K) subledger postings still fail.
Why account type matters for the fix
A vendor invoice hits account type K, a customer invoice hits D, a G/L journal hits S, and an asset posting hits A. Opening only the S row and assuming AP or AR will also work is the single most common repeat ticket on this error - each account type needs its period range checked independently in OB52.
Materials Management postings (goods movements, invoice verification) use account type M, which is separately governed by MM period control (transaction MMPV / MMRV) in addition to the FI posting period variant - both have to be open for an MM-originated FI document to post.
OB52 -> Variant: <variant id> -> filter Account Type
OBBP -> confirm which variant your company code is assigned to
MMRV -> check current MM period status (separate from OB52)
Controlling who can open closed periods
Many organizations deliberately restrict OB52 change access to a small Finance/controlling group and route requests through a ticket so every late posting into a closed period is visible and approved, rather than self-service by any FI-authorized user.
A common compromise is keeping period 2 (the special/adjustment period range) open wider than period 1 at all times, and requiring documented approval only for reopening period 1 after formal close - this limits how often OB52 itself needs urgent changes.
Common causes beyond a simple typo
Batch interfaces (IDocs, LSMW loads, third-party integrations) that run on a schedule can queue documents dated for a period that closes before the batch executes, producing a wave of F5 060 errors overnight that look unrelated at first glance.
Time zone and system date mismatches between an interface server and the SAP application server occasionally push a document's system-derived posting date one day past a month boundary, closing the intended period just before the batch runs.
Common pitfalls
- !Opening account type + without checking whether Materials Management period control (MMRV) also needs to move will still leave MM-originated postings failing.
- !Leaving old periods open indefinitely after close defeats the point of period control and increases audit risk - close them back down once the correction is posted.
- !OB52 changes apply to every company code sharing that variant, not just the one that raised the ticket - check the assignment in OBBP before widening periods.
- !A wide period 2 range meant for adjustments can let normal transactional postings slip into prior periods unnoticed if account type + is left open too broadly.
- !Changing the posting date on a document without checking exchange rate or tax determination effective on that date can shift downstream values, not just close the F5 060 error.
How an ERP-grounded AI assistant handles this
ERPray grounded on your SAP FI configuration can answer 'which periods and account types are open right now for company code X' directly from OB52/OBBP without a user opening SPRO, and can flag when an MM period (MMRV) is out of sync with the FI posting period variant before a batch job fails overnight.
Frequently asked questions
What does account type + mean in OB52?
It is a wildcard row that opens the period range for all account types at once (A, D, K, M, S). If a specific account type also has its own explicit row, that row overrides the + row for that type, so check both when troubleshooting.
Does opening a period in OB52 also open it for Materials Management postings?
Not fully. Goods movements and invoice verification also depend on the separate MM period status controlled by MMRV/MMPV. Both the FI posting period variant and the MM period need to be open for an MM-driven FI document to post.
Why did F5 060 appear on a batch load overnight with no user involved?
Scheduled interfaces (IDoc, LSMW, third-party) post with a system-derived date. If the job runs after a period closes, or a source system's date crosses a month boundary before SAP's, every document in that run can fail with F5 060 simultaneously.
Should end users have access to OB52?
Generally no. Most organizations restrict period control to a small Finance/controlling group and route reopening requests through approval, since it affects every posting for that company code and account type, not just one document.
Related
SAP M7 021: Deficit of SL Stock Quantity
M7 021 fires during a goods issue, delivery, or confirmation when SAP checks the unrestricted-use (SL) stock for the exact plant, storage location and batch combination and finds less than what you are trying to post out. Fix the entry (batch, storage location, quantity) first; only enable negative stock or downgrade the message to a warning if the business genuinely needs to post ahead of a receipt.
Error fixSAP KI 235: G/L Account Requires an Assignment to a CO Object
KI 235 means a primary cost or revenue element exists (or should exist) on a P&L account, but the posting you are entering has no valid Controlling object - cost center, order, WBS element or profitability segment - to receive it. Add the account assignment on the posting, or set a default cost center via OKB9 so future postings resolve automatically.
How-toSAP VL150: Collective Processing of Documents Due for Delivery
VL150 (and its more commonly used successor VL10) mass-creates outbound deliveries for sales orders that are due by a selected date, based on shipping point, route, and delivery-relevant item category. Orders that do not appear are usually held back by a delivery block, an incomplete order, a failed availability check, or a delivery date outside the selection window.
Error fixSAP CO11N Confirmation Errors and How to Fix Them
CO11N (time ticket confirmation for production/process orders) throws several distinct errors: deviation from the standard value is too large, goods movement not possible for a component, or the order/operation status does not allow confirmation. Each has a specific cause in order status, routing tolerance settings, or component availability, not a single generic fix.
Error fixSAP IDoc Status 51: Application Document Not Posted
Status 51 tells you the IDoc reached the application layer and failed to post, but the status text itself is not the error - the real cause sits in the status record's long text or the linked application log. Fix the underlying data or configuration, then reprocess the IDoc through BD87 rather than editing the status.
Error fixSAP Short Dump TIME_OUT: Maximum Runtime Exceeded
A TIME_OUT runtime error means a dialog (or RFC) work process ran longer than the maximum allowed runtime, controlled by profile parameter rdisp/max_wprun_time (600 seconds by default). The fix is almost always to move the long-running work to background processing or tune the underlying program, not to raise the timeout.
AI for ERPAI for SAP S/4HANA, Running On-Prem or in Your Private Cloud
Run AI on SAP S/4HANA without sending ERP data to a public API. On-prem and private-cloud architecture, CDS views, OData, and honest deployment trade-offs.
AI for ERPGet AI Value From SAP ECC Now, and Use It to De-Risk the Move to S/4HANA
SAP ECC 6.0 mainstream maintenance ends in 2027. Add AI value on ECC now, using its existing BAPIs and IDocs, and use it to de-risk the S/4HANA migration.
Stuck on SAP ERP (ECC 6.0 / S/4HANA)?
Talk to engineers who work inside SAP ERP (ECC 6.0 / S/4HANA) every week, and who build private AI that answers these questions from your own ERP data.