Balance carry-forward

A successor period begins with balances inherited from its configured predecessor. The carry-forward rules preserve both the book value and, where relevant, the exact foreign-currency denomination quantity.

Same-profile carry-forward

When consecutive periods belong to the same profile and no explicit mappings exist, balances carry forward by identical account path:

source 311/001 → target 311/001

The predecessor’s closing balance becomes the successor’s opening balance. If the predecessor is still open, previews are provisional and reflect its current closed-journal activity. Once it closes, the frozen period snapshot becomes the final source.

Explicit account mappings

Use a mapping when an account changes between periods or when the predecessor belongs to another profile:

old_profile: 311/001 → new_profile: 311/customers

Both source and target accounts must exist. Their denomination currencies must match, and the source and target profile accounting currencies must match.

Mappings are one-to-one and cannot overlap parent/child paths already covered by another mapping. This prevents the same aggregate balance from being carried twice.

Once explicit mapping mode applies, every source balance that matters must be covered or deliberately closed out. The opening-balance view reports unmapped book balances and unmapped denomination quantities so period close cannot silently drop them.

Mappings can be added or removed only while the target period is mutable.

Accounting-transfer tables

ACCOUNTING_TRANSFER is a table-definition option for materializing one editable transfer row per directly transferable source account. It is different from ACCOUNTING: it does not make ordinary business rows post journal lines.

The definition expands into twelve fields:

Frozen source fact	Editable target counterpart
`source_period_id`	`target_period_id`
`source_account_segments`	`target_account_segments`
`source_book_balance`	`target_book_balance`
`source_book_currency`	`target_book_currency`
`source_denomination_quantity`	`target_denomination_quantity`
`source_denomination_currency`	`target_denomination_currency`

Source fields describe the closed predecessor and are read-only. Target fields initially copy the same account path, balance, currency, and denomination values.

The transfer table must be selected when the table is created, and a table can contain only one ACCOUNTING_TRANSFER definition.

Generating transfer rows

Generation requires:

a closed source period;
a mutable target period;
the target period to name the source as its predecessor;
the transfer table to belong to the target profile;
no existing active materialization for that source period in the table.

The server derives direct account balances from the source snapshot so parent aggregates are not duplicated alongside their children. It inserts one row for each transferable direct account or denomination balance.

Generation is a one-time materialization for that source period. Repeating it while active rows already exist is rejected rather than creating duplicates.

How transfer rows are applied

When the target period closes, carry-forward chooses one source of opening balances:

If one ACCOUNTING_TRANSFER table contains active rows for the target period, those rows define the opening balances.
Otherwise, explicit account mappings are used when mapping mode applies.
Otherwise, a same-profile predecessor carries balances by identical account path.

Materialized transfer rows therefore take precedence over ordinary mapping or same-path behavior. More than one transfer table with active rows for the same target period is ambiguous and rejects period close.

If a source period was materialized but its active rows point somewhere other than the expected target period, close also fails. The transfer cannot silently disappear from the carry chain.

Validation before period close

Generation is only the beginning. Period close revalidates the active transfer dataset against the frozen predecessor snapshot:

every automatically generated source account must still have exactly one row;
no unexpected or duplicate automatic source account may appear;
source period, account, book balance, currency, denomination quantity, and denomination currency must remain unchanged;
every target account must exist in the target profile;
target book currency must equal the target profile accounting currency;
denomination quantity and denomination currency must be supplied together;
a nonzero source denomination quantity must remain covered on the target side;
all target book balances must sum to zero using the debit-positive convention;
target denomination quantities must sum to zero independently for each currency.

These checks ensure the transfer can remap or split accounting meaning without creating or destroying value.

Adjustment rows

A manually added adjustment row may omit all automatic source fields and supply only a complete target side. This can express a balancing or classification adjustment.

It must not contain only some source fields. A row is either a complete, unchanged automatic source row or a source-free adjustment row; a partial source identity is treated as corrupted data.

Using Steel during transfer

Target fields may be changed by the user or computed by Steel. This supports rules such as account remapping, selective closing, balance transformation, or target classification.

Steel scripts run while transfer rows are generated. A script may target the editable target fields, but never a frozen source field. The source facts remain the audit basis for explaining how the target value was derived.

See Steel for the calculation model.

Carry-forward versus materialized transfer

Use direct opening-balance mappings when the goal is simply to tell the successor period which target account inherits each source balance.

Use an ACCOUNTING_TRANSFER table when users need a reviewable dataset with source facts and editable/computed target values before applying a more involved transfer workflow.