Skip to main content

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.

period · is the fiscal period defined, and still open?

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.

integrity · the hash chain and the GL invariant sweep

This is the Auditor’s 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.

unposted · are all approved documents actually posted?

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.

close_list · do the Close checksums tie out?

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.

statutory · does the TT200 mapping cover the active accounts?

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.

How a step can fail

Each step returns one of five outcomes, and the distinction between the last two is the one that matters.
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.

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

Run the Auditor

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.

Clear Awaiting posting

Every approved document with no entry is a step-3 blocker. Post them, or reject them, before you start.