AI Internal Controls in Finance: A Guide to Controlling AI-Prepared Financials

The question a finance team gets from its auditor, and from its own conscience, is short: who prepared this number, who reviewed it, and what proves it? When an AI agent prepares the number, the answer has to survive the same three questions. AI internal controls in finance are the design choices that make it survive: what the agent may do, what a person must approve, and what record remains afterward.

This guide is written for the controller who has to defend a number and for the IT or security lead who has to approve the tool that prepared it. It covers where AI creates control risk, the five controls an auditor will test, an architecture that keeps a model away from the arithmetic, and a checklist to run against any vendor, including us.

Scope note: this guide covers internal control over financial reporting as it applies to AI-prepared work. It does not give legal or audit advice, and your auditor decides what satisfies your own control framework. For the vendor-selection side, see Evaluating AI Finance Tools.

---

Why AI changes the control conversation

Internal controls were built around a simple fact: people prepare, and other people review. The preparer's name sits on the work, the reviewer's name sits beside it, and the gap between the two is the control. SOX compliance for public companies, and the same logic in private-company audits, rests on that separation.

An AI agent changes the preparer. The work still gets done, but the question of who stands behind it gets harder. Three things shift:

• The preparer has no memory of its own reasoning. A person can explain why they booked an accrual. A model produces output, and unless the system records the inputs and steps, nobody can reconstruct the why.
• The output can vary between runs. A spreadsheet formula returns the same answer every time. A language model asked the same question twice can answer differently, and one wrong answer in a hundred is enough to fail a control.
• The speed outruns the review. An agent can prepare fifty reconciliations before a reviewer finishes the first. A review step designed for a person's pace turns into rubber-stamping at an agent's pace.

None of these problems disqualifies AI from financial work. Each one has a design answer, and the rest of this guide gives those answers.

---

AI internal controls in finance: where the risk sits

Map the risk to the places where a model touches the process. Four spots matter.

Inputs. The agent reads bank feeds, invoices, ledgers, and spreadsheets. A wrong input produces a confident wrong output. The control is completeness and accuracy testing on what the agent reads, the same test you apply to any report your team relies on.

Judgment. The agent categorizes a transaction, matches a payment to an invoice, or drafts a variance explanation. Wrong judgment is the risk the 97 percent model post measures: the dangerous error is the one the system commits to with confidence, and a blank costs far less than a confident wrong entry.

Arithmetic. The agent computes a total, a tax amount, or a rollup. Language models make arithmetic errors, so the control is to keep arithmetic out of the model entirely, which the architecture section explains.

Posting. The agent writes to the ledger or the ERP. This is the point of no return, and it gets the strictest control: a named person approves before anything posts.

Spend your control effort in proportion to this order. Posting gets the gate, arithmetic gets the deterministic code, judgment gets the confidence and abstention rules, and inputs get the completeness checks.

---

The five controls an auditor will test

An auditor reviewing AI-prepared financials asks the same questions a controller asks of a human preparer. Five controls answer them.

1. A named human approves before anything posts

Every consequential step stops at a gate. The approver is a named person, with authority for the amount and the account. The gate is a system rule enforced in code, and a policy document does not count as one.

Build the gate around separation of duties. The person who configures an agent should differ from the person who approves its output on high-value items, just as the person who enters a journal entry should differ from the person who approves it.

2. Every number traces to its source

A reviewer must be able to click from a figure to the transaction or document behind it, without calling the preparer. This is the audit trail standard applied to agent output: source data, the steps taken, and the decision made, stored together.

For each agent output, ask whether a second person could reperform the work from the stored record alone. If the answer is no, the output has no support, whoever or whatever prepared it.

3. Exceptions go to a person, with evidence

Agents clear the items that match by rule. The rest become exceptions, and the control is that each exception routes to a person with its source documents attached, instead of getting a guess. An agent that resolves every item has hidden its uncertainty, which is worse than showing it.

