> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hitaji360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Requesting & Approving a Period Reopen

> Sometimes a period was closed too early and a correction must be posted into it.

Sometimes a period was closed too early and a correction must be posted into it. Hitaji gives you **two** ways to reopen a period, depending on how much control you need:

1. **Direct reopen** — a one-click button that returns a closed period straight to **OPEN**.
2. **Maker-checker reopen request** — a controlled workflow where one person *files a request* and a finance-admin *approves or rejects* it. This is the path for **locked** periods and for any environment where reopening should require sign-off.

You'll find the direct reopen at: `/accounting/periods` (navigation: **Finance → Periods & Close**).

> 📷 *Screenshot: A CLOSED period row showing the "Reopen period" button — to be added.*

***

## Option 1 — Direct reopen (one click)

On the **Periods & Close** page, a closed period shows a **Reopen period** button.

1. Open **Finance → Periods & Close** (`/accounting/periods`).
2. Find the closed period (rose **CLOSED** badge).
3. Click **Reopen period**.
4. The badge returns to **OPEN** and you'll see a *"Period reopened"* confirmation.

The period is now postable again. The reopen clears the "closed at / closed by" stamps and writes a `REOPENED` entry to the audit trail.

Use this when reopening is a routine correction and the person doing it is trusted to decide. For tighter governance, or for a **locked** period (which this button does not handle), use the request workflow below.

***

## Option 2 — Maker-checker reopen request

The maker-checker workflow separates **who asks** from **who approves**, so a reopen of a closed or locked period leaves a deliberate paper trail.

### Step 1 — File a reopen request (the "maker")

A user files a request against the closed or locked period, supplying a **reason**.

* The request is recorded as **PENDING**.
* You **cannot** file a request for a period that is already **OPEN** — it returns *"Period is already open; no reopen is required."*
* You **cannot** file a second request while one is already pending for the same period — it returns *"A reopen request is already pending for period '\<name>'."*
* Filing writes a `REOPEN_REQUESTED` audit event capturing the reason and the period's previous status.

### Step 2 — Approve or reject (the "checker")

A **finance-admin** reviews the pending request and either approves or rejects it, optionally adding a resolution **note**.

* **Approve** moves the period from **LOCKED → CLOSED** (not directly to OPEN). This is deliberate: a single approval relaxes a locked period only one step, to closed. To make it fully postable again you then perform an explicit close-reopen cycle, which forces a second, recorded action. The request is marked **APPROVED** with the approver and timestamp, and a `REOPEN_APPROVED` audit event is written.
* **Reject** leaves the period as it was and marks the request **REJECTED**, with a `REOPEN_REJECTED` audit event.

Each request stores who requested it, the reason, who resolved it, when, and the resolution note — a complete maker-checker record.

### Who can approve

Approving, rejecting, or even **listing** pending reopen requests requires a finance-admin / override role. The accepted roles are:

* `accounting:override-period-lock`
* `override-period-lock`
* `finance_admin` / `finance-admin`
* `admin`
* `superadmin`

A user without one of these roles is refused with *"Period reopen approval requires finance-admin privileges."* Filing a request (Step 1) does not require these roles; resolving it (Step 2) does — that's the separation of duties.

***

## Direct reopen vs. maker-checker — which to use

|                        | Direct reopen button          | Maker-checker request              |
| ---------------------- | ----------------------------- | ---------------------------------- |
| Where                  | Periods & Close page          | Reopen-request workflow            |
| Result                 | CLOSED → **OPEN** immediately | Approval moves LOCKED → **CLOSED** |
| Handles locked periods | No                            | Yes                                |
| Separation of duties   | No (one click)                | Yes (request, then approve)        |
| Approval role required | No (page access only)         | Yes (finance-admin)                |

> Note: the maker-checker request, approval, and rejection actions are exposed through the accounting API but are **not yet surfaced as buttons on the Periods & Close page** in the current build. Teams that need the controlled workflow drive it through the API / an admin surface; the page's **Reopen period** button performs the direct reopen. *(Flagged for the docs owner — confirm the intended end-user surface.)*

***

## After reopening

Once a period is open again:

* Post your correction(s) for that date range.
* **Re-close the period** when you're done, so it goes back to protecting the month. Re-closing writes a fresh `CLOSED` audit event.
* If the reopen affected a fiscal year you had already year-end-closed, review whether the year-end close needs to be revisited.

***

## Related

* [Accounting Periods](/accounting/user/periods-compliance/accounting-periods)
* [Closing a Period](/accounting/user/periods-compliance/period-close)
* [Year-End Close](/accounting/user/periods-compliance/year-end-close)
* [Accounting Audit Trail](/accounting/user/periods-compliance/audit-trail)