Claude for Controllership: A CFO's Operating Manual

Most finance AI pilots do not fail on capability. They fail on governance.

The technology reaches the demo stage quickly, the controller likes what they see, and the project stops eighteen months later in an audit conversation nobody prepared for. What was missing was never intelligence. It was the evidence layer underneath it.

This is the operating manual I use on live controllership builds. One rule holds it together: deterministic rules produce every number, the model writes the story around them, and a named human signs.

Fluency is not accountability

A language model will give you a depreciation charge in the same confident tone whether or not the asset still exists. It is not lying. It was never asked to know.

That is a survivable weakness in marketing copy and a fatal one in a function where every number carries a signature. The finance objection to generative AI is usually framed as accuracy. It is really about accountability: when a figure in the statutory accounts is challenged eighteen months later, someone has to reproduce it — the same inputs, the same logic, the same answer. A probabilistic system cannot make that promise, and no amount of prompt engineering converts a plausible sentence into audit evidence.

The mistake most finance teams make is concluding that AI therefore has no place near the ledger. The correct conclusion is narrower and far more useful: the model should never be the thing that computes. Accept that, and most of the risk drains out of the problem — because the expensive part of controllership was never the arithmetic.

Ask any controller where the month actually goes. Not the calculation. It goes on chasing the requisitioner who never raised the GRN, writing up why the variance moved, explaining the same twelve reconciling items to three different audiences, drafting the write-off note, and answering the auditor's question about a sample selected in a period nobody remembers.

That is language work sitting on top of numbers. It is exactly what the model is good at, and exactly what your best people are over-qualified to spend a week on.

Rules compute, the model narrates, a human signs

The rule is deliberately blunt so it survives contact with vendors, internal enthusiasm and a bad quarter.

No number that lands in a statement, a return, a register or a board pack is produced by a model. If a figure appears in AI output, it was calculated upstream by a versioned rule and passed in as an input.

Read it as a control, not a philosophy. It gives you a test any pilot can be held against: point at the number and ask what produced it. If the answer is a line of Python or SQL you can open, re-run and diff, the pilot is inside the boundary. If the answer is "the model worked it out from the file", it is outside — however good the demo looked.

The second half matters as much as the first. A human signs. Not reviews casually — signs, by name, against a stored version, at a recorded time. AI-drafted content that goes out unsigned is the most common way a well-designed pilot becomes an audit finding.

Six steps, and the order is the control

Nearly every failed finance AI project started at step four. This is a real sequence: each step is unusable until the one before it is signed off, and a skipped step surfaces later as a control gap rather than a bug.

1. Finance truth. What is the business process — who does what, in what order, on what input? What does a controller actually review, as opposed to what is easy to build? What will the auditor ask for under CARO 2020, Ind AS, the Companies Act or GST? Name the exception types before naming any technology: missing, disposed, transferred, timing, duplicate, unmatched.

2. Deterministic rules. Written in Python or SQL, explicit and defensible. "Flag if not sighted in 180 calendar days" — never "the model decides". Every rule emits a row: an asset ID, a transaction ID, a line item. Counts are not evidence. Document each threshold and why it is that number, because that is the question you will be asked.

3. Evidence and audit trail. Every exception links back to its source row — file, transaction, timestamp. Every calculation traces to formula, input and period. Approvals, disposals and adjustments log who and when. Output exports cleanly for the audit file, because that is where this ends up whether you planned for it or not.

4. The AI layer. Only now. The model drafts exception narration, the CFO digest, the write-off memo, the variance commentary, the reply to the auditor's request list. Every claim cites a source row. Every artefact is stamped as a draft until signed. Nothing in this layer changes a number.

5. A workbench, not a dashboard. A dashboard tells a controller something is wrong. A workbench lets them finish it: queue, drilldown, evidence, action, owner, status, trail. Target three clicks from alert to decision without opening another system. If an agent did work, show the work in the interface — capability buried in code does not get trusted.

6. The label. State plainly what this is — concept, demo, MVP or production — on the screen and in the covering email. Mislabelling is the fastest way to lose a finance audience, and the damage is not to the pilot. It is to the next three things you propose.

