Accounting Periods
An accounting period is one slice of your fiscal calendar — usually a month. Every transaction you post belongs to a period, and that single fact underpins period-end reporting, comparatives, aging, bank reconciliation, and book closure. Periods are the time backbone of the entire ledger.
The record itself is small, but its behaviour reaches across the whole platform. This article covers the full picture: the model, how period numbers relate to your fiscal year, how periods get onto your documents, why posting needs one, and everywhere a period is consumed.
Access you'll need. Setting up and maintaining accounting periods requires the Accounting Admin v2 or Accounting Controller v2 permission set. The Accounts Payable v2, Accounts Receivable v2, and Read Only v2 sets can view the calendar but not change it.
The model: a status-less, territory-scoped calendar
A period carries only what it needs to:
| Field | What it holds |
|---|---|
| Start Date / End Date | The date range the period covers. Every date maps to exactly one period. |
| Period Number | 1–12 — the period’s position within its fiscal year (see below). |
| Territory | The top-level territory whose calendar this period belongs to. |
| Name | Derived automatically in YYYY-MM form from the start date — you don’t type it. |
Two design principles shape everything else:
| Principle | What it means |
|---|---|
| Periods have no status | A period is not “open” or “closed” in itself — it’s just a date range. Whether you can post into it is governed at the entity level (see Closing the Books), never by a flag on the period. |
| Periods are scoped to a territory | The fiscal calendar is defined per top-level territory. Entities in a sub-territory inherit their parent territory’s calendar — one calendar serves a whole territory branch. |
Period numbers follow your fiscal year, not the calendar
This trips people up, so it’s worth being precise: Period 1 is the first month of your fiscal year — not necessarily January. The period number is the position in the fiscal year, and the dates fall where they fall.
| Fiscal year | Period 1 | Period 10 | Period 12 |
|---|---|---|---|
| Calendar (Jan start) | January | October | December |
| April start | April | January (next year) | March (next year) |
When you generate periods you choose either a plain calendar year (Jan–Dec) or a custom fiscal year by setting its first month. REDA then lays out the twelve periods accordingly — including rolling the tail months into the next calendar year when your fiscal year doesn’t start in January.
How periods land on your documents
You almost never pick a period by hand. When you create a source document — a sales invoice, purchase invoice, cash receipt, disbursement, journal entry, or purchase order — REDA stamps the period from the document’s date:
Find the entity’s calendar
REDA resolves the document’s entity up to its top-level territory — the territory whose calendar applies.
Match the date to a period
It finds the period in that calendar whose start ≤ the document date ≤ end, and stamps it on the document.
Re-derive if the date changes
Change the document’s date and the period recalculates, so the two never drift apart.
You need a period to post
Posting is where periods become non-negotiable. When a document posts, REDA enforces three period rules — and understanding them resolves the most common “why can’t I post?” questions:
| Rule | What it means & how to fix it |
|---|---|
| A period is required | If no period exists for the document’s date, the period stays blank and the post is rejected. Fix: generate the periods for that fiscal year so the date has a home. |
| The date must fall within the period | A transaction’s date must be inside its period’s start–end range. If you override the period to one that doesn’t contain the date, the post is rejected. Fix: let the period default from the date, or pick the matching period. |
| The period must be open for that module | If the date falls on or before the entity’s closed-through date for that module (GL / AR / AP), the post is blocked. Fix: post into an open period, or have an administrator reopen — see Closing the Books. |
Periods in financial reporting
Periods give your statements their time boundaries. When you run a report for a period (or a date range), REDA uses the period dates to split every account’s figures three ways:
- Opening balance — everything posted before the window begins.
- Period activity — what was posted within the window (the period’s debits and credits).
- Closing balance — opening plus activity, as at the period end.
Other places periods are used
| Area | How the period is used |
|---|---|
| AR / AP aging snapshots | Point-in-time aging snapshots are taken as at a period end — receivables and payables are aged relative to that date, so you can report exactly how they stood at each close. |
| Bank reconciliation | A reconciliation is tied to an accounting period; the period’s end date is the cut-off used to compare the bank statement against the GL balance. |
| Fixed assets | Depreciation and other asset-ledger postings are period-stamped from their ledger date, so asset movements land in the correct period. |
| Book closure | Closing a period is the act of setting the entity’s closed-through date to that period’s end — see Closing the Books. |
Lifecycle & the rules that protect the calendar
Periods are normally created in bulk by the period generator; you can also maintain them on the Accounting Periods tab. Either way, REDA holds the calendar to these rules:
- Auto-named. The name is set to
YYYY-MMfrom the start date — consistent and not editable by hand. - Valid, non-overlapping ranges. Start must precede end; two periods in a territory can’t overlap; period numbers run 1–12 and are unique per territory per year. Every date therefore maps to exactly one period.
- Active, top-level territory. A period’s territory must be an active, top-level territory.
- Dates lock after closing. Once any entity in the territory has closed through a period’s end date, that period’s start/end dates are locked — you can’t move them under posted, closed history.
- Can’t be deleted once used. A period that has accounting transactions can’t be deleted — referential integrity protects your posted history.
Where to go next
- Generating Periods — create the periods before anyone posts.
- Closing the Books — declare a period final and locked.
- Ledger Management — the book each transaction belongs to.
- How Posting Works — how documents land in a period.
- Year-End Close — roll balances forward at fiscal year end.
Frequently asked questions
No period exists for the document’s date. This usually happens at the start of a new fiscal year before that year’s periods have been generated. Ask an administrator to generate the periods for the territory and year, then save again — the period will stamp automatically.
Because period numbers follow your fiscal year, not the calendar. If your fiscal year starts in April, Period 1 is April, Period 9 is December, and Periods 10–12 fall in January–March of the next calendar year. Set this when you generate periods.
Because closing is done per entity and per module (GL, AR, AP), not per period — and one entity can be closed through a date while another in the same territory isn’t. A single status on the shared period couldn’t capture that. Instead, each entity carries its own “closed-through” dates, and posting is checked against them. See Closing the Books.
Correct the document’s date — the period re-derives to the one containing that date. The period must always contain the transaction date, so changing the date is the right lever; the period follows.
No — per top-level territory. Every entity in that territory, including sub-territories, shares the same calendar, which keeps reporting consistent and consolidation clean.
Was this article helpful?