bus-period — accounting period open/close/reopen and locking (SDD)
bus-period — accounting period open/close/reopen and locking
Introduction and Overview
Bus Period opens and closes accounting periods, generates closing and opening balance entries, carries forward opening entries from a prior workspace into the current workspace, and locks periods to prevent changes after close. Periods can be created in advance in a future state; open, close, reopen, and lock are state transitions (future → open → closed → reopened → closed → locked).
Requirements
FR-PER-001 Period control datasets. The module MUST store period state (future, open, closed, reopened, locked) as schema-validated repository data. Acceptance criteria: period rows validate against schemas and are append-only; allowed state values are exactly future, open, closed, reopened, locked; every period record appended by add, open, close, reopen, or lock MUST include a non-empty retained_earnings_account.
FR-PER-004 Period state lifecycle. The module MUST support creating periods in a future state and transitioning them open → closed → reopened → closed → locked. Acceptance criteria: only periods in state open or reopened accept new postings; closed and locked periods reject writes; future periods exist in the dataset but do not accept postings until opened; transitions are future → open → closed, closed → reopened, reopened → closed, and closed → locked; every period record appended by add, open, close, reopen, or lock MUST include a non-empty retained_earnings_account.
FR-PER-002 Close and lock operations. The module MUST generate closing entries and enforce period locks. Acceptance criteria: close outputs are deterministic and locked periods reject writes.
FR-PER-003 Opening from prior workspace. The module MUST provide a CLI operation that generates the opening entry for a new fiscal year in the current workspace from the closing balances of a prior workspace (e.g. a separate workspace repository for the previous year). Acceptance criteria: the command reads the prior workspace, computes account balances as-of a specified date using the same logic as period close or journal balance, creates exactly one balanced journal transaction in the current workspace with deterministic provenance, and refuses to run when preconditions are not met (target period not open, opening entry already exists without --replace, account or period validation failures).
NFR-PER-001 Auditability. Period transitions MUST remain reviewable in repository history. Acceptance criteria: period control datasets preserve open and close boundaries without overwrites.
NFR-PER-002 Path exposure via Go library. The module MUST expose a Go library API that returns the workspace-relative path(s) to its owned data file(s) (period control dataset and schema). Other modules that need read-only access to period control raw file(s) MUST obtain the path(s) from this module’s library, not by hardcoding file names. The API MUST be designed so that future dynamic path configuration can be supported without breaking consumers. Acceptance criteria: the library provides path accessor(s) for the period dataset (and schema); consumers use these accessors for read-only access; no consumer hardcodes periods.csv outside this module.
FR-PER-005 Repair of retained_earnings_account. The module MUST provide a CLI command to set or fix retained_earnings_account for an existing period in an append-only manner (no overwriting of rows). Acceptance criteria: the command appends a new record for the same period_id carrying forward start_date, end_date, and state from the effective record but with retained_earnings_account populated or updated; the command refuses if the effective state is closed or locked (or only in states explicitly allowed by the contract); the command enables repair of workspaces created by older versions where the field was blank, without manual file editing.
FR-PER-006 Deterministic reopen workflow. The module MUST allow a closed period to be reopened with explicit audit metadata and then re-closed. Acceptance criteria: reopen appends a new history row with state reopened, records a reopened_at timestamp and audit fields (reopen_reason, reopen_approved_by, optional reopen_voucher_ids), clears closed_at and locked_at, and refuses to run when the period is locked or not closed; a configurable policy window (for example --max-open-days) MUST be enforced when provided; re-closing a reopened period appends a new closed row and records reclosed_at.
Planned: automatic result-to-equity transfer at year end (profit/loss to equity account as part of close or a dedicated step). Until implemented, users post the transfer via bus-journal.
System Architecture
Bus Period owns the period control datasets and uses journal data to generate closing entries. The opening subcommand reads journal and period data from a prior workspace and appends one opening transaction to the current workspace journal via existing journal APIs. The module integrates with validation, VAT, and reporting workflows that precede filing and exports.
Key Decisions
KD-PER-001 Period control is recorded as repository data. Period transitions are stored in datasets so close and lock boundaries remain reviewable.
KD-PER-002 Path exposure for read-only consumption. The module exposes path accessors in its Go library so that other modules can resolve the location of the period control dataset for read-only access. Write access and all period business logic (add, open, close, lock, opening entry) remain in this module.
KD-PER-003 Future periods. Periods can be created in advance in state future. Creation is a separate operation (add); open and close are state transitions only and require the period to already exist. This allows batch setup (e.g. all months for a year) and clear semantics: open means “this period is now active for posting,” close means “this period is finished.”
KD-PER-004 Append-only state model. The period control dataset is an append-only event log. The effective state of a period is the record with the greatest recorded_at for that period_id (latest wins). All CLI commands and validation MUST use this effective-record rule: list, precondition checks for open, close, lock, and opening, and any downstream reads MUST resolve the current state of a period by selecting the effective record only and MUST NOT scan “any row” or “first row” for that period. The dataset is always valid immediately after any successful command in the sense that the effective record for every period present in the dataset satisfies schema and business rules (including non-empty retained_earnings_account where required). The list subcommand MUST show only effective records by default; history (all records per period) MAY be exposed via an explicit flag (e.g. --history) if implemented.
Append-only and schema validity. Periods.csv history is append-only and MUST remain schema-valid after every successful command, including the common fast sequence bus period add … immediately followed by bus period open …. No successful command may produce a duplicate primary key or leave the dataset in a state where bus period validate fails.
Row identity and monotonic recorded_at. History rows are uniquely identified by the primary key of the period control dataset (see Data Design / Files). Every appended record for a given period_id MUST have a recorded_at strictly greater than the recorded_at of any existing row for that same period_id. The implementation MUST guarantee this: recorded_at is written in UTC using RFC3339Nano (or equivalent). If the generated time would collide with an existing history row key for that period_id, the implementation MUST deterministically bump the value forward (for example by 1ns) until it is strictly greater than the latest recorded_at for that period_id. Ties on recorded_at for the same period_id are invalid. If such ties exist (e.g. from hand edits or legacy data), validate MUST reject the dataset with a clear diagnostic, and list MUST refuse to produce an effective state for that period until the dataset is repaired using normal commands (not hand edits). Any duplicate primary key scenario produced by recorded_at collisions after a successful add and open is considered a bug; the implementation MUST prevent it by enforcing the monotonic recorded_at rule above.
Component Design and Interfaces
Interface IF-PER-001 (module CLI). The module exposes bus period with subcommands init, add, open, close, lock, reopen, set, list, validate, and opening and follows BusDK CLI conventions for deterministic output and diagnostics.
Interface IF-PER-002 (path accessors, Go library). The module exposes Go library functions that return the workspace-relative path(s) to its owned data file(s) (e.g. period control CSV and schema). Given a workspace root path, the library returns the path(s); resolution MUST allow future override from workspace or data package configuration. Other modules use these accessors for read-only access only; all writes and period logic remain in this module. The SDD requires path accessors only; it does not require the module to expose a separate API that returns effective period state (e.g. “is period open”). Consumers that need open/closed state obtain the path from this library and may read the dataset using the effective-record rule (KD-PER-004) until the module optionally provides a state API.
The init command creates the baseline period control dataset and schema when they are absent. The baseline consists of the schema and a period control file that may be empty or contain only a header row; it does not pre-create any period rows. If both periods.csv and periods.schema.json already exist and are consistent, init prints a warning to standard error and exits 0 without modifying anything. If only one of them exists or the data is inconsistent, init fails with a clear error to standard error, does not write any file, and exits non-zero (see bus-init FR-INIT-004).
Period state lifecycle. The period control dataset records exactly five states: future, open, closed, reopened, locked. Valid transitions are: future → open (via open); open → closed (via close); closed → reopened (via reopen); reopened → closed (via close); closed → locked (via lock). Only periods in state open or reopened accept new journal postings. Re-opening a locked period is not required by the workflow; the implementation MUST refuse it and MUST exit non-zero with a clear diagnostic.
Subcommand: add
The add command creates a period row in state future. The period MUST NOT already exist; if a row with the same period identifier exists, the command MUST exit non-zero with a clear diagnostic and MUST NOT modify the dataset.
Command signature. bus period add --period <period> [--start-date <YYYY-MM-DD>] [--end-date <YYYY-MM-DD>] [--retained-earnings-account <code>] [-C <dir>] [global flags].
Flags.
-
--period <period>: (Required.) Period identifier in one of the forms YYYY, YYYY-MM, or YYYYQn. Determines the period_id stored in the dataset. -
--start-date <YYYY-MM-DD>: (Optional.) First date of the period. When omitted, the implementation MUST derive it deterministically from the period identifier (e.g. 2024-01 → 2024-01-01; 2024Q1 → 2024-01-01). -
--end-date <YYYY-MM-DD>: (Optional.) Last date of the period. When omitted, the implementation MUST derive it deterministically from the period identifier (e.g. 2024-01 → 2024-01-31; 2024Q1 → 2024-03-31). -
--retained-earnings-account <code>: (Optional.) Account code used for closing/opening balance (e.g. retained earnings). When omitted, the command MUST set a deterministic default (default:3200). Rationale: many entities use a single retained-earnings or carry-forward account (often 3200 in common charts), so a fixed default keeps the common case simple and ensures the field is never blank after a successfuladd.
Contract. The command MUST append exactly one row to the period control dataset with state future, the given (or derived) period_id, start_date, end_date, and a non-empty retained_earnings_account (from the flag or the default); closed_at and locked_at MUST be empty. The command MUST NOT change state of any existing period. Idempotency: adding the same period twice is invalid; the command MUST fail when the period already exists. Acceptance criteria: add MUST exit non-zero and MUST NOT write any row if the default or provided account code does not exist in the current workspace chart of accounts; if the accounts model can determine account type, add MUST exit non-zero and MUST NOT write if the account exists but is not an equity account.
Subcommand: open
The open command transitions a period from state future to open. The period MUST already exist in the period control dataset; if it does not exist, the command MUST exit non-zero with a clear diagnostic (e.g. “period … not found”) and MUST NOT create a row. If the period exists and is in state future, the command MUST append a new record (per KD-PER-004) with state open and MUST include retained_earnings_account copied from the effective prior record. The open command MUST refuse (exit non-zero, no write) if the effective record for the period lacks a non-empty retained_earnings_account; the user MUST repair the period first via bus period set --period <period> --retained-earnings-account <code>. If the period exists and is already open, the command is idempotent (exit 0, no change). If the period exists and is closed or locked, the command MUST exit non-zero with a clear diagnostic and MUST NOT change state; closed periods are reopened only via reopen.
Period selection is always explicit and flag-based. The open, close, and lock commands accept --period <period> as a required parameter and do not use positional period arguments. A period identifier is a stable string in one of three forms: YYYY for a full-year period, YYYY-MM for a calendar month, or YYYYQn for a quarter (where n is 1 through 4). This mirrors period usage in other modules such as bus vat, bus loans, and bus payroll, which also use --period and YYYY-MM or YYYYQn formats rather than positional arguments.
Close and lock (state transitions). The close command transitions a period from open to closed, or re-closes a reopened period. The period MUST exist and be in state open or reopened; otherwise the command MUST exit non-zero with a clear diagnostic. Close generates closing entries and then appends a new record (per KD-PER-004) with state closed; the new record MUST carry forward retained_earnings_account from the effective prior record. When re-closing a reopened period, the new row MUST record reclosed_at. The command accepts optional --post-date <YYYY-MM-DD> (when omitted, the closing entry date defaults to the last date of the selected period). The lock command transitions a period from closed to locked. The period MUST exist and be in state closed; if it is open, reopened, or already locked, the command MUST exit non-zero with a clear diagnostic. Lock appends a new record with state locked and MUST carry forward retained_earnings_account from the effective prior record. Lock does not generate postings; it only updates state so that the period cannot be modified.
Subcommand: reopen
The reopen command transitions a period from closed to reopened with mandatory audit metadata. It is used for controlled correction windows after a period has been closed and before it is locked.
Command signature. bus period reopen --period <period> --reason <text> --approved-by <id> [--voucher-id <id>]... [--max-open-days <n>] [-C <dir>] [global flags].
Contract. The command MUST refuse if the period does not exist, is not closed, or is locked. The command MUST append a new record with state reopened, set reopened_at to the new record timestamp, clear closed_at and locked_at, and populate reopen_reason, reopen_approved_by, and reopen_voucher_ids (when provided). When --max-open-days is provided, the command MUST compare the prior closed_at to the current time and refuse if the window is exceeded. Reopen is idempotent if the effective state is already reopened.
Subcommand: validate
The validate command loads the workspace period, accounts, and journal data and verifies schema and business rules. It MUST enforce that the period control dataset has no duplicate primary key: no two rows may share the same (period_id, recorded_at). Duplicate recorded_at for the same period_id (ties) MUST be rejected with a clear diagnostic (e.g. that each history row must have strictly increasing recorded_at per period_id). After a successful bus period add … followed immediately by bus period open …, even when the two commands run within the same second, bus period validate and bus period list MUST succeed; any duplicate primary key scenario produced by recorded_at collisions in that case is considered a bug, and the implementation MUST prevent it by enforcing the monotonic recorded_at rule (KD-PER-004).
Subcommand: set
The set command repairs retained_earnings_account for an existing period in an append-only manner (FR-PER-005). It MUST NOT overwrite existing rows.
Command signature. bus period set --period <period> --retained-earnings-account <code> [-C <dir>] [global flags].
Contract. The command MUST append a new record for the same period_id, carrying forward start_date, end_date, and state from the effective record but with retained_earnings_account set to the provided <code>. The command MUST refuse (exit non-zero, no write) if the effective state of the period is closed or locked; repair is allowed only for periods in state future or open. The command MUST refuse if the period does not exist or if the provided account code does not exist in the current workspace chart of accounts (and, if the accounts model can determine it, if the account is not an equity account). This enables repair of workspaces created by older versions where the field was blank, without manual file editing.
Subcommand: opening
The opening subcommand generates the opening entry for a new fiscal year in the current workspace from the closing balances of a prior workspace. It is a required accounting workflow step for starting a new fiscal year correctly without manual file editing. Typical use: a prior-year workspace repository (e.g. 2023) has been closed and locked; the user has created a new workspace for the new year (e.g. 2024), initialized accounts and period control, opened the first period, and initialized the journal; bus period opening then produces a single balanced journal transaction that carries forward account balances from the prior workspace into the current workspace.
Command signature. bus period opening --from <path> --as-of <YYYY-MM-DD> --post-date <YYYY-MM-DD> --period <YYYY-MM> [optional flags]. All of --from, --as-of, --post-date, and --period are required. The effective working directory for the current workspace is the directory given by -C / --chdir or the current directory.
Flags.
-
--from <path>: Path to the prior workspace root. The command MUST resolve paths to that workspace’s period control, journal, and accounts datasets via the respective owning modules’ Go libraries (bus-period, bus-journal, bus-accounts), not by hardcoding file names. The path is resolved relative to the current process working directory (before any-C). The command does not perform network access; the prior workspace must be accessible on the local filesystem. -
--as-of <YYYY-MM-DD>: Closing date in the prior workspace. Account balances are computed as-of this date using the same internal logic as period close or journal balance in that workspace. -
--post-date <YYYY-MM-DD>: Posting date for the opening entry in the current workspace (typically the first day of the new fiscal year). -
--period <YYYY-MM>: Target period in the current workspace. The opening entry is associated with this period; the period must be open (see validation rules). -
--equity-account <code>: (Optional.) Account code for the balancing equity line (e.g. retained earnings). Default:3200. Rationale: many entities use a single retained-earnings or carry-forward account (often 3200 in common charts) so a fixed default reduces required flags in the common case. Users whose chart uses a different equity account for year rollover MUST override with--equity-account. -
--include-zero: (Optional.) Include accounts with zero balance in the opening entry. Default: false. By default only non-zero balances are included; when set, the command includes one line per account that exists in the prior workspace chart (or per account that has journal activity in the prior workspace, as defined by the implementation) so that the opening entry explicitly shows zero balances where desired. -
--description <text>: (Optional.) Override the default transaction description. When omitted, the description is deterministic: it MUST include provenance sufficient for audit, specifically the normalized path to the source workspace and the as-of date (e.g. “Opening balances from <normalized-path> as-of YYYY-MM-DD”). Normalization of the path (e.g. absolute or relative) is implementation-defined but MUST be stable for the same path so that repeated runs produce the same description. -
--replace: (Optional.) If an opening entry already exists for the target period that was created by this command (identified deterministically, e.g. by a fixed prefix or marker in the transaction description), remove only that entry (or those entries) and then create the new opening entry. The command MUST NOT remove arbitrary user postings; only entries that can be deterministically attributed to a previousbus period openingrun for the same target period may be removed. If no such entry exists,--replacehas no effect on removal and the command proceeds to create the opening entry. Default: false; when false, the command refuses to run if an opening entry for the target period already exists (as identified by the same deterministic rule). -
--allow-as-of-mismatch: (Optional.) Allow running when the prior workspace’s fiscal year end (from its workspace config, if available) does not match--as-of. When omitted, the command MUST refuse to run if the prior workspace has a defined fiscal year end and it does not equal--as-of, with a clear diagnostic. When set, the command proceeds so that operators can intentionally carry forward from a different cut-off date (e.g. mid-year migration). Default: false.
Deterministic behavior and validation. The command MUST read the prior workspace state and compute account balances as-of --as-of using the same internal logic as period close or journal balance (so that closing balances and opening-source balances are consistent). It MUST resolve paths to the prior workspace’s accounts, journal, and period datasets via the bus-accounts, bus-journal, and bus-period Go libraries (read-only path access). The command MUST require that the current workspace has a chart of accounts initialized (path and schema obtained via bus-accounts library). It MUST validate that every account code used in the opening entry exists in the current workspace chart of accounts; if any code is missing, it MUST exit non-zero with a clear diagnostic and MUST NOT write any journal data. The command MUST refuse to run if the target period is not open or is closed/locked. It MUST refuse to run if the prior workspace has a defined fiscal year end and that date does not match --as-of, unless --allow-as-of-mismatch is set. It MUST refuse to run if an opening entry for the target period already exists (identified as above) unless --replace is provided. The command MUST NOT directly edit files outside BusDK modules; it MUST use existing library APIs (e.g. bus-journal or shared journal layer) for journal append and validation so that all writes go through the same schema and balance checks.
Output data changes. The command creates exactly one balanced journal transaction in the current workspace, dated --post-date, with one line per (included) balance from the prior workspace plus a balancing line posted to the selected equity account. The transaction MUST include deterministic provenance in its description when --description is not set (normalized source workspace path and as-of date). The resulting journal MUST pass the same validation as any other journal transaction (balanced to zero, schema-valid, account codes present in the current chart). VAT reporting period and other workspace configuration (e.g. in bus-config) are not modified by this command.
Acceptance criteria and invariants. The generated opening entry MUST be balanced to zero. Output MUST be deterministic for the same inputs (same --from, --as-of, --post-date, --period, --equity-account, --include-zero, and prior/current workspace contents). Validation of the resulting journal (e.g. bus journal validate or equivalent) MUST pass. The command MUST NOT perform network or interactive operations.
Example workflow (year rollover). In the new workspace: run bus accounts init and populate the chart of accounts; run bus period init; run bus period add --period 2024-01 (or add multiple future periods, e.g. 2024-01 through 2024-12); run bus period open --period 2024-01; run bus journal init; then run bus period opening --from ../sendanor-books-2023 --as-of 2023-12-31 --post-date 2024-01-01 --period 2024-01 --equity-account 3200. VAT reporting period and other workspace configuration are handled by bus-config and are not modified by bus period opening. Opening your first period. The sequence bus period add --period <id> immediately followed by bus period open --period <id> is a common fast sequence. The implementation MUST guarantee that after both commands succeed, bus period validate and bus period list succeed even when the two commands run within the same second. Duplicate primary key or validate failure due to recorded_at collision in that scenario is a bug; the implementation MUST prevent it via the monotonic recorded_at rule (KD-PER-004).
Usage examples:
bus period add --period 2026-02
bus period open --period 2026-02
bus period close --period 2026-02
bus period close --period 2026Q1 --post-date 2026-03-31
bus period lock --period 2026Q1
bus period opening --from ../sendanor-books-2023 --as-of 2023-12-31 --post-date 2024-01-01 --period 2024-01 --equity-account 3200
Data Design
The module reads and writes the period control dataset at the workspace root as periods.csv, with a beside-the-table schema file periods.schema.json. Paths are root-level only: there is no subdirectory (for example, the data is not under periods/periods.csv). Period operations append records so period boundaries remain reviewable (append-only event log per KD-PER-004); the effective state of a period is the record with the greatest recorded_at for that period_id.
Files and primary key. The schema file periods.schema.json defines the table schema for periods.csv. The primary key MUST support append-only history and therefore MUST NOT be period_id alone. The primary key MUST be a composite that uniquely identifies each history row; it MUST include recorded_at (for example primaryKey: [ "period_id", "recorded_at" ]) or another explicit event-identity column if the schema uses that approach. Row identity is thus (period_id, recorded_at) (or equivalent). The effective-record rule is greatest recorded_at wins for each period_id. A deterministic tie rule applies: ties on the primary key (e.g. two rows with the same period_id and recorded_at) MUST NOT exist. If they do exist, validate MUST fail with a clear diagnostic and list MUST refuse to produce an effective state for that period until the dataset is repaired using normal CLI commands (not hand edits).
The field retained_earnings_account is required for all period records written by the CLI. It is needed for deterministic close/opening workflows and for downstream modules that depend on a known equity account for balance carry-forward. Successful commands (add, open, close, reopen, lock, set) MUST never leave this field blank in any appended row; the dataset is always valid immediately after any successful command in the sense that every effective record has a non-empty retained_earnings_account.
Reopen metadata fields are append-only audit data. reopened_at, reopen_reason, and reopen_approved_by are required when state is reopened. reopen_voucher_ids holds a deterministic, comma-separated list of affected voucher identifiers when provided. reclosed_at records the timestamp when a reopened period is closed again. For states other than reopened and re-closed periods, these fields remain empty.
Period rows enter the dataset when the user runs add --period <id>. The add command creates the row in state future with a non-empty retained_earnings_account (default or provided). The init command creates only the dataset file and schema (empty or header-only); it does not insert any period rows. The open, close, reopen, and lock commands append new records (effective-record semantics) and carry forward retained_earnings_account; set appends a record to repair the field for existing periods in future or open state.
Other modules that need read-only access to the period control dataset (e.g. to check open/closed state in another workspace) MUST obtain the path from this module’s Go library (IF-PER-002). All writes and period-domain logic remain in this module.
Assumptions and Dependencies
Bus Period depends on journal datasets and on the workspace layout and schema conventions. Missing datasets or schemas result in deterministic diagnostics.
Security Considerations
Period locks are a control boundary and must be enforced in the module to prevent edits to closed periods. Repository access controls protect underlying data.
Observability and Logging
Command results are written to standard output, and diagnostics are written to standard error with deterministic references to dataset paths and identifiers.
Error Handling and Resilience
Invalid usage exits with a non-zero status and a concise usage error. Close, lock, or opening violations exit non-zero without modifying datasets.
Testing Strategy
Unit tests cover period state transitions and close calculations, and command-level tests exercise open, close, reopen, lock, set, and opening against fixture workspaces.
End-to-end invariant (required). The test suite MUST prove the following. After bus period init, bus period add --period 2024-01, and bus period open --period 2024-01, the workspace MUST be in a state where bus period validate and bus period list succeed. Regression (add+open): a test MUST run bus period add --period <id> then immediately bus period open --period <id> (back-to-back, same second) and assert that periods.csv ends up with two rows with distinct recorded_at values and that bus period validate passes. Regression (duplicate key): a test MUST verify that when two rows share the same period_id and recorded_at, validate detects and reports an explicit error (e.g. duplicate primary key or invalid recorded_at tie). Regression: a scenario MUST cover legacy workspaces where the effective period record has a blank retained_earnings_account; repair MUST be achievable via bus period set --period <period> --retained-earnings-account <code> so that validate and list then succeed, with no manual file editing in the primary workflow.
Deployment and Operations
Not Applicable. The module ships as a BusDK CLI component and relies on the standard workspace layout.
Migration/Rollout
Not Applicable. Schema evolution is handled through the standard schema migration workflow for workspace datasets.
Risks
Not Applicable. Module-specific risks are not enumerated beyond the general need for deterministic period control.
Glossary and Terminology
Period control dataset: the repository dataset that records period boundaries, state, and locks. It is an append-only event log; the effective state of a period is given by the effective record.
Effective record: for a given period_id, the record with the greatest recorded_at (latest wins). All commands and validation resolve period state from the effective record only.
Effective state: the state (future, open, closed, reopened, locked) and all other fields of a period as given by its effective record.
Period state: one of future, open, closed, reopened, locked. Future periods exist in the dataset but do not accept postings until opened.
Future period: a period in state future, created by bus period add, not yet open for posting.
Reopened period: a previously closed period in state reopened for controlled corrections, with required audit metadata recorded on the reopen row.
Period lock: a state (locked) that prevents edits to closed period data.
Opening entry: a single balanced journal transaction that carries forward account balances from a prior workspace into the current workspace, produced by bus period opening.
Prior workspace: the workspace (e.g. a separate repository for the previous fiscal year) whose closing balances are used as the source for an opening entry in the current workspace.