Closed-period control scoped per organisation

Why This Matters

The control that blocks postings into a closed or locked accounting period is enforced at the database layer, so it cannot be bypassed by any application path. It was, however, scoped too widely: it asked whether a closed period covered the transaction date in any organisation, rather than in the organisation the transaction belonged to. The effect was contained in normal use, because customer requests run under per-organisation isolation that only ever sees their own periods. On the elevated administrative and background paths that intentionally see across organisations, the first organisation to close a financial year could have blocked others from posting into the same date range. No customer was ever exposed, and the defect was found and fixed before launch by a documentation audit settling query. A control whose correctness depends on who invoked it is not a control, so this is now correct by construction.

Fix

The period check is now organisation-scoped: it considers only the closed or locked periods belonging to the same organisation as the transaction being written. The function no longer relies on the caller’s isolation context to be correct, so it behaves identically on customer paths and on elevated administrative paths.

Proof anchor: enforced by the period-check database trigger, migration 104, verified by a cross-tenant isolation test covering the customer path, the owning-organisation path, and the elevated cross-organisation path.

Operational Impact

None breaking. Period gating behaves exactly as before for a single organisation: a transaction dated inside that organisation’s own closed or locked period is still rejected. The only change is that one organisation’s closed period no longer reaches across to another.

Files Changed

Database migration adding the organisation predicate to the period-check trigger function. No application code changed.