The control model: how you let AI near the ledger

The first question a controller asks about AI is not what it can do. It is how anyone would let it near the numbers. That is the right question, and it has a plain answer. The answer is a pattern, and once a team sees it they can apply it to every recurring process they own.

Four parts, always the same

1. 01Input. A file, an export, a query result. The export is the read-only boundary: the tool sees a copy, never the system of record.
2. 02Transformation. Two kinds. The deterministic part, sums, joins, as-of logic, thresholds, is code, and code is tested. The AI part reads what the code produced, classifies the exceptions, and drafts the explanation. It never does the arithmetic.
3. 03Output. A workbook, a note, an email, a draft journal. It lands in a review folder or an inbox. It does not land in the ledger.
4. 04Human check. A named person reads the output and approves it. The approval is the trigger for anything that posts. Every run writes what it did and why, so there is a log.

That is the whole model. The tool prepares, a person approves, nothing touches the ledger without one, and there is a record. It is the same architecture every serious ERP and close-platform vendor is building into their own agents. Teams that learn the pattern are not learning a vendor; they are learning the thing that stays true when the vendor changes.

What it looks like in a reconciliation

Take the monthly AP sub-ledger to GL control-account reconciliation. Most finance teams have one, by company and GL offset, and it takes three to six hours a month.

• Input: the AP open-item extract as of month end, and the trial balance report, which arrives as a PDF print.
• Deterministic transformation: pivot the sub-ledger by company and offset, derive the GL account string from the lookup, compare to the trial balance, compute the difference per account. That is a query and it does not change.
• AI transformation: read the trial balance PDF into rows, look at each difference, classify it as timing (GL date differs from activity date) or error, and draft the one-line explanation. Then draft the approval email that already exists in the process.
• Output: the reconciliation workbook in the reviewer's familiar layout, summary tab, TB totals, AP-versus-GL tab, and the email.
• Human check: the accounting supervisor reads it and replies with the approval, exactly as they do today. Nothing posted. Nothing changed in the ledger. Three to six hours became one review.

What the auditor asks, and the one-page answer

The auditor will ask three things. What data did the tool see, and could it change anything. Who approved the output, and can you show it. Is the calculation reproducible. The control model answers all three by construction: the export is read-only, the approval is recorded, the deterministic part is code with tests. A team that can say that in one page has a better answer than most teams have for their spreadsheets today.

Where teams go wrong

• Letting the AI do the arithmetic. It will be right most of the time, which is worse than being wrong all of the time, because nobody checks. Arithmetic is code.
• Automating the wrong thing first. The first process should be high volume, rule-bound, and something the auditor will not ask about. Journal entry preparation is the last thing to automate, not the first.
• Skipping the log. If a run cannot say what it did, it did not happen. The log is what turns a clever script into a control.

The pattern is taught in the flagship course, where each person builds it on one of their own processes and the sponsor leaves with a ranked list of what to automate next.