Closing the Books: Maker-Checker Built Into the Database
Context
Faolan Consulting runs its own finance operation across several entities, and we treat it as a live proving ground for FaolanIQ: before a workflow goes to a client, it runs on us first. Month-end close - finalising a period's journal entries, checking the trial balance, and locking the books - is a core control point in any finance function. We rebuilt ours as a two-agent control chain, proven end to end on our own books.
The problem
Month-end close done by hand has a familiar failure mode. One person proposes the entries, and the same person, or nobody, checks the balance and declares the period closed. There is no enforced separation between preparing the numbers and finalising them, so the close is only as reliable as whoever is at the keyboard that month. Worse, once a period is "done" in a spreadsheet, nothing actually stops someone posting into it afterwards, so the trial balance signed off on Monday can drift quietly by Friday. That is not a discipline problem, it is a systems problem: the control existed as a habit, not as a rule the software enforced.
The approach
We split the close into two agents with two different jobs, both routed under Tyr, the pillar head for internal management. Ledger, a financial-ledger agent, does the preparation: it posts journal entries into an open period, builds the trial balance, and assembles a close pack (trial balance, cost consolidation, journal summary) for the period. When the numbers are ready, Ledger proposes the close - it has no authority to finalise it. Fenrir, the inhouse finance agent, does the review: it reads the close pack, confirms the trial balance balances and that no anomalies remain open, and only Fenrir can lock the period.
This is maker-checker, and it is enforced at the data layer, not just written down as a process. A period moves through exactly three states: open, close-proposed, locked. A database trigger permits only the legal transitions - Ledger can move a period from open to close-proposed; only Fenrir can move it from close-proposed to locked, or reopen a locked period with a reason recorded. Skipping the proposal and jumping straight from open to locked is not possible for anyone, including a script running outside the normal flow. A second trigger rejects any journal entry posted into a locked period outright. The hand-off itself travels as a schema-validated brief through the fleet's standard dispatch channel, not a shared file someone might forget to check; there is no path that lets Ledger write directly into Fenrir's decision. Material journal entries above a set rand threshold gate to a named human approver before they can post, and anything touching tax submission stays with Fenrir behind that same human gate.
The outcome
The result is a close with two properties a spreadsheet does not give you for free: separation of duties the software enforces rather than assumes, and finality that means something - a locked period genuinely rejects new postings until a named agent deliberately reopens it, reason on record. Ledger produces a one-pass close proposal (trial balance, cost consolidation, journal summary) instead of a scramble of ad hoc reconciliations, and Fenrir's review is a read of one structured pack rather than a hunt through someone else's working files. The control chain was built, then exercised end to end against a synthetic period before it touched live entries, and it is backed by the fleet's automated regression suite (158 tests passing at the time of writing, 2026-07-03).
What this demonstrates
This is a small, unglamorous workflow, and that is the point. It shows FaolanIQ agents holding a real financial control - segregation of duties, period finality, a human approval gate on material amounts - as a property of the system rather than a policy people are trusted to follow, proven on our own books before we ask a client to trust it on theirs.