The four labels, never blurred:

Concept — static screens, no real data.
Demo — working app, believable sample data, not client-deployable.
MVP — deterministic rules solid, basic auth, deployable.
Production — RBAC, audit logs, persistent database, CI/CD, monitoring.

Never let a demo pretend to be an MVP. Never let an MVP pretend to be production.

What the model does, and what it must never touch

Three things belong to rules alone, because they must be reproducible years later against archived inputs:

Computation — depreciation, accruals, tax, FX. To the paisa, every time.
Exception detection and thresholds. The threshold is the control. It has to be documented, versioned and defensible.
Matching on an exact key. Invoice number equals invoice number. Never a similarity score.

One thing belongs to people alone:

Approval, write-off and posting decisions. Accountability cannot be delegated to a system that cannot be held to account.

The rest is where the model earns its place:

Fuzzy matching — narration text, vendor-name variants. Proposed as candidates, confirmed by a person, logged either way.
Document extraction — contracts, POs, GRNs. Extract to structured fields with a confidence flag; the arithmetic happens downstream in rules.
Exception narration and the CFO digest — four hundred flagged rows into five themes with owners and amounts. This is the actual bottleneck in most closes.
Write-off memos, board commentary, audit replies — first draft in minutes, reviewed and signed by the controller. Drafting was never the control.
Policy framing — excellent at locating the paragraph and shaping the question. The position is taken by your technical team.
Writing the rules themselves — it writes the Python, you review the logic, the output stays deterministic and versioned.

Hold that last point against the first. The model is very good at writing the deterministic layer. It is being kept out of being the deterministic layer. That distinction is the entire design.

Is the process even ready?

Before asking whether a process is ready for AI, ask whether it is ready for a capable new joiner with limited supervision. Could they run it on day one from what is written down?

Inputs are named — which system, which extract, which period, in what format, from whom, by when.
Rules are explicit — the logic lives in a document or in code, not in the head of the person who has done it for six years.
Exceptions are typed — a finite list of things that go wrong, each with an owner.
Escalation is defined — above this value, or past this date, it goes to a named person.
Done is defined — a stated completion condition, not "when the controller is satisfied".

A process that fails this test will fail with AI too, and more expensively, because the model fills every undocumented gap with a confident guess. The honest response to a failed readiness test is not a pilot. It is two weeks of process documentation — work the model can draft from existing evidence and the team can correct.

The inverse is also true and often missed. A process that passes cleanly may not need AI at all. If inputs, rules and exceptions are that well defined, deterministic automation alone will do it — cheaper, and with fewer questions from the auditor.

Rules, model, or agent

Three different technologies get sold under one word, and they carry very different control burdens.

Deterministic rules — when inputs are structured, logic is stable and the answer must be identical every time. Control burden is low: code review and version control. This is ageing, depreciation, threshold breaches, exact-key matching.

A language model, single call — when the input or the output is language and a human reviews before it matters. Control burden is medium: prompt versioning, citation, sign-off. This is exception narration, variance commentary, memo and email drafts.

A controlled agentic workflow — multi-step, tool-using, with a defined stop condition and a human gate. Control burden is high: step logging, permissions, a kill switch, replay. This is pull the extract, run the rules, draft the digest, route to the owner, wait for approval.

Default to the lightest option that solves the problem. Agents earn their governance overhead only when the sequence itself is the work — when the value is in orchestrating five steps that today sit with five people and a chase list. Even then, keep the agent's authority narrow: it may gather, compute via rules, draft and route. It may not approve, post or send externally.

One practical marker. If you cannot describe the agent's stop condition in a single sentence, you are not ready to run it in a close.

The Indian control environment already applies

There is no separate rulebook for AI in Indian financial reporting. That is not a gap to exploit — it means existing obligations apply to AI-assisted processes exactly as they apply to everything else.

Section 143(3)(i), Companies Act 2013. The auditor reports on the adequacy and operating effectiveness of internal financial controls over financial reporting. An AI-assisted process is in scope like any other. The testable control is the rule plus the review and the sign-off — not the model.

