Ask better questions
In finance, the AI conversation usually revolves around "where can we use it?" This question is too broad. A more useful question might be more along the lines of: where in the process do we require judgment?
When you do a review from this perspective, step-by-step, you will quickly find that most of the month-end close is based on clear rules. Match the bank line. Apply the contract rates. Allocate shared costs on the agreed basis. Post the recurring journals. Revalue the foreign currency balances. Compare this month with last month and flag anything over the threshold. None of that needs judgment. It needs a rule, written down once and applied the same way every time.
That work should run on plain scripts and the features already built into your accounting system. Once in place though, it should be boring. Boring is the goal. The interesting and more valuable work for finance teams is elsewhere, and the more of the rules you make boring, the more time (and AI credits) there is for it.
Most of the close has been automatable for years
Bank matching rules, recurring journals, scheduled reports and reconciliation checks have been available in mid-market accounting systems for a long time. When they still aren't automated, the reason is rarely the technology. It's usually that the rule was never written down explicitly: which reference to match on, what counts as a duplicate, what's material, which of three systems holds the real number. The hard part of automation is not the code, it's mapping out the process at a level of detail that enables you to implement it successfully.
AI makes coding the script cheap. It can help draft the matching logic, the reconciliation check or the report query. What you need is someone who understands the process to guide the AI through implementation, review it, test it thoroughly and put it into production. What can be scripted, must be scripted, and it has never been easier to script it.
Three questions for every step
To decide what goes where, take each step in a process and ask three questions.
Is the input structured? A bank feed, a ledger extract or a usage export arrives in rows and columns, with the same fields every time. An invoice PDF, a remittance email or a contract doesn't.
Can code check the answer? Some outputs can be verified mechanically: the extracted invoice total equals the sum of its lines, the vendor exists in the vendor master, the reconciliation ties to the ledger. Others can't: whether a variance explanation is right, or whether a new contract should be accrued on usage or on its minimum commitment.
What are the stakes if it's wrong? A miscoded $40 software charge is a nuisance. A wrong revenue number in the board pack can lead to a decision made on bad information.
The answers sort the work into three kinds.
- Structured input, checkable answer: script it. This is most of the close. A script gives the same answer every time, costs next to nothing to run and can be re-performed by anyone who asks.
- Messy input, checkable answer: the model reads, the code checks. The model pulls the supplier, date, amount and lines off the invoice. Code confirms the lines add up, the supplier is in the vendor master and the purchase order exists. Anything that doesn't pass goes to a person. The model handles the mess. Code handles the trust.
- Judgment that code can't check: the model drafts, a person decides. Variance commentary, the basis for an estimate, a revenue recognition call. The model can do much of the groundwork: pull the transactions, find the likely causes, draft the explanation and even provide a recommendation. The decision, and the signature, stay with a person.
The stakes question doesn't move a step from one kind to another. It sets how much review the step gets. A low-risk, high-volume step can be sampled. A high-stakes one gets a full review every time.
Where the model earns its place: the exceptions
Every set of rules leaves something behind. The payment with no reference. The supplier spelled three different ways across two entities. The customer who paid two invoices in one transfer, short by the bank fee. Rules don't cover these, by definition, and this residue is where a surprising share of finance time goes. It's also where AI adds the most value today.
Working an exception is investigative work. Pull the related transactions, read the email or the contract, compare with similar cases, propose a resolution and explain it. A model does that well, and a person can review a proposed resolution, with the evidence attached, far faster than they can build one from scratch.
There's a second benefit that's easy to miss. When the same kind of exception is resolved the same way three months running, it isn't really an exception anymore. It's probably a rule that nobody has written yet. Document it, script it and take it out of the pile. Over time the exceptions shrink and the scripted core grows. The model ends up doing several jobs: - working the residue - showing where the next rules are - helping you implement them
Why boring wins
It's tempting to point an agent at the whole process and let it work everything out. For the rule-based steps, a script is better on every measure that matters in finance.
It's consistent. The same input gives the same answer, every time. A model's answer is usually right, but "usually" isn't a standard you'd want your finance team working from.
It's cheap. A script costs next to nothing to run, every day, for years. A model is paid for on every run, and that cost grows with volume.
It's auditable. A script can be read, tested and re-performed. When someone asks how a number was produced, the answer is the code and the data, not a description of what the model probably did.
It fails loudly. When a script hits something it doesn't expect, it stops with an error. A model facing the same surprise tends to produce something plausible. In finance, loud failure is a feature.
AI is a key tool today, and as finance leaders it's our responsibility to put it where it's strongest, and to rely on deterministic systems to carry the weight everywhere else.
Getting the order right
The sequence matters more than the tools.
- Definitions first. Agree what each number means, how it's used, and where it comes from. Automation built on conflicting definitions or data only produces the confusion faster. We walked through a real case of exactly this.
- Rules next. Write down how each step works: what to match on, what's material, how shared costs are allocated. Documenting in detail is tedious, but it's a key step in automation.
- Script the rules. This is where the deterministic, repeatable automation lives: the accounting system's own features where they exist, plain scripts where they don't. Let a model help write them, then test them like you would any other control.
- Point the model at the residue. Exceptions, messy inputs, first drafts of commentary.
- A person signs. Whatever produced the work, someone owns the result. A number needs an owner who can explain and justify it.
If you want a starting point, pick one process you run every month, list every step and ask the three questions of each. Then tackle them one at a time. Most teams find that more of the process is scriptable than they expected, and that the steps that genuinely need judgment are fewer, and more interesting, than the ones currently eating the week.
Intelligence where warranted
The goal isn't a finance function run by AI. It's one where the rules run themselves, quietly and reliably, the exceptions get worked quickly, and the team spends its time where it adds the most value. Save human and artificial intelligence for the parts that deserve it.