Recurring Entry Not Generating Expected Document
A recurring entry document is only a template. It never posts by itself. A document only appears when the recurring entry program is executed for the period and the resulting batch input session is processed without error. Missing documents almost always trace back to the program not being run, the date interval not covering the period, or the session stopping on an error.
This page covers why a recurring entry set up in FBD1 fails to produce the expected FI document in a given period. It walks through the sequence of checks across the recurring document itself, the recurring entry run, and the batch input session that actually creates the posting, and separates data fixes from configuration fixes.
Published 16 Sept 2026· 1,023 words
The business symptom
The complaint usually surfaces during month end review: the rent accrual, the insurance allocation, or the intercompany service charge that always posts on its own has not appeared on the account this period. Someone on the business side says the automatic posting did not run, or that the recurring document they set up months ago has stopped working. It is often noticed only because a balance looks lower than expected, not because anyone was watching the recurring entry directly. In some cases the business insists it worked last month and nothing was changed, which is usually not quite true - either the run was skipped, or someone touched the master data without realising it affects future periods.
The configuration behind it
- The recurring entry program was never executed for the period. Recurring documents in FBD1 are only templates; nothing posts until F.14 is run, and F.14 is not automatic unless someone has scheduled it as a background job. If the job was not scheduled, or the schedule failed silently, no session is even created.
- The date interval on the recurring document does not cover the current period. FBD1 stores a first run date, last run date, and interval. If the last run date has already passed, or the first run date is still in the future, F.14 will skip the document entirely without any error message.
- F.14 ran and created a batch input session, but the session was never processed in SM35. This is the single most common cause once F.14 execution is confirmed - the run log shows the document was selected, but the actual FI document was never posted because the session sits unprocessed.
- The session was processed but stopped on an error inside it - a closed posting period, a field status conflict, an inactive cost center, or a blocked account. The session log in SM35 shows exactly where it stopped, and any documents after that point in the session were never posted either.
- The recurring document has been flagged for deletion. Someone marked it for deletion in FBD2 intending to stop it going forward, and F.14 correctly excludes it, but nobody communicated that the recurring posting was being retired.
- The recurring document was selected by the wrong company code or document number range in the F.14 selection screen, so it was simply never picked up in that run even though it is technically active.
What to check
- FBD3: display the recurring document, confirm the first run date, last run date, interval, and whether a deletion indicator is set.
- F.14: check the run log for the period in question, in test or update mode, to confirm whether the document was selected at all and whether a session was created.
- SM35: locate the batch input session generated by the F.14 run, check its status - not started, incorrect, or processed - and open the session log if it errored.
- FB03: search for the resulting document number by reference or by the recurring document number to confirm whether it actually posted.
- OB52: check whether the posting period was open at the time the session should have run, if the session log points to a period-closed error.
How to prove it in the data
Pull the F.14 run log for the period and company code in question and check whether the recurring document number appears in the selected list. If it does not appear, the date interval or deletion flag is the cause. If it appears but no FI document number is attached, cross-check SM35 for the session status and error log - that pinpoints whether it is unprocessed or errored mid-run.
Resolution path
If F.14 was never run, execute it for the missing period and process the resulting session in SM35 - this is an operational action, not a configuration change, though it should be paired with setting up a proper background job if one does not exist. If the date interval is wrong, correct it in FBD2 - a master data fix on the recurring document itself. If the session errored on a closed period, open the period in OB52, then reprocess the session in SM35 rather than recreating it. If the session errored on a field status or account configuration problem, that fix goes through the relevant IMG configuration and needs a transport if it is meant to apply beyond one company code. If the deletion indicator is set and the posting is still needed, there is no way to reactivate a deleted recurring document cleanly - a new one has to be created in FBD1 with the same terms and a corrected interval.
The fix people try first (and why it fails)
The usual reflex is to post a manual one-off entry in FB50 or FB60 to cover the gap for the period and move on. This closes the immediate complaint but leaves the recurring document itself untouched. The date interval is still wrong, the deletion flag is still set, or the background job is still missing, so the same gap reappears next period. It also creates a manual posting that duplicates what the recurring entry will eventually post if the underlying issue is fixed without checking for the manual entry first, leading to a double posting later.
Whose problem this is
Ownership sits with the FI accountant who maintains the recurring entry, jointly with whoever owns the background job scheduling if the F.14 run is meant to be automatic. The handover note should state the recurring document number, the expected posting date, the last successful run date, and the SM35 session status at the time the issue was raised.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-functional-issues/recurring-entry-not-generating-the-expected-documentERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.