Rule 11(g), Companies (Audit and Auditors) Rules 2014. For financial years beginning on or after 1 April 2023, books must be maintained in software with an audit trail and edit log that cannot be disabled, and the auditor reports on it. Any tool that writes to the books must preserve that trail. Drafting tools sit beside the ledger; they never bypass its posting controls.

CARO 2020, clause 3(i)(a) and 3(i)(b). Proper records with quantitative details and situation of property, plant and equipment; physical verification at reasonable intervals; material discrepancies dealt with in the books. A ghost-asset exception engine maps to this clause line by line — build the output so it can be handed over as the verification working paper.

Ind AS 16. Componentisation, useful-life and residual-value review, derecognition on disposal. Derecognition timing is a rule with dates. The model writes the note explaining it; it does not decide when the asset left.

DPDP Act 2023 with the DPDP Rules 2025, notified 14 November 2025 with phased obligations. This defines what may leave your boundary inside a prompt. Payroll, vendor contacts and customer data need masking or an approved tenancy — decided before the pilot, not during it.

The RBI's FREE-AI framework, released 13 August 2025, sets out seven guiding principles and twenty-six recommendations across six pillars. Binding direction if you are a bank, NBFC, payment system operator or fintech. If you are not, it remains the most usable AI governance template available in India. Borrow the structure.

The EU AI Act, for groups with European exposure. Prohibitions have applied since February 2025 and general-purpose AI obligations since August 2025; Article 50 transparency duties apply from 2 August 2026, while Annex III high-risk obligations were deferred to 2 December 2027 under the Digital Omnibus. Controllership drafting is rarely high-risk, but transparency duties can reach group reporting. Confirm the current position with counsel — this timeline has moved twice in eighteen months.

NIST AI RMF 1.0 and ISO/IEC 42001 are voluntary, and useful when the board asks which framework you follow and you would rather not answer with something you invented.

The survey work inside that report belongs in every governance discussion. Among regulated entities already using AI: 35% validated for bias and fairness, 21% monitored for data or model drift, 18% maintained audit logs, 15% used interpretability tools such as SHAP or LIME, and 14% carried out real-time performance monitoring. Roughly a third had any board-level oversight.

Read those five numbers in order and the shape of the problem is clear. Adoption is running ahead of observability. Around a fifth of surveyed entities were deploying AI and two thirds were exploring it, while fewer than one in five could produce a log of what their systems actually did.

The gap in Indian financial services is not appetite. It is the evidence layer underneath the appetite — precisely the layer a controller is trained to build, and the reason this belongs on the CFO's desk rather than only in the technology function.

Twelve controls you should be able to name

"We review the output" is not an answer when the audit committee asks how AI is controlled. This is the minimum set. Each has an owner and produces evidence someone outside the team can test.

Authority limits (CFO with IT) — every tool registered as read-only, draft-only or write. Write access to the books is approved separately, by name, and is never the default a pilot inherits.
Data boundary (CFO with CISO) — a classification of what may be sent, with masking rules and a log.
Approved environment only (IT) — contracted tenancy, data-processing agreement, retention settings, no consumer accounts.
Rule provenance (Controller) — every number carries the rule version that produced it.
Row-level citation (Process owner) — every AI claim references a source row; unsupported statements are flagged by the system.
Draft labelling (Process owner) — every AI artefact stamped as an unsigned draft until a person signs it.
Named sign-off (Controller) — reviewer, timestamp and the exact version reviewed, held in the system rather than in an inbox. The reviewer is someone other than the person who wrote the prompt.
Prompt and model change control (System owner with Controller) — prompts held in a repository with history, and any change to prompt or model that affects reported output goes through the same process as a code change.
Threshold register (Controller) — every threshold, its rationale, its owner, its last review date.
Reproducibility pack (Controller) — inputs, rule version, prompt version and final output archived together, so a prior period can be re-run after the model version is retired.
Completeness testing (Internal audit) — periodic re-run of rules against source, reconciling exception counts and values.
Incident path (CFO) — a defined route for when a wrong figure reaches a reader: contain, correct, log, report.

Twelve at once reads as a wish list, so start with three. Authority limits, because it decides how much the rest matters. Row-level citation, because it is what makes the output reviewable. Draft labelling with named sign-off, because together they cost a day to implement and close the most common failure.

