All posts
·9 min read

Claude for Controllers: Close, Controls, Audit Trail

Claudecontrollerfinancial controlsmonth-end closeaudit trailAI finance

Part of our series on Claude for finance teams. The surface map is in Claude Has Four Surfaces.

Every other playbook in this series is about doing work faster. This one is about something a controller cares about more: whether the control environment survives the automation. A controller who hears "AI agents post to the ledger" is right to reach for the audit checklist — so that's where we'll start, with the checklist.

The control framework, before the magic

Five properties hold for everything in this playbook, agent or human:

  1. Everything posts through one gateway. There is no side door. Agent-originated and human-originated entries flow through the same validated workflow: payload checked, entry must balance, period must be open, account must exist.
  2. Risk-based approval lanes. Routine entries flow (green); sensitive ones wait for one approver (yellow); deletions, large amounts, and the unusual wait for multi-level sign-off (red). The thresholds are your policy, written down, changeable.
  3. Per-row audit trail. Every event — including every agent action — is recorded with actor, timestamp, and payload. "Who touched this number and why" is a query, not an investigation.
  4. Document evidence attached. Bills carry their source PDFs; bank lines carry their statement origin; payments trace to their approval. The evidence chain assembles itself at posting time, not at audit time.
  5. Periods lock. A closed period is closed — for agents too. Post-close adjustments are visible as exactly what they are.

If any of those five were missing, the rest of this article would be irresponsible. They're not optional features; they're the product. (The longer argument is in The Thinking Behind Artifi.)

Scenario 1: The close you supervise instead of perform

A controller's close is mostly verification choreography: are the statements in, did everything reconcile, what's unposted, are the accruals booked, does the trial balance tie. Each of those is now a question with a live answer:

You: Close status for May, Tallinn entity. Claude: All four bank accounts imported and reconciled — 312 lines, 9 needed review, all resolved. Two bills are still in the yellow approval lane (waiting on Maria). The recurring accruals are posted; the trial balance ties at €84,690. Period is ready to lock once those approvals clear.

The agents did the volume during the month (reconciliation ran nightly; bills posted as they arrived), which changes what the close is: not a posting marathon, but a review-and-lock. The lock itself is an action with your signature. (Watch a real close.)

Scenario 2: Anomaly review that doesn't depend on luck

The entries a controller most needs to see are the ones nobody flags. Standing anomaly checks run as scheduled work: round-amount entries near thresholds, postings to rarely-used accounts, vendor name near-duplicates, margin shifts that don't match volume, weekend postings. Findings arrive as a queue with the underlying rows attached — Chat handles the follow-up ("show me every entry this user posted to 7400 in May").

Claude is genuinely good at this class of cross-sectional review because it reads the whole ledger at once. It is not a fraud examiner — treat the findings as a sharper net, not a verdict.

Scenario 3: Audit season as a query, not a quarter

The auditor's sample lands: forty transactions, full support. Where that used to mean a shoebox archaeology project, it's now: every sampled row → its journal entry → its workflow history (who approved, when, in which lane) → its source document. Exportable. The PBC list shrinks to the things that genuinely live outside the ledger.

Multi-entity controllers get the same property across the group: dimension-based consolidation with intercompany eliminations, every elimination entry as inspectable as any other.

Scenario 4: Policy as readable text

The controls themselves — approval thresholds, allocation methods, accrual conventions, the close checklist — live as readable configuration and Plugins, not vendor settings screens. When policy changes, the change is a text edit with version history. Your accounting manual and your system configuration stop being two documents that drift apart.

What's real today — and what isn't

Real, shipping now: the five-property control framework above; risk-based lanes on all 46 transaction types; per-row audit including agent actions; document evidence on bills and payments; period locks; multi-entity, multi-currency consolidation with eliminations; reconciliation evidence with match confidence recorded; anomaly checks as scheduled agents; dedicated PostgreSQL schema per organization (your auditor's IT questionnaire will like that answer, alongside Anthropic's SOC 2 Type II on the AI layer).

Not there yet — and we'd rather tell you: a packaged SOX/ICFR certification kit — the trail and the controls are there, but mapping them to your control matrix is still consultant work, not a button; auditor self-service portals don't exist (you export; they receive); statutory consolidation disclosures beyond Estonia's annual report are roadmap; and no "fully autonomous close" — the close runs itself but locks on your signature, which any controller knows is not a limitation but the entire point.

The honest pitch to a controller

You're not being asked to trust a model. You're being asked to trust a workflow gate, an approval matrix you wrote, and an audit trail you can read — with a model doing the typing inside those walls. Evaluate it the way you'd evaluate a new hire: give it the volume work, check everything for a month, and widen the lanes as it earns it. The lanes are yours.

Real runs in the walkthroughs; adoption paths — bridge beside your current ledger or Artifi as the ledger — here.

SUBSCRIBE · NEW POSTS · NO SPAM

Get the next post in your inbox.

Practitioner notes on AI-native finance. One email when something new ships. Unsubscribe any time.