Automating the month-end close, with a human sign-off

The month-end close is the ritual where a company turns a month of activity into numbers it can trust. Done well, it is quiet: the trial balance balances, every account is reconciled, the statements articulate, and a responsible person signs. Done the usual way, it is a scramble — a week of chasing documents, re-keying adjustments and reconciling banks against a deadline, ending in a close that someone signs more out of exhaustion than confidence.

Automating the close is a core job of an autonomous finance department. FINMOZG does not replace the close with a black box that declares "done." It turns the close into a measurable readiness signal, does the routine assembly with its agents, and stops for a human to sign off — with every step recorded.

Why the close takes so long

A slow close is rarely caused by one big problem. It is death by a hundred small open items, each of which blocks the next. The recurring culprits are predictable:

• Unclassified transactions. Bank lines and expenses that no one has coded yet sit in suspense, so the trial balance cannot be trusted until they are resolved.
• Missing documents. A payment without its supplier invoice is a posting you cannot fully support, and a VAT credit you cannot defend.
• Unreconciled banks. If the ledger and the bank statement disagree, every downstream number is suspect until they are matched.
• Last-minute adjustments. Accruals, prepayments and corrections discovered on the final day force a re-run of the statements and a re-check of everything they touch.

Each of these is invisible until it isn't. In a manual close they surface in sequence, late, which is why the close compresses into a frantic final stretch. The fix is not heroics — it is making the open items visible continuously and resolving them before the deadline arrives.

Books X percent ready: a readiness signal, not a feeling

The most useful thing FINMOZG does for the close is replace "how are we doing?" with a number you can trust. The period-close readiness signal — books X percent ready — is computed from eight deterministic checks, each of which passes or fails against the posted ledger. It is not an estimate or a vibe; it is a count of objective conditions met.

That deterministic foundation matters. Because the percentage comes from real checks rather than a language model's impression, you can defend it. When the signal says ninety percent ready with one check failing, you know exactly which condition is open and what closing it requires — not a guess about whether the close "feels" on track.

The eight checks

Readiness is the conjunction of eight conditions. Each is a concrete, testable state of the books:

• Trial balance balanced. Debits equal credits; the foundation everything else stands on.
• Transactions classified. No line is left in suspense; every entry has an account.
• Documents complete. Postings that require supporting documents have them attached.
• No high anomalies. The anomaly feed shows no unresolved high-severity items — duplicates, outliers, policy breaches.
• VAT prepared. The ПДВ return is drafted and validated against the ledger, covered in depth in VAT and КЕП automation.
• Payroll posted. The payroll run for the period is computed and posted, with its taxes recognised.
• Adjusting entries posted. Accruals, prepayments and corrections are in the ledger, not pending.
• Bank reconciled. The ledger agrees with the bank, the subject of bank reconciliation automation.

Each check is a click-through into the items behind it. A failing "documents complete" check does not just lower the percentage — it lists the exact postings missing a document, so resolving the close is a worklist, not a hunt.

Adjusting entries and the trial balance

Most of the genuine work in a close lives in adjusting entries — the accruals, prepayments and corrections that turn raw activity into a faithful picture of the period. In a manual close these are the most error-prone step, often kept in a spreadsheet overlay that drifts from the ledger.

FINMOZG treats them as real postings. The Controller Agent proposes each adjusting entry with a confidence score and an evidence link, and posts it after review so it lands in the actual ledger. The financial statements — trial balance, income statement, balance sheet — are then computed deterministically from those postings and articulate exactly: the statements tie to each other because they are built from the same posted entries, not assembled separately. Because the adjustments are postings and not overlays, every one is traceable, and the trial balance you sign is the trial balance the statements were built from.

Who signs off the close

The agents can take the books to ready, but they do not close the period. Closing is a hard human boundary in FINMOZG — it never auto-executes, no matter how high the readiness signal. A person reviews the "books X percent ready" figure, inspects any remaining failing checks and exceptions, and approves the close.

That approval is not a quiet flag flip. It is written to an immutable, hash-chained audit log: who closed the period, when, against which readiness state, and on what evidence. The close becomes a defensible act with a named owner and a permanent record — exactly what an auditor, a bank or a board needs to rely on the numbers. You can read how that evidence chain is built across the platform in the audit trail and financial integrity.

Automating the close in FINMOZG is not the AI quietly closing your books. It is a close that measures its own readiness from eight real checks, does the routine assembly, and hands a clean, evidenced state to a human who signs — with every step on the record.