This set is available as a working file — control register, threshold register, sign-off log, exception taxonomy, pilot scorecard and the gate below, set up for one exception queue at a time. It sits with the other free tools under resources.

Five questions the auditor will ask in year one, and the answers worth having ready:

"Which numbers did the model produce?" None — then show the rule code and the row-level output that fed the narrative.
"Who reviewed the AI-drafted content?" Name, timestamp, version, from the system.
"How do you know it was not fabricated?" Every claim cites a source row, and the system flags claims it cannot tie to one.
"What data went into the model?" A documented boundary, a masking rule, a retention setting.
"Can you reproduce last quarter?" Rules versioned, inputs archived, drafts stored with the pack.

Tag every claim before it reaches a reader

Models are fluent about the outside world too — competitor moves, funding rounds, listing status. A single inference that reads like a verified fact causes everything else in the document to be re-examined, usually in the room where you least want that.

Five tags, applied before anything leaves the building:

[F] Fact — verified, with a primary source and date inline: exchange filing, regulator, company announcement, final prospectus.
[P] Partner — internal knowledge, attributed to the person who said it.
[I] Inference — reasoned but unconfirmed, with the reasoning shown. Never phrased as fact.
[H] Hypothesis — to be tested, paired with the question that would settle it.
[S] Solution — our proposal, kept distinct from the client's stated need.

Take the statistic everyone quotes about fixed assets: that ten to thirty per cent of a typical register no longer physically exists. It is repeated widely, it is directionally consistent with what verification exercises turn up, and it traces back almost entirely to vendors selling asset verification services. That makes it [I], not [F] — usable as framing, never as the basis for a business case.

What replaces it is stronger anyway: the client's own number. How many assets on your register were physically confirmed at their recorded location in the last verification cycle? What percentage of gross block does the unconfirmed balance represent? How many disposals were recorded in the books more than ninety days after the asset physically left? Three questions, no borrowed statistics, and the answer is the business case.

Two house rules follow. Listing, M&A and leadership claims are facts only from the exchange, the regulator, the company's own announcement or a final prospectus — aggregator pages carry stale placeholder windows and are not confirmation. And where two sources conflict, mark it unverified and move it to the question list rather than quietly picking one.

Brief it the way you brief a new manager

Output quality tracks almost entirely with how much process context went in. A finance brief that works has seven parts, and the first six are things you already know but rarely write down: the standard and period; the rule provenance — which rules ran, what they flag, at what threshold; the data with keys, row-level rather than summarised; the materiality, in rupees; the audience, because the audit committee, the statutory auditor and the plant controller are three different documents from the same facts; the citation requirement; and the label.

A weak brief looks like this:

Analyse this fixed asset register and tell me what's wrong.

No standard, no threshold, no period, no audience, no citation rule. You get fluent prose and no defensible position, and every figure in it needs re-deriving before use.

A working brief looks like this:

FAR extract attached. FY25-26, Ind AS 16, SLM. Rules already run at v2.3: not sighted over 180 days, disposed but still depreciating, duplicate tag, NBV below zero. Exceptions are in exceptions.csv, keyed on asset_id. Materiality: mention themes above ₹5 lakh. Draft a one-page note for the Audit Committee — five themes maximum, ₹ in lakhs, each theme citing asset_ids and the rule that flagged it. State explicitly anything you cannot tie to a row. Head it DRAFT, AI-generated, unsigned.

Rules ran first. The model is writing, citing and labelling — not calculating. The output is reviewable in the time it takes to read it.

Three briefs worth keeping in the repository rather than in someone's head:

The close digest. Given the task tracker extract and the ageing of open items, write the 07:30 standup note: what closed yesterday, what is blocked and on whom, what is at risk for the cut-off. Name owners. Do not estimate percentage completion.
Reconciliation commentary. Given the break file keyed on transaction ID, group breaks into causes, quantify each in ₹ lakhs from the file, and draft the commentary for the balance sheet review pack. Flag any break older than sixty days separately.
The auditor request reply. Given the PBC list and our evidence index, draft a reply per item stating what is attached, what is pending and the expected date. Where evidence is not available, say so plainly — do not describe compensating comfort.

