Invoice raised should have gone into Period 9, but it has gone into period 10, the ACC_AUDIT table shows period 10, as does the TBI table.
Summary
The period that a Sales Order invoice is stamped with is not taken purely from the invoice date. It is taken from (or forced up to) the current sales‑ledger period held in SYS_DATAINFO.SALES_PERIOD, and that value is read WITH (NOLOCK). The most consistent explanation for the invoice landing in period 10 while 579308 (7 minutes earlier) and 579310 (next morning) landed in period 9 is that SALES_PERIOD was transiently seen as 10 at 13:10; almost certainly because a Sales‑Ledger period‑end transaction was in flight (and later rolled back / reversed) at that moment, and the NOLOCK read picked up the uncommitted value.
How the SO invoice period is decided
When posting the sales journal, the period is derived through ASC_CHECK_PERIOD_S. For an S/SO origin it reads the current ledger period straight from SYS_DATAINFO using a dirty read:
Even if the period is defaulted from the transaction date (via AA_GET_DEFAULT_PERIOD_S, which compares the date against ENDDATE_Px in SYS_DATAINFO2), there is a crucial rule that bumps any date‑derived period up to the current ledger period if the ledger has already moved on:
So a 03/09/2026 invoice whose date resolves to period 9 will still be written into period 10 if SALES_PERIOD (the current sales‑ledger period) is 10 at the instant of posting. This exactly matches your symptom: a date‑based rule alone could never produce period 9 → 10 → 9 across three invoices with essentially the same date.
On the COBOL side the same pattern is used everywhere: the sales postings read SALES_PERIOD from SYS_DATAINFO WITH (NOLOCK) and, when PAR-ACC-USE-FIN-POSTING = 1, call CHECKPER with the transaction date.
The resulting ACSL-TRAN-PERIOD / ACSL-TRAN-YEAR is what gets written to ASC_ACC_AUDIT (ACAU_TRAN_PERIOD) and to the TBI record (TBI_SL_PERIOD), which is why both tables agree on period 10.
Why the Sales Ledger Period was momentarily 10
A Sales‑Ledger period‑end advances the current period by one, inside a transaction:
Two things make a transient "period 10" window plausible around 13:10:
Dirty read (NOLOCK).
ASC_CHECK_PERIOD_Sand the COBOL posting code all readSALES_PERIODWITH (NOLOCK). WhileAA_SL_PYEND_ShasSALES_PERIOD = SALES_PERIOD + 1uncommitted in itsbegin tran, a concurrent invoice post can read the uncommitted10. If that period‑end was then rolled back (or failed one of itsSL_BATCH_IN_USE/rowcount checks),SALES_PERIODreverts to9; leaving only the one invoice that posted during the window stamped with 10.A period‑end run then reversed. Equivalently, someone ran the SL period end (9→10), realised it was wrong, and reset the current period back to 9. Any invoice posted while it was 10 keeps period 10; invoices before and after get 9.
Both explanations produce precisely the observed sequence: 579308 (13:07) = 9, 579309 (13:10) = 10, 579310 (next morning) = 9.
The single‑invoice, transient nature (9 → 10 → 9) rules out a static calendar/date boundary problem and points firmly at the current‑ledger‑period value being read as 10 at 13:10 due to a concurrent, subsequently‑reversed period‑end combined with the NOLOCK reads.