Appearance
Closing Period Deep Dive
Page intent This page explains closing period as a platform chapter even where source anchors in this documentation set are currently lighter than for documents/reporting.
Trust level
- Verified anchors:
README.mdplatform capabilities, prior platform analysis, runtime/accounting/register dependency shape - Architecture synthesis: yes
- Template guidance: yes
Chapter navigation
What closing period must achieve
A serious business platform must make period closure an invariant boundary, not only a reporting label.
In NGB terms, closing period should protect:
- late mutation of closed business periods;
- accidental back-posting;
- inconsistent operational/accounting state across period boundaries;
- weak explainability around adjustments.
Recommended design stance
Closing period belongs conceptually between:
- runtime workflow/orchestration;
- accounting validation;
- register consistency rules;
- background remediation/finalization jobs.
It should not be treated as a purely UI toggle.
Typical platform expectations
A production-ready closing model usually needs:
- explicit close commands/documents/actions;
- invariants on post/repost/unpost against closed periods;
- defined policy for adjustment entries after close;
- reporting semantics that distinguish “effective as of” versus mutable operational work;
- background verification/finalization where needed.
Recommended review checklist
- What is the authoritative close boundary: day, month, fiscal year?
- Which operations are blocked after close?
- Which correction paths remain legal?
- How are post-close adjustments represented without erasing history?
- Which jobs verify that period state is final and consistent?