One more discipline, easy to skip and expensive to skip: when scoping a build, require the model to ask one clarifying question and wait. Batched questions produce batched assumptions, and assumptions are where finance logic quietly goes wrong.

Where it pays first

Every one of these has the same shape — a deterministic engine underneath, a drafting layer on top, a person signing.

Fixed asset and ghost asset review. Rules compute not-sighted ageing, location certainty, disposed-but-depreciating, duplicate tags. The model drafts the write-off memo and the CARO-facing verification note.
Month-end close tracking. Rules compute task status, dependency breaks, ageing blockers. The model drafts the daily standup note and the escalation mail with owners.
Reconciliations. Rules compute GL versus subledger, bank and intercompany breaks. The model drafts break commentary grouped by cause.
Variance analysis. Rules decompose actual against budget and prior by driver. The model drafts the movement explanation with owners and next actions.
Accrual completeness. Rules compute open PO versus GRN versus invoice gaps by age and value. The model drafts the chaser to the requisitioner — not another mail to finance.
Audit request management. Rules handle sample selection, evidence status, ageing of open items. The model drafts per-item replies and the PBC status summary for the partner call.
Tax control tower. Rules compute TDS sections, GST buckets, advance tax positions and mismatches. The model drafts mismatch explanations and first-draft notice replies.
Order to cash. Rules compute AR ageing, dunning triggers, credit limit breaches. The model drafts collection notes segmented by customer tier.
Board and MD&A pack. Every figure comes from the reporting engine. The model drafts narrative, KPI commentary and the risk section.
CapEx and CWIP. Rules compute CWIP ageing, capitalisation triggers, depreciation start dates. The model drafts the CWIP review note for the plant controller.

Start where the exception list already exists and nobody has time to write it up. That is where month one of value sits, and where the audit trail is easiest to prove.

Seven ways this goes wrong

The silent number. A figure appears in the memo that no rule produced, because it was easier to let the model total the column. Control: rule provenance on every figure, spot-checked against the engine.
The plausible reconciliation. Breaks grouped into causes that read beautifully and do not match the underlying rows. Control: row-level citation, with three themes sampled back to source every cycle.
Threshold drift. "Not sighted in 180 days" quietly becomes 240 because the queue was too long in March. Control: a threshold register with owner, rationale and review date.
The prompt in someone's head. Digest quality collapses when one person is on leave. Control: prompts in version control, reviewed like code.
The unsigned draft that travelled. An AI-drafted note reaches the audit committee without review because it looked finished. Control: a mandatory draft stamp until named sign-off is recorded.
A demo dressed as an MVP. A pilot built on sample data gets scheduled into a live close. Control: the label on the screen and in the email, and an explicit MVP gate before any live period.
Boundary breach. Payroll or customer data pasted into an unapproved surface to "just check something". Control: approved environments, masking rules, and a sanctioned route that is faster than the shortcut.

Six of the seven are process failures, not model failures. That is the honest summary of the risk profile. The technology rarely breaks a finance AI deployment. The absence of a control around it does.

Metrics that prove it worked

Adoption counts and self-reported hours saved will not survive a budget conversation. Six measures will, and each is computable from data the system already produces.

Working days to close — period-end date to sign-off date, by entity. The number the board already tracks.
Exceptions cleared before cut-off — resolved before cut-off over total raised. Measures control rather than speed, because a fast close with open items is not a finished close.
Evidence completeness — exceptions with a linked source row over total exceptions. This is the ratio the auditor is implicitly testing.
Draft rework rate — material edits to AI drafts over drafts produced. Falling rework shows the briefing layer maturing; rising rework is an early warning.
Audit queries self-served — queries answered from the workbench over total queries. Converts the pilot into a visible reduction in audit-season load.
Reviewer minutes per pack — recorded review time over packs signed. The honest version of "hours saved", measured rather than estimated.

Take a baseline for all six in the close before the pilot starts. Without it you will spend the review arguing about whether anything changed.

The first ninety days

