# Month End Close Checklist

> Use this skill whenever the user wants to plan, run, or audit a monthly close against their Mosofin workspace. Triggers include: 'run the month-end close', 'month-end checklist', 'what's left to close', 'close calendar', 'organize the close for [month]', 'close coordination', or any orchestration of the periodic close process. Workspace-scoped: it confirms the workspace, discovers which company files are connected and which read-only tools are enabled, then scopes the checklist from the entity's actual chart of accounts, pre-populates the status of every task that leaves ledger evidence, and runs the final tie-out including inter-period continuity. Do NOT use for an individual close task (a specific reconciliation, accrual, or JE) — use the corresponding specific skill. Outputs a comprehensive close checklist with owners, deadlines, dependencies, status tracking, a final tie-out workpaper, and a coverage sheet.

- Skill: `mosofin/month-end-close-checklist` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mosofin/month-end-close-checklist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mosofin/month-end-close-checklist/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: MosoFin (https://skillmd.com/u/mosofin)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mosofin/month-end-close-checklist

---


<!-- shared:onboarding-inline start -->
## Before you start — this skill works with or without Mosofin

**With Mosofin connected**, the skill reads your live accounting data through the
gateway: the figures come from your own books, it validates against the real chart of
accounts, and most steps run automatically.

**Without it, the skill still works.** No subscription, no connector, or a skill copied
on its own — you are not blocked and you are not asked to buy anything first. The
Mosofin gates are skipped and you are asked for what each step needs instead: a trial
balance, a statement, an export, the documents themselves. **The accounting logic, the
edge cases and the output standards are identical** — only where the numbers come from
changes, and the output always says which is which.

**You choose, and you are asked.** Where a connection exists, the skill asks at the
start whether to use it for this run or whether you would rather supply the data
yourself — **a connected gateway is not taken as consent to read your books.** Say no
and it runs manually without asking again.

### Strict rule — this skill never changes your data

**This skill will never write, update or delete existing data in any data source.**
Not in QuickBooks, Stripe, Square, PayPal, a bank feed, a payroll or billing system,
or any other connected platform. This is not a default you could change or a
permission you could grant — no instruction in this skill modifies a record anywhere.

It will **never**:

- create, edit, overwrite, void or delete a record in a connected platform
- invoke a write operation, or ask you to approve or enable one — a write tool is out
  of scope even when your policy has it enabled
- direct you to update, overwrite or delete existing data in a data source
- copy or move data from one connected platform into another

What it does instead is **read, and propose.** Every entry, schedule, reconciliation
and document it produces is a **draft for you to review.** Where it finds a problem —
a duplicate, a mismatch, a stale balance — it describes the problem and proposes a
correcting entry as a draft. It does not tell you to delete or overwrite the original,
and it never acts on one itself.

Whether anything reaches your books is a decision you make outside this skill, in your
own system, by your own hand. **If you act on none of it, nothing in your data has
changed.**

### Onboarding — required whenever Mosofin is connected

**If the Mosofin gateway is connected, onboarding is not optional and not per-skill.**
Before any skill reads anything, the workspace and the data sources in it must be
confirmed with you. It is the same sequence for every Mosofin skill, so it is kept in
one place rather than repeated in each:

- in this repo: [`shared/onboarding.md`](../../shared/onboarding.md)
- installed on its own, or you would rather read the product docs:
  [docs.mosofin.com/start-here/quickstart](https://docs.mosofin.com/start-here/quickstart)

**Already onboarded this workspace?** Then you have answered it once and will not be
asked again from scratch — but **the confirmation itself still happens every run.**
Gate 0 reads your workspace back and waits for an explicit yes; Gate 1 settles which
company file. Those are not skippable, and no data is read before them.

**No Mosofin connector? The skill still works.** If the gateway is not present at all,
there is nothing to onboard: the gates are skipped, every step becomes `[manual]`, and
you are asked for what each step needs — a trial balance, a statement, an export.
**The accounting work is unchanged**; only the data source is. You will be told this
once, and you will not be asked to install anything before being helped.

What follows in **Part A** is not more onboarding. It is this skill exploring what your
confirmed workspace and data sources can actually do — which tools exist, which serve
this particular request — so the run is shaped around your books rather than a generic
template.

---
<!-- shared:onboarding-inline end -->
# Month-End Close Checklist (Mosofin)

Plans, orchestrates, and audits the **monthly close process**. Produces a comprehensive **task list with
owners, deadlines, dependencies, status**, and a **final tie-out** demonstrating books are ready for
reporting.

**In plain words:** closing the month means making sure everything that happened has been recorded, every
balance has been checked against something outside the ledger, the estimates have been updated, and the
numbers can be handed to someone who will make decisions with them — by a date, with names against each
piece.

This skill is **industry-aware** — it adjusts the task list to the entity's industry, size, and
complexity.

It is **workspace-scoped**: the scoping evidence, the task status and the final tie-out come from tool calls
against a company file connected to your Mosofin workspace in this conversation, or from something you
supplied by hand and that is labelled as such.

## This is the orchestration hub — and three things the workspace changes

**Almost every task in this checklist hands off to another skill.** This one coordinates; the others do the
work. **Three things change when the coordinator can read the books.**

**1. The checklist scopes itself.** Step 2 asks you to customise: *"No inventory? Skip inventory steps. No
fixed assets to speak of? Streamline FA steps. Single entity, single currency? Skip consolidation and FX
revaluation."*

> **Every one of those questions is answerable from Gate 1 and the chart of accounts.** **[auto]**: no
> inventory account, no fixed asset account, one connected company file, one currency, no restricted-fund
> accounts. **A checklist that arrives already scoped to this entity is worth far more than a generic one**,
> and the scoping costs one read.

**2. Many tasks are self-verifying.** The tedious part of running a close is chasing status — *has
depreciation been posted? did the accrual go in? is the FX revaluation done?*

> **Every task that produces a journal entry leaves evidence.** **[auto]**: **pre-populate the status
> column** for depreciation, amortisation, prepaid release, accruals, FX revaluation, deferred revenue
> release and lease entries. **"Posted 2026-08-04, £14,208, JE-2608-011" is a status; "Complete" ticked by
> whoever remembered is not.**
>
> **Be precise about what this proves**: it shows **an entry exists**, not that it is **correct** or
> **complete**. The task owner still owns the task. **But knowing what has and has not been posted, at any
> moment during the close, is exactly the coordination this skill exists to provide.**

**3. The final tie-out is nearly all `[auto]`** — including **inter-period continuity**, which is the one
almost nobody checks by hand and the one that catches a reopened prior period.

**What the workspace cannot do:** **it cannot lock the books, post an entry, or mark a task complete.**
**Mosofin is read-only.** It observes evidence and reports it; **the close is run by people.**

---

# ONBOARDING — Confirm the workspace and its data sources

**Required for every skill, every run — whenever Mosofin is connected.** Gates 0 and 1
settle *which books this is about*: the workspace, and the data sources inside it.
**Part A then explores what those confirmed sources can actually do** and personalises
the run around them. Nothing is read before Gate 0 is answered.

**If the Mosofin tools are not present at all, skip this part.** There is nothing to
onboard: say so once, then run the skill manually on data the user supplies. See the
precondition check below.

Run Gates 0 → 1 → 2 → 3 in this order, before building the checklist. This ordering is the contract. Do not
skip a gate because a previous conversation covered it — connections, permissions, and company files
change between periods.

Call the Mosofin tools by the **bare names your own tool list exposes** — `list_workspaces`,
`get_agent_datasources`, `get_datasource_tools`, `invoke_datasource_api_tool`, `get_skills`,
`get_my_skill`, `create_skill`. Do not add a `mosofin_` prefix and do not hardcode a client-side
`mcp__…` namespace; that string is composed by whichever MCP client is running.

<!-- shared:scope-protocol start -->
### First — ask whether to use Mosofin for this run

Two things decide how this skill runs, and they are settled **before Gate 0**.

**1. Are the Mosofin tools present at all?** — `list_workspaces` and the rest of the
gateway. Check before doing anything else.

**2. If they are present, ask the user. Once, in these terms:**

> Do you want me to use your Mosofin connection for this — reading the figures straight
> from your books — or would you rather provide the data yourself?

**Wait for the answer.** A connected gateway is **not** consent to read from it, and
this skill does not open with a data read. Never assume, never auto-pick.

- **Use Mosofin** → onboarding is required. Run Gates 0-1 to confirm the workspace and
  its data sources, then Part A explores what those sources expose.
- **Provide the data myself** → **skip Gates 0-2 entirely** and run manually, exactly as
  though no connector were present. **Do not ask again during the run.** Raise it once
  more only if the user asks for something their supplied data cannot answer, and then
  as an offer, not a demand.

**If the tools are not present, do not ask** — there is nothing to choose. The skill was
copied on its own, the connector was never added, or there is no subscription.
**Do not make connecting a condition of helping.** Say once, plainly, that Mosofin is
not connected and this run will be manual, then **carry on with the skill's normal
workflow**: ask for what each step needs — a trial balance, a statement, an export, the
documents themselves — and do the accounting work on what the user provides.

**In manual mode**, whether chosen or unavoidable:

- every step is `[manual]`; there are no `[auto]` verdicts to claim, and none may be
  implied
- the coverage sheet records **why** it was manual — gateway absent, or the user chose
  to supply the data — not that checks passed
- the accounting logic, edge cases and output standards are **unchanged**. That is the
  part of this skill that never depended on a connection
- mention **once** that connecting Mosofin would automate the manual steps, with a link
  to [docs.mosofin.com](https://docs.mosofin.com). Do not raise it again, and never
  withhold work to press the point

#### What a manual run actually does, gate by gate

| Gate | In a manual run |
|---|---|
| **Gate 0** — workspace | **Skipped.** There is no workspace to confirm. |
| **Gate 1** — data sources | **Skipped as a discovery step.** Still ask *which entity or company this work is for*, by name, so every output can be labelled — but record it as **user-asserted**, not confirmed against a connection. |
| **Gate 2** — capability map | **Skipped.** The map is not empty, it is uniform: **every task is `[manual]`.** |
| **Gate 3** — profile, then interview | **Runs, and grows.** The profile half cannot run — there is no company-profile tool — so everything it would have derived silently becomes a **question**: base currency, fiscal calendar, country or region, time zone. Then the interview runs in full, and **every row of the Inputs table that would have been `[auto]` becomes something to ask for.** |

Then **Part B runs unchanged** on what the user supplied.

**Ask the user to upload the data, and name the formats.** A manual run does not mean
retyping anything. Say plainly what to upload, in what form, and what each item is for —
then read it from the files they provide.

| Ask for | Upload as |
|---|---|
| Ledger detail, trial balance, transaction listings | **CSV** or **XLSX** export, or a pasted table |
| Statements and third-party documents | **PDF** or **CSV**, or a clear photo / scan |
| Invoices, bills, receipts, remittances | **PDF** or **image** — a single file or a batch |
| Short facts — a date, a balance, a policy | typed straight into the chat |

**Ask for the whole set up front, as a checklist, not drip-fed.** A person collecting
exports would rather be given one list than be interrupted six times. Mark which items
are strictly **required** and which merely improve the result, so they can decide how
much to gather.

**Confirm what actually arrived before starting the work.** Name each file, say what was
read from it — period covered, row count, opening and closing balances — and list what
is still outstanding. If a file is unreadable, covers the wrong period, or does not
contain what its name suggests, **say so at once**. Never work around a bad input
silently, and never guess at a column you cannot identify — ask.

**If something cannot be supplied, say what the output will and will not be — before
doing the work.** Never estimate a figure that was meant to come from the books, never
fill a gap with a plausible number, and never present a partial result as complete. An
honest partial answer, clearly labelled, is the correct outcome.

**Everything the user provides is evidence like any other.** Reconcile it, check it,
and challenge it where it does not tie. Manual input is not more trustworthy than a
ledger read — it is less, because nothing validated it on the way in.

**Present but not authenticated is not the same as absent.** If the tools are there and
a call returns a `reconnect_url` or an auth error, surface it and let the user choose —
reconnect, or continue manually. Do not silently fall back.

### Confirming scope — workspace, then data sources, then tools

**Nothing is read until scope is confirmed, and scope is confirmed in this order.**
Each step depends on the answer to the one before it, so none of them may be skipped,
merged, or guessed at.

| # | Question to the user | How it is settled |
|---|---|---|
| 1 | **Which workspace?** | `list_workspaces` with **no arguments**. Read the workspace back **by name** and wait for an explicit yes. On `selection_required`, ask whether this is single- or multi-workspace, then which **by name**, then call again with `workspace_ids=[…]` and `mode="single"`/`"multi"`. |
| 2 | **Which data sources, in that workspace?** | `get_agent_datasources` with the confirmed `workspace_id`. `connected: true` is in scope; `connected: false` is **excluded and named as excluded**, with any `reconnect_url` surfaced. Then settle the entity scenario — single-entity: which company; multi-entity: which set — always by `display_name`. |
| 3 | **Which tools do those sources actually expose?** | `get_datasource_tools` per in-scope datasource, **and per company file when several are live — permissions are per company.** This is discovery, not a question: read what is there before promising anything. |

**Never auto-pick.** Not the workspace, not the company file, not the entity scenario.
**Silence is not a yes**, and an answer to one question is not an answer to the next.

**Names, never internal ids.** Name the workspace and refer to companies by
`display_name`. Never print an internal numeric tenant id, and never show a raw
`data_source_id` — pass the opaque handle, show the name.

**Only then does the work begin.** Once the workspace, the data sources and their tools
are confirmed, resolve every task against what was actually found: what is available
now decides which steps are `[auto]`, which are `[gated]` and which fall to `[manual]`.
Where the confirmed tools cannot answer the request, say so and ask — do not substitute
an assumption for a capability.

**The catalogue is authoritative.** Take exact `tool_name` values from the Gate 2
listing — names are not uniformly styled, some underscored, some hyphenated.
**Do not invent a tool name.** On `UNKNOWN_TOOL`, read the valid names from the error
and retry.
**Never call a tool whose `effective_policy` is `disabled`.**

**This map is built fresh every run** and held only for this run. It is written out in
the coverage sheet, never written back into this file.
<!-- shared:scope-protocol end -->

## Gate 0 — Confirm the workspace

Call `list_workspaces` with **no arguments**.

- **One workspace** → read the workspace **name** back and **wait for an explicit yes**.
- **Two or more** (`selection_required`) → ask **in chat** whether this is single- or
  multi-workspace, then which workspace(s) **by name**, then call again with `workspace_ids=[…]`
  and `mode="single"` / `mode="multi"`.

Never auto-pick. Never print an internal numeric tenant id — name the workspace, pass the opaque
`ws_…` handle.

## Gate 1 — Discover live datasources and settle the entity scenario

Call `get_agent_datasources` with the confirmed `workspace_id`.

- `connected: true` → **in scope**.
- `connected: false` → **excluded, and named as excluded**. Surface any `reconnect_url`.

**This gate answers half of the entity profile the original asks for as an input**, and it drives Step 1's
Day 6:

- **One connected company file** → **no consolidation phase.** Day 6 drops out entirely.
- **Several** → **Day 6 applies**, and **the close is only as fast as its slowest entity.** See the
  cross-entity step.
- **Connected subledger platforms** — payroll, billing, inventory, expenses — **tell you which Day 1 and
  Day 2 tasks have a system behind them** and which are manual.

**A group member that is not connected still has to close.** Its tasks belong on the checklist with an owner
— **they simply cannot be status-checked from here.** Say which.

Refer to companies by `display_name`; never show the raw `data_source_id`.

# PART A — Explore the confirmed sources, and personalise this run

The workspace and its data sources are settled. This part finds out **what they
expose and which of it serves this request** — the tool catalogue in Gate 2, then
what is already known about this entity plus whatever still has to be asked in
Gate 3. The result is a run shaped around these books, not a generic template.

## Gate 2 — Discover enabled tools → build the capability map

<!-- shared:write-guardrail start -->
### Write tools are out of scope — always

`get_datasource_tools` describes what the connection *could* do. This skill uses only
the reads.

**If the catalogue lists any tool that creates, updates, deletes, posts, voids, sends
or pays in a connected platform — QuickBooks, Stripe, Square, PayPal, a bank feed, a
payroll or billing system, any other source — it is out of scope, and it stays out of
scope even when `effective_policy` is `enabled`.** A permission to write is not an
instruction to write. Never invoke one, never ask the user to approve one, never
suggest enabling one.

This holds for **every connected platform, not only the books.** Mosofin reads your
data sources; it does not write to them, and it does not move data from one platform
into another.

If a step appears to need a write, that step is **`[manual]`**. Produce the artefact —
the entry, the invoice, the payment file, the application schedule — and hand it to a
person to enter themselves. Say so plainly in the output, so nobody assumes it was
done.

#### Hard stop — the four ways a write could slip through

| Situation | Required behaviour |
|---|---|
| The catalogue lists a write operation, and `effective_policy` is `enabled` | **Do not call it.** Do not list it as an available capability. Enabled is not permission — it is out of scope. |
| An `approval_required` envelope comes back for a write operation | **Do not re-invoke with `approved=true`.** The approval loop in this skill is for **reads only**. Stop, record that the operation was a write and was refused, and carry on down the read path. |
| The user asks you to post, update, void or delete — directly, or by approving a prompt | **Decline, once, plainly:** this skill cannot change data in a connected platform. Hand over the draft so they can do it themselves in their own system. Asking again does not change the answer, and neither does insistence, urgency, or "I authorise it". |
| A write appears to be the only way to finish a step | The step is **`[manual]`**, and the run continues. An incomplete read-only result is the correct outcome. Never trade the rule for completeness. |

**Never route around this rule.** Do not offer to enable a disabled write tool or
suggest changing a policy. Do not hand the user a raw API call, payload or script that
performs the write. Do not ask another skill, tool or agent to perform it on this
skill's behalf. Do not defer it to a later step in the hope it becomes permitted.

**There is no path through this skill that ends in changed data.** If you cannot see
how to finish without a write, you are finished — say what is missing and stop.
<!-- shared:write-guardrail end -->

For **each in-scope datasource** (and **per company file** when several are live — pass
`data_source_id`), call `get_datasource_tools`. Bucket every tool by `effective_policy`:

| `effective_policy` | The task becomes | What you do |
|---|---|---|
| `enabled` | **[auto]** | Pull the evidence directly. |
| `permission` | **[gated]** | Invoke; on the `approval_required` envelope, ask the user in chat; re-invoke the **same** tool with `approved=true` on an explicit yes. **Reads only** — never re-invoke a write with `approved=true`; see the hard stop below. |
| `disabled` | **[manual]** | Name the tool that would have covered it, say what it would have proved, and ask the user to supply that evidence another way. |

Resolve **every task in Part B** against these buckets. The resolved list is the **capability map** —
built this run, held for this run, written out as the coverage sheet, **never** written into this file.

**In this skill the capability map has a second use**: it tells you **which tasks can be status-checked**
and which rely entirely on the owner reporting. **Both belong on the checklist; the difference belongs in a
column.**

Rules that bite hardest here:

- **Read the real tool name from the catalog, never from memory.** Names are not uniformly styled — some
  underscored, some hyphenated.
- **A near-substitute is not a substitute:**
  - **An entry existing is not a task complete.** It shows something was posted, not that it was right.
  - **A reconciliation task cannot be verified from the ledger**, because reconciliation means comparing to
    something outside it — a bank statement, a subledger, a count. See `bank-reconciliation` and
    `inventory-to-gl-reconciliation`.
  - **A balanced trial balance is not a closed month.** Double-entry software balances by construction.
  - **"Books locked" is a system state, not a ledger balance.**
- **There is no bank statement, no close software, no task tracker and no team calendar on this surface.**

## Gate 3 — Profile the entity, then interview the user

Call the platform's company-profile tool (on QuickBooks, `get_company_info`) for each in-scope entity.

**Derive silently** what the profile answers: legal name, **base currency**, **fiscal calendar and
period ends**, country / region, **industry** — which drives Step 2's industry additions.

**Ask the user** what actually changes the work — the original Inputs table, **minus the parts the connected
books now answer**:

| What to confirm | Required? | Notes |
|---|---|---|
| **Period being closed** | **Required** | |
| **Close calendar / target close date** | **Required — [manual]** | **The day allocation in Step 1 flexes to it.** |
| ~~Entity profile~~ — industry, size, complexity | **Now largely [auto]** | **Multi-entity and multi-currency from Gates 1 and 3; industry from the profile.** Confirm rather than ask. |
| **Reporting framework** | **Required — [manual]** | |
| **Standard close template**, if existing | Recommended — **[manual]** | **Preferred over a generic list** where one exists. |
| **Team / owners** | Recommended — **[manual]** | **Not in the ledger, and the checklist is worth little without them.** |
| **Materiality threshold** | Recommended — **[manual]** | **Do not assume one**; see the startup edge case. |
| ~~Sub-processes in scope~~ | **Now [gated]** | **Scoped from the chart**; confirm the result. |
| **Prior month's close** | Recommended — **[gated]** | **Carry-forward items are `[manual]`; whether last month's entries posted is `[auto]`.** |
| **Whether this is a soft or hard close** | **Required — Mosofin addition** | Different rigour; see the edge cases. |
| **Confirm scope** | **Required** | Read back in-scope and excluded company files by `display_name`, and the period. |
| **Confirm any profile contradiction** | **Required if one appears** | e.g. a monthly close for an entity whose periods are quarterly. |
| **Confirm manual evidence** | **Required** | Owners, materiality and the calendar are `[manual]`. |

Ask as **one short batch** — **and present the scoped checklist with the questions**, so the user is
confirming a tailored list rather than answering abstract ones.

**On later runs**, read stored preferences first (Step 9), confirm in one line, and ask only what changed.
The task list, the owners, the dependencies, the materiality basis and the scoping decisions persist;
**every status and every tie-out is re-observed.**

---

# PART B — The domain work

Every step below is the original procedure, unchanged in count, order, or substance, with plain-language
wording, an `[auto]` / `[gated]` / `[manual]` verdict, and the typical evidence tool added.

**Never drop a task because no tool covers it.** Most close tasks are performed by people using other
skills; this one coordinates them.

Tool names in *italics* are typical. Resolve real names and policies from your Gate 2 catalog.

## Step 0 — Fetch the scoping and status evidence (grounding) — Mosofin addition

**Batch independent reads into one message** — the chart, the balances, the entries and the prior period do
not depend on each other. Never serialize them.

The server is **stateless**: pass `data_source_id` on **every** call, including retries.

Typical opening batch, per in-scope entity:

- *`search_accounts`* — **the full chart: the scoping instrument** — usually **[auto]**
- *`search_journal_entries`* **for the period** — **the status evidence for every entry-based task** —
  usually **[auto]**
- *`get_trial_balance`* at the period end **and at the prior period end** — **the tie-out and continuity
  check** — usually **[auto]**
- *`get_balance_sheet`* current and prior — usually **[auto]**
- *`get_profit_and_loss`* current and prior — **the reasonableness review** — usually **[auto]**
- *`get_general_ledger`* around the period boundary — **cutoff evidence** — usually **[auto]**
- *`search_classes`* / *`search_locations`* — segment structure — usually **[auto]**
- *`get_company_info`* — **industry, currency, period ends** — usually **[auto]**

Handle the envelopes:

- `approval_required` → ask the user in chat, then re-invoke the same tool with `approved=true`.
- `entity_required` → ask by `display_name`, then pass that `data_source_id`.
- `tool_policy_disabled` → convert that check to **[manual]** and record the gap — **the task stays on the
  checklist**, only its status verification is lost.
- `UNKNOWN_TOOL` → read the valid names from the error; do not guess.
- Dead connection → surface the `reconnect_url`.

Check the **`mock` flag**. `mock: true` is fixture data — **a close status board built on fixtures shows a
month closing that is not.**

## Step 1 — Build the close task list

**A comprehensive monthly close typically includes** — every task carries its Mosofin status-check verdict,
where **`[auto]` means the checklist can observe whether it was done**:

**Pre-Close (Day −5 to Day 0)** — **[manual]** throughout; these are communications and requests
- **Communicate close calendar and cut-off times to all functions**
- **Confirm subsystems are open through period-end**
- **Run final daily integrations** (subledger to GL feeds)
- **Bank statements requested / downloaded**
- **Vendor statements requested for material vendors**

**Day 1 — Subledger Cutoffs** — **[auto]** to check
- **AR cutoff**: final invoices posted; subsequent invoices held for next month — **[auto]**: invoices dated
  in the period but entered after it
- **AP cutoff**: final bill posting; subsequent bills held for next month — **[auto]**, same test
- **Inventory cutoff**: shipments and receipts dated through last business day — **[auto]**
- **Payroll cutoff**: confirm last payroll posted; accrue any partial-period — **[auto]** for the posting
- **Bank transactions imported through period-end** — **[auto]**: latest transaction date in the cash
  account

**Day 2 — Subledger Reconciliations and Initial Entries** — **[gated]**: **a reconciliation compares to
something outside the ledger, so completion cannot be confirmed from inside it**
- **AR aging run and review** (`ar-aging-and-collections`) — **[auto]** to produce, `[manual]` to review
- **AP aging run and review** (`ap-aging-and-payment-runs`) — same
- **Bank reconciliations** (`bank-reconciliation`) — **[manual]**: **no bank statement on this surface**
- **Credit card reconciliations** (`credit-card-reconciliation`) — **[manual]**, same reason
- **Merchant processor reconciliations** (`merchant-and-payment-processor-rec`) — **[gated]**
- **Cash application** (`cash-application`) — **[auto]** for unapplied balances
- **Inventory cycle count or roll-forward** (`inventory-to-gl-reconciliation`) — **[manual]** for the count
- **AP accrual cutoff entries** (`ap-accrual-cutoff`) — **[auto]** for the entry

**Day 3 — Adjusting Entries** — **[auto]** to check, **all of them**; this is where status pre-population
pays most
- **Prepaid amortization** (`prepaid-amortization-schedule`)
- **Depreciation** (`fixed-asset-register-and-depreciation`)
- **Amortization of intangibles** (`intangibles-and-amortization`)
- **Lease entries** (`lease-accounting-asc842-ifrs16`)
- **Stock-based compensation expense** (`equity-compensation-accounting`)
- **Accruals and deferrals** (`accruals-and-deferrals`)
- **Bad debt allowance true-up** (`bad-debt-and-write-offs`)
- **Inventory write-downs** (`inventory-to-gl-reconciliation`)
- **Revenue recognition entries** (`revenue-recognition-asc606`)
- **Deferred revenue release**
- **Loan amortization** (interest + principal)
- **FX revaluation** (`multicurrency-fx-revaluation`)

**Day 4 — Reconciliations** — **[gated]**
- **Balance sheet reconciliations** (`balance-sheet-reconciliations`) **for every BS account** — **[auto]**
  to list the accounts and their balances; **[manual]** to reconcile
- **Intercompany reconciliations** (`intercompany-reconciliation`) — **[auto]** where both sides are
  connected
- **Payroll clearing** (`payroll-clearing-reconciliation`) — **[auto]** for the clearing balance
- **Tax accounts reconciliation** — sales tax, VAT, withholding — **[gated]**
- **All other control accounts** — **[auto]** to enumerate

**Day 5 — Review and Variances** — **[auto]** for the analysis
- **Preliminary trial balance review** — **[auto]**
- **P&L variance to budget / forecast** (`budget-vs-actual-analysis`) — **[gated]**: actuals `[auto]`,
  budget where held
- **BS variance to prior month** — **[auto]**
- **Unusual fluctuations investigated** — **[auto]** to surface, **[manual]** to explain
- **KPI dashboards refreshed** (`kpi-dashboard-builder`) — **[auto]**

**Day 6 — Consolidation (if multi-entity)** — **[gated]**; **drops out entirely for a single entity**
- **Sub-entity closes complete**
- **Currency translation** — each sub's functional currency → group reporting currency
  (`foreign-currency-translation-asc830`)
- **Intercompany eliminations** (`consolidation-and-eliminations`)
- **Consolidation adjustments**
- **Group trial balance review**

**Day 7 — Reports and Sign-Off** — **[gated]**
- **Financial statements built** (`financial-statement-builder`)
- **Management reporting pack** (`management-reporting-pack`)
- **Management review** — **[manual]**
- **Final adjustments** — **[auto]** to observe
- **Books locked** — **[gated]**; a system state
- **Distribution** — **[manual]**

**Adjust the daily allocation based on the entity's close target** — some entities close in 3 days, others
in 10.

## Step 2 — Customize to the entity

**Remove or downplay tasks that don't apply** — **[auto]** to determine, and this is the scoping step:

| Original question | How the workspace answers it |
|---|---|
| **No inventory? Skip inventory steps** | **No inventory account, or a nil balance** |
| **No fixed assets to speak of? Streamline FA steps** | **Fixed asset and accumulated depreciation balances** |
| **Single entity, single currency? Skip consolidation and FX revaluation** | **Gate 1's file count; the profile's currency; any foreign-currency balances** |
| **Cash basis entity? Remove most accruals** | **The accounting method on the reads, and whether accrual accounts carry balances** |
| **Nonprofit? Add fund-accounting steps** (`nonprofit-fund-accounting`) | **Net asset accounts split by donor restriction; fund or program classes** |

**Report the scoping conclusions with their evidence** — *"no inventory account in the chart, so the four
inventory tasks are removed"* — **so a task removed in error is visible and recoverable.**

**Add industry-specific tasks** — **[gated]**: the industry is `[auto]` from the profile, **the task set is
`[manual]` judgment**:

- **SaaS**: **deferred revenue release, ARR/MRR calculation, customer churn analysis** — *note*:
  **ARR and churn need the billing system**; see `kpi-dashboard-builder`
- **Construction**: **percentage-of-completion calculations**
  (`construction-percentage-of-completion`), **retainage review, WIP roll-forward**
- **Real estate**: **rent roll, CAM reconciliation, depreciation**
- **Manufacturing**: **variance analysis (PPV, MUV, OHV), inventory roll**
- **E-commerce / retail**: **returns reserve, gift card liability, loyalty accrual**
- **Professional services**: **WIP unbilled, project profitability**
- **Healthcare**: **patient revenue, contractual adjustments, allowances** — see
  `healthcare-revenue-cycle-accounting`

**[auto]** corroboration: **the chart frequently confirms the industry pattern** — a gift card liability
account, a retainage account, a WIP account. **Where an industry task has an account behind it, the task is
clearly live.**

## Step 3 — Assign owners and deadlines

**For each task** — **[manual]**, and **the checklist is worth little without this**:

- **Owner** (person or role)
- **Due date / due time**
- **Dependencies** (other tasks that must complete first)
- **Estimated time**
- **Status** (Not Started / In Progress / Complete / Blocked)

**Build a dependency tree. Critical path tasks: any task whose delay would push the close.**

**Mosofin addition — a sixth column: Evidence.** For every task whose status is `[auto]`, **record what was
observed**: the entry, its date, its amount, its reference. **Status says what someone claims; Evidence says
what the books show.** Where the two disagree — a task marked Complete with no entry posted — **that is the
most useful line on the whole board.**

## Step 4 — Materiality and risk

**Apply materiality** — **[manual]** for the threshold:

- **Reconciliations below materiality threshold can be completed with less detail**
- **Above-materiality reconciliations get full scrutiny**
- **Year-end uses tighter materiality than monthly**
- **Auditor expectations affect what's documented**

**[auto]** application once a threshold exists: **list every balance sheet account above and below it**, so
the scrutiny split is a fact rather than a habit. **Accounts drift across the threshold between periods**,
and a list rebuilt from balances catches that.

**Flag risk areas** — each with its verdict:

- **New transactions or accounts in the period** — **[auto]**: **accounts used this period that were not
  used before**. A strong, cheap signal
- **Unusual fluctuations** — **[auto]**: period-over-period movement outside normal range
- **Estimates with high uncertainty** — allowances, accruals — **[auto]** to identify the accounts,
  **[manual]** to judge
- **Recently restated or audited areas** — **[manual]**
- **Items management has identified as risk areas** — **[manual]**

## Step 5 — Track open items and review notes

During close, track — **[gated]**:

- **Outstanding tasks** — **[gated]**: `[auto]` where status is observable
- **Variances under investigation** — **[auto]** to surface
- **Pending information from outside** — vendor statements, bank confirmations — **[manual]**, and
  **frequently the critical path**
- **Manager review comments** — **[manual]**
- **Audit-trail-worthy decisions** — **[manual]**

**The third item deserves attention**: **the tasks waiting on outside information are the ones the workspace
cannot see and cannot chase.** They are also, in most closes, what actually delays it. **Surface them
separately** so they are not buried among tasks that will complete themselves.

## Step 6 — Tie-out workpaper at close

**Final tie-out** — **[auto]** for most of it:

- **Trial balance balances (debits = credits)** — **[auto]**, **and note it is true by construction** from a
  double-entry platform. **It confirms the software works.** See `financial-statement-builder`
- **Each BS account reconciled** — **[gated]**: **[auto]** to list every account and its balance and flag
  any without a reconciliation recorded; **[manual]** for the reconciliations themselves
- **Income statement reasonable** — variance to expected within tolerance — **[auto]** to compute,
  **[manual]** for the tolerance
- **Inter-period continuity** — **this period's opening = last period's closing** — **[auto]**, ⭐ **and the
  most valuable item here.** **A break means a prior period was reopened and something changed after it was
  reported** — see `ipo-readiness-accounting` and `financial-statement-builder`, where the same check
  appears. **Almost nobody runs it manually, and it is one comparison**
- **All adjusting entries posted and approved** — **[auto]** for posted; **[manual]** for approved
- **Books are locked** — **[gated]**: a system state, not a balance
- **Reports distributed** — **[manual]**

**Run the continuity check across every balance sheet account**, not just in total. **A total that continues
while individual accounts do not means a prior-period reclassification** — which may be perfectly proper and
still needs to be known before this month's statements go out.

## Step 7 — Lessons learned and improvements

**Post-close review** — **[gated]**:

- **Where did the close slip?** — **[auto]** support: **the posting-date distribution shows when tasks
  actually completed**, which is more reliable than recollection. See `ipo-readiness-accounting`, where the
  same measurement anchors a readiness assessment
- **What manual workarounds were used?** — **[manual]**
- **What can be automated?** — **[gated]**: **recurring identical entries are readable** and are the
  automation candidates
- **What recurring issues keep appearing?** — **[gated]**: **the same account reconciling late, or the same
  entry posting after the target date, is measurable across periods**

**Update the close calendar and template for next month.**

**This step is usually skipped, and the workspace makes it nearly free.** **Measured slip beats remembered
slip**, and the measurement is a by-product of reads already taken.

## Step 8 — Output

Deliver an `.xlsx` close workpaper:

**Sheet 1: Close Calendar**

| Day | Task | Sub-Process | Owner | Due Date/Time | Dependencies | Status | Time Estimate |

**Add three Mosofin columns**: **Applies?** (with the scoping evidence), **Status Verifiable?**
(`[auto]` / `[manual]`), and **Evidence** (what the books show). Plus the header block: workspace name; the
entity by `display_name`; excluded company files; **soft or hard close**; whether any read returned `mock`
data.

**Sheet 2: Task Detail** — **for each major task:

…(truncated)