Track the exception rate and the aging of open exceptions. A rising rate means the data or rules changed. Rising aging means the queue is outrunning the reviewers.

4. Access and permissions match the source systems

An agent should hold no more access than the person who owns the workflow. Role-based access inherited from the source systems keeps an agent from reading or writing what its owner could not. Credentials belong in a secret vault, and the agent's access should be read-only by default, with write access enabled per workflow after review.

5. A run log records what happened

Each run leaves a trace: inputs read, steps taken, outputs produced, who approved, and when. The log serves the auditor, and it serves the controller who needs to explain a surprising number three months later. Include model usage and cost in the trace, so the finance team can see what the agent did at what price.

---

The architecture that keeps a model away from the numbers

The strongest control against model error is to remove the model from the part of the work where error is expensive. Adopt's design follows one rule: the language model never touches the numbers.

Here is how that works in practice:

• Models read and write code, and people review the code. When a bank export arrives in an unfamiliar format, a model writes the conversion routine. A person reviews that routine once. After approval, the routine runs the same way on every file.
• Deterministic code does the math. Sums, tie-outs, and tolerance checks run in code that returns the same result on every run. A model never adds a column.
• A checker reviews the maker. One agent prepares and a second checks, running on a different model family, so a systematic blind spot in one does not repeat in the other.
• Every output carries a provenance record. Source data, computations, and decisions travel with the output, and approval requires a named reviewer.

One caution applies to the maker-checker pattern. Two agents agreeing is not independent validation, since both read the same inputs. The independent check is a tie-out against a number the agent did not produce: the ERP's own report, the bank statement balance, the subledger total. Build that tie-out into the review step and keep it standard across every workflow.

---

Autonomy as a dial the customer sets

A control framework needs a way to grow trust from evidence. Treat agent autonomy as a setting that your team moves per workflow and per action:

1. Watch. The agent reads and reports, and writes nothing.
2. Suggest. The agent proposes entries and matches, and a person applies them.
3. Act with approval. The agent prepares the action, and a person approves it before it runs.
4. Act. The agent runs the action within limits you set.

Start every action at suggest. Move an action to the right only after a track record exists: a stretch of runs where reviewers approved the agent's work without edits. Move it back left the day the record turns. This turns "can we trust it?" from a debate into a measurement, and it gives the auditor a documented reason for each level.

---

A checklist for any AI finance tool

Run these questions against every vendor. Skip none of them for a vendor you already like.

For the data-handling row, read How to Keep Client Data Private When Using AI Accounting Software and ask for the vendor's security reports under NDA.

---

What this looks like in a close

Consider a controller with twelve bank reconciliations due on the third business day. The agents prepare all twelve overnight. Each reconciliation arrives with matched items already linked to their source lines, and the unmatched items listed as exceptions with the statement line and the nearest ledger candidates attached.

The controller opens the queue. Nine reconciliations show a handful of timing differences, each explained. Three show larger exceptions. The controller reviews the exceptions, approves the explanations she accepts, sends two items back for support, and signs off. The log shows who prepared what, who reviewed it, and when. Nothing reached the ledger before her approval. For the full close workflow, see The Month-End Close: The Complete Guide and Account Reconciliation: The Complete Guide.

---

When AI controls fail

Controls on AI fail in familiar ways. Watch for these:

• Approval fatigue. Reviewers approve in bulk because the queue is long. Fix it by raising thresholds for what reaches a person, so that the queue holds only items that need judgment.
• Silent rule drift. A rule or prompt changes and nobody reviews the change. Treat prompt and rule changes like code changes: review them, version them, and log them.
• Unlogged overrides. A reviewer corrects an output in the ERP directly, and the agent's record no longer matches the books. Require corrections to flow through the same approval path.
• A control weakness left open. If a control fails repeatedly, classify it correctly. The difference between a material weakness and a significant deficiency decides what you report.