Day 30 — one exception queue, made real. One process, one entity, one period. Write the rules. Produce a row-level exception list a controller agrees with, line by line. No AI this month. If the list is wrong, nothing downstream matters. If the list is right, you have already delivered something useful.

Day 60 — the drafting layer and the workbench. The model narrates exceptions and drafts the memos. Build the queue view: exception, evidence, action, owner, trail. Label it a demo and run it in parallel with the existing process for one full close, recording the six metrics on both tracks.

Day 90 — harden, measure, extend. Auth, logging, persistence, export, retention. Walk the twelve controls with internal audit before anyone asks. Present the scorecard against baseline. Only then take the same pattern to a second process — the pattern travels far better than the pilot does.

Ownership needs to be explicit from day one. The controller owns the rules, the thresholds and the sign-off, and is the single accountable name on the output. The process owner owns the prompts, the exception taxonomy and draft quality. IT and the CISO own the environment, the data boundary and change control. Internal audit owns completeness testing and reviews the control set before the statutory auditor does. The CFO owns the boundary decision, the incident path and the labels — especially the labels.

Resist the platform pitch in month one. One wedge proved end to end buys more organisational permission than a roadmap covering the whole function, and it buys it from the people whose cooperation the second wedge will need.

The sign-off gate

Six questions before anything is called done. A single no sends it back, because code passing is not the same as finance logic being correct.

Finance story — is the process real and the exception logic credible to a working controller?
Data — is the sample controller-grade, with realistic distributions, seeded exceptions and honest edge cases, rather than toy data that passes every test and teaches nothing?
Rules — is every calculation deterministic, documented, versioned and reproducible?
AI — is the model only narrating: computing nothing, deciding nothing, sending nothing?
Workbench — can a controller get from exception to evidence to action in three clicks?
Label — is the concept, demo, MVP or production label accurate on the screen and in the covering note?

Sources and claim status

Applying the tagging discipline to this article. Verified as at August 2026; regulatory timelines move, so confirm before relying on any of this in a filing.

[F] CARO 2020, clause 3(i) — records with quantitative details and situation of PPE, physical verification at reasonable intervals, material discrepancies dealt with in the books. Ministry of Corporate Affairs, Companies (Auditor's Report) Order 2020.
[F] Rule 11(g), Companies (Audit and Auditors) Rules 2014 — audit trail and edit-log requirement for financial years commencing on or after 1 April 2023, with an auditor reporting obligation. See ICAI's Implementation Guide on reporting under Rule 11(g).
[F] Section 143(3)(i), Companies Act 2013 — the auditor's report on internal financial controls with reference to financial statements.
[F] DPDP Rules 2025 — notified 14 November 2025 under the Digital Personal Data Protection Act 2023, with phased implementation.
[F] RBI FREE-AI Committee report — released 13 August 2025; seven guiding principles and twenty-six recommendations across six pillars. The survey findings cited above (bias validation 35%, drift monitoring 21%, audit logs 18%, interpretability tools 15%, real-time performance monitoring 14%, board oversight around one third, adoption around 21% with 67% exploring) are reported within it.
[F] EU AI Act — prohibitions from February 2025, GPAI obligations from August 2025, Article 50 transparency duties from 2 August 2026, Annex III high-risk obligations deferred to 2 December 2027 under the Digital Omnibus.
[I] "Ten to thirty per cent of a typical fixed asset register consists of ghost assets" — widely repeated and directionally consistent with verification experience, but traceable primarily to asset-verification vendors rather than independent research. Framing only, never a business case input.
[S] The six-step sequence, the twelve controls, the claim tags and the sign-off gate — my own operating framework, developed across controllership builds in FMCG asset assurance, tax operations and close management. Offered as a working standard, not an authority.

The short version

Build the finance truth first. Let rules produce every number. Let the model write the story around them and cite its sources. Show the output, never the capability. Label what it is. Then sign it — by name, against a version, at a recorded time.

Done in that order, AI stops being a risk item on the control matrix and becomes a drafting layer on controls you already own.

The twelve controls, the threshold register and the sign-off gate are available as a free Excel and PDF companion under resources — built to be filled in for one exception queue, not adopted wholesale.