Batch MIRO postings: why MM-FI accounting gets blocked by the open period

This one has a very recognizable pattern: automated invoice verification (MIRO) runs flawlessly for weeks, and then, on the first few days of every month, it suddenly starts rejecting documents in bulk.

The symptom

The automatic invoice posting job returns an error like “Period not allowed” or “Posting period not open” (a message from class F5, typically F5 063 or similar, sometimes M8 021 depending on the flow). The odd part: if you post the same document by hand a little later, it works. The FI team swears the period is open.

The real cause

It’s not one cause — it’s two calendars that aren’t in sync.

• The posting period is controlled in OB52 (posting period variant, table T001B), where FI defines which periods are open for which account ranges/company codes.
• The document your automation job generates uses the execution date as its posting date (BLDAT/BUDAT), not necessarily the date the order/invoice actually originated.

When the MIRO job is scheduled to run, say, at 00:30, and FI closes the previous period early the next day (or even at midnight via an automated closing process), there’s a window where:

1. The document to be posted has a posting date your program computed as “today,” but “today” already belongs to the new period.
2. That new period may not yet be open for every account type (vendor accounts, for instance, often open later than others).
3. Or the reverse: the document carries a previous-period date (due to a queue delay — see the job queue overload problem) that’s already closed.

The result is the same error message whether you’re running too early or too late relative to FI’s closing calendar.

How to confirm it

" Check whether the period for the proposed posting date is actually
" open for the company code and account type before attempting MIRO
CALL FUNCTION 'FI_PERIOD_CHECK'
  EXPORTING
    i_bukrs = ls_invoice-bukrs
    i_budat = ls_invoice-budat
    i_koart = 'K'   " vendors
  EXCEPTIONS
    error_period = 1
    OTHERS       = 2.

IF sy-subrc <> 0.
  " don't force it: log the real reason and decide on an alternative date or a retry
ENDIF.

Checking this before calling BAPI_INCOMINGINVOICE_CREATE (the standard BAPI behind MIRO) avoids the generic error and gives you room to decide what to do, instead of finding out from the failure message.

The fix that actually works

1. Don’t assume “today” as the default posting date. Calculate it explicitly against the open-period calendar, with a clear rule for the edge case (e.g.: if today’s period isn’t open yet for the required account type, use the last open period instead of forcing the current one).
2. Verify the period with FI_PERIOD_CHECK (or equivalent) before posting, don’t let the error surface from the posting itself. A controlled rejection with your own message is far easier to monitor than an F5 063 buried in the job log.
3. Coordinate the job’s execution window with FI’s closing calendar, which usually already exists as a known process (period close, next period opening). There’s no reason to schedule the automation right at the edge of that window.

The lesson

When a process crosses MM and FI, the most annoying errors are never in either module’s logic alone: they’re at the boundary, in implicit assumptions about dates and calendars that each side takes for granted differently. Make that assumption (the open period) explicit instead of letting the error message discover it for you.