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

# Closing a period

> The Accountant's five-step checklist: what each step asks, what blocks a close, and what only warns.

# Closing a period

The Accountant Accounting Desk and its close reads are live.
Reading the checklist remains read-only; fiscal close/reopen and adjustment release are separate guarded decisions.

Closing a period asks one question: **can this period close, and what is in the way?**

The Accountant answers it with a five-step checklist.
It does not re-invent the oracle: the Close checksums already exist as tested code against the real GL and all seven sub-ledgers, and the integrity sweep already exists as the Auditor.
The checklist orchestrates them, and adds the checks that live between the agents rather than inside either.

Accountant Waves D/F made the Close inventory executable by phase and added the close-gated job path, including depreciation coverage.
Wave E added carry-forward, year-end roll and CIT control behavior plus three `KETCHUYEN-*` checks.
The current inventory is **104 Close checksums**: 78 continuous and 26 close-gated.

## The five steps

They run in the order a human closes a period in.

<Steps>
  <Step title="period · is the fiscal period defined, and still open?" icon="calendar">
    The ledger's open-period invariant is defined on the fiscal period rows, so **a close against a
    period that does not exist is not a close at all**.
    An undefined period is blocking.

    With no period scoped, the checklist reports over the whole book rather than failing.
  </Step>

  <Step title="integrity · the hash chain and the GL invariant sweep" icon="shield-check">
    This is [the Auditor's](/greatbook/guides/audit-your-books) work, run as a step.

    The dependency is deliberate and it runs in this direction: **the Accountant depends on the
    Auditor**.
    A book whose chain is broken cannot be certified closed on top of.
  </Step>

  <Step title="unposted · are all approved documents actually posted?" icon="inbox">
    Approved intake rows with no GL entry yet.

    Closing a period while approved documents sit unposted **books them into the wrong period**.
    They are not lost; they land in the next one, which is worse than losing them, because the
    numbers for both periods are then quietly wrong.
  </Step>

  <Step title="close_list · do the Close checksums tie out?" icon="scale">
    The v12 workbook's Close list, run as live queries over the GL and all seven sub-ledgers.

    Every **must-be-zero checksum** that is off is a blocking item.
    The **explainable balances** are reported, never forced to zero.
  </Step>

  <Step title="statutory · does the TT200 mapping cover the active accounts?" icon="file-text">
    Accounts with activity but no statutory mapping row: the TT200 return cannot be produced from them.

    **A warning, not a block on the books.**
    An unmapped account is a reporting problem, not a bookkeeping one, and refusing to close the
    period would not fix it.
  </Step>
</Steps>

## How a step can fail

Each step returns one of five outcomes, and the distinction between the last two is the one that matters.

| Outcome        | Meaning                                                   | Blocks the close? |
| -------------- | --------------------------------------------------------- | ----------------- |
| `done`         | the step ran and found nothing                            | no                |
| `warning`      | the step ran and found something worth knowing            | no                |
| `blocking`     | the step ran and found something that must be fixed first | **yes**           |
| `skipped`      | the step did not apply, for example no period was scoped  | no                |
| `inconclusive` | the step **could not run**: a read failed                 | **yes**           |

<Warning>
  **An inconclusive report is never `ready_to_close`.**

  Every step is wrapped so that a read failure degrades to `inconclusive` rather than throwing, and one
  bad step never kills the rest of the checklist.
  But an inconclusive step is not a passing step.

  The Accountant certifies nothing it did not verify.
  "I could not check that" and "that is fine" are different answers, and collapsing them is how a close
  gets signed off on a book nobody looked at.
</Warning>

## What the Accountant can and cannot do

**The checklist cannot post.**
It reads fiscal periods, integrity, unposted work, 104 Close checksums and statutory coverage.

**It cannot certify what it did not verify.**
See the inconclusive rule above.

**It can propose an adjustment, but it cannot approve its own proposal.**
The proposal routes through the Bookkeeper graph and pauses at the posting gate with nothing written.
The adjustment-keyed approve/reject path requires a named non-agent human and binds the decision to the stable adjustment source.
Only a resulting journal entry establishes that an approval posted; a rejection is stored as a durable decision.

The Accountant reads allocations, costing and adjustments from their canonical services.
Those tabs expose exact money, pagination, partial/error truth and journal/workpaper links; they are not a generic finance writer.

## Closing or reopening from a staged workspace

The merged staged-workspace adapter set includes fiscal close and reopen.
It binds the exact `YYYY-MM` period and a transition-version hash, re-reads status under the verified organization and refuses stale or invalid transitions.

Close still calls the canonical service, which reruns and stores the five-step checklist and refuses any blocking or inconclusive result before locking the period.
Reopen requires the `period.reopen` role, a named human and a written reason.
Both transitions append fiscal-period events, and the workspace returns the canonical reference and audit receipt.
This code is merged application behavior.
The public MCP ingress and release source are current at registry `1.14.1`, but no ChatGPT or Claude close/reopen exercise is claimed.

## Worked example: investigate a close blocker

1. Select the exact fiscal period in **Accounting → Close**.
2. Read all five steps; do not stop after the first blocker, because another step may be inconclusive.
3. If `unposted` blocks, follow the exact approved document or adjustment to its posting gate.
4. If `close_list` blocks, open the named checksum, then follow its Books family tie-out and native register.
5. If `integrity` blocks, open the stored Auditor run and exact finding evidence.
6. Re-run only after the underlying fact is corrected or the authorized decision is recorded.
7. Treat `inconclusive` as blocking and preserve the evidence time; it is never equivalent to `done`.

## Reading the result

The verdict is read back from the fiscal period's own status, not from what the answer claims.

That distinction is small and it matters: an agent that reports "the period is closed" is reporting its own belief.
An agent that reads the period row back is reporting the database's state.
Only the second one is evidence.

## Before you close

<CardGroup cols={2}>
  <Card title="Run the Auditor" icon="search" href="/greatbook/guides/audit-your-books">
    The integrity step runs it anyway, but running it first means you meet a broken chain before you
    have started closing rather than in the middle.
  </Card>

  <Card title="Clear Awaiting posting" icon="stamp" href="/greatbook/guides/posting-gate">
    Every approved document with no entry is a step-3 blocker. Post them, or reject them, before you
    start.
  </Card>
</CardGroup>

## Related

* [Asking the Auditor](/greatbook/guides/audit-your-books) - step 2, in detail
* [The Close checksums](/greatbook/capabilities/close-list) - step 4, in detail
* [Statutory reporting](/greatbook/capabilities/statutory-reporting) - step 5, in detail