Period balances are a rebuilt cache of the inventory ledger by item, branch, accounting book and fiscal period. Each row holds opening, inward, outward and closing quantity and value. A successful rebuild supplies the period columns used by the inventory valuation statement; it does not guarantee a tie when prerequisites are missing or a valuation scope failed.
The rollup grain
| Dimension / measure | Meaning |
|---|---|
| Item, branch, company | Whose stock, where. |
| Accounting book | The book whose costing policies value the period. |
| Fiscal period | The period of your financial calendar being summarized. |
| Opening / inward / outward / closing quantity | The period's quantity story: what it started with, what came in, what went out, what remained. |
| Opening / inward / outward / closing value | The same story in money, at the book's costing method. |
| Costing method | The method that produced the values, stamped on the row. |
How the ledger rolls up
Within a period, inward is the sum of the period's positive posted movements and outward the sum of the negative ones; closing is opening plus inward minus outward; and each period's opening is the prior period's closing, chaining back to the start of history. Because the ledger corrects by reversal rather than edit, a correction and its original cancel inside whichever period they were posted in — the rollup needs no special handling for corrections, which is one of the quiet benefits of the reversal model described in the inventory ledger.
Rebuilt on demand, not maintained per posting
The value side cannot be kept current by adding to a naive total: under FIFO or moving average, a period depends on cost history. Period balances are therefore a rebuilt cache. A rebuild replays the relevant ledger history and rewrites the summarized rows. When it succeeds under valid book and method configuration, it provides a reproducible comparison; configuration or strategy failures must be resolved rather than hidden behind an assumed tie.
The consequence to remember: period balances are as fresh as their last rebuild. The valuation statement's period views carry a Rebuild action that recomputes the cache and reloads; run it after heavy posting activity, backdated corrections, or a change of valuation policy, and before relying on a period comparison for a decision.
Where period balances are used
The period and year comparisons of the stock position and valuation statement read the cache — each fiscal period becomes a column, in quantity, value or both, optionally as an opening/change/closing movement view. Current stock and the item ledger do not go through the cache; they are live reads of stock and ledger, which is why a stale cache shows up as a mismatch between "current" and "this period so far" views — the rebuild resolves it.
Common questions
The period comparison doesn't match current stock — which is right?
Both, at their own timestamps. Current stock is live; a period column is as of the last rebuild. If the current period's column trails today's figure, postings have happened since the rebuild — run the Rebuild action on the statement and the column catches up. If a closed period's figures changed after a rebuild, look for backdated corrections posted into it.
Why is the value column not just quantity times a price?
Because the value is produced by the costing engine under the book's method, exactly as the valuation statement computes it. Under FIFO the closing value reflects which receipt layers survived; under moving average, the average cost as of period end. That is deliberate: a period balance that used a naive price multiplication would disagree with the valuation statement and be unusable for reconciliation.
Do I need to rebuild after every posting?
No. Rebuild when you are about to use a period comparison and freshness matters, or after events that change history — backdated documents, corrections into earlier periods, policy changes. Day-to-day posting does not need the cache to be current, because the operational screens read live stock and ledger data.