.webp)
The FRC's AI guidance is written for audit firms, not for the companies they audit.
Read it (or otherwise research it) anyway.
It's the closest thing a UK finance lead has to an official view on what makes an AI tool's output trustworthy. And it comes from the regulator that inspects your auditor's work.
The FRC published its Generative and Agentic AI Guidance on 30 March 2026. It names three risks and four ways of reducing them. None of it binds you directly. But it does reveal what your auditor's firm is being asked to think about, which is a pretty good guide to the questions they'll be asking you.
What follows turns those four categories into questions to put to any software that touches your ledger, but also what they won't tell you.
How did we get here?
Think about how most AI actually arrived in your finance function. Nobody chose it. Your accounting platform added automated bank matching in a release note. Your AP tool started reading invoices and filling in fields somebody used to key manually. It didn't come through a procurement decision or a board paper. It just arrived one day as a feature.
So when somebody asks how a figure got into the ledger, you need to know the answer. The FRC has now written down what good looks like for the very people who'll be doing the asking.
The document itself (Generative and Agentic AI Guidance, 30 March 2026) is aimed at the central technical teams inside audit firms. The FRC calls it the first such guidance from any audit regulator globally. There's an earlier piece too: AI in audit: Illustrative example and documentation guidance (26 June 2025), covering how a firm documents a tool that uses AI.
Two things worth noting. First, it's guidance and nothing more. The requirements against which firms are assessed remain only those in the ISQMs and ISAs (UK). Second, the tools it has in mind are your auditor's, not the ones you have.
Which is exactly why it's useful. It tells you what questions might come your way.
Three risks your auditor now has a name for
The FRC separates three problems that look identical from the outside, and once you see the distinction, it changes how you think about controls.
A coding suggestion that's simply wrong. The FRC calls this "deficient output". The tool got it wrong. Straightforward.
A coding suggestion that's right, but accepted by the wrong person. This is "misuse of output". The answer was fine. The problem is that nobody with authority reviewed it, and nobody checked afterwards.
A method that doesn't meet standards, even when the output is correct. "Non-compliant methodology". Everything worked, but the approach itself wouldn't pass scrutiny.
Here's why this matters in practice: most finance teams only have controls for the first one. Is the number right? Great, move on. But a control that catches a wrong number will sail straight past the second problem. The person who accepted it had no business doing so, and nobody noticed.
"The tool is accurate" isn't an answer to either of the last two.
Four questions to ask your own stack
The FRC groups its mitigations into four categories. Turn them back towards your own tools and each one becomes a question you can ask.
01System design and development
What was it designed to do, and is that what we’re using it for?
This is the FRC’s “system design and development” category. It’s a reading exercise. Pull up what the vendor says the tool does, then compare it to what you’re actually using it for. Any gap is usually quickly visible (and often bigger than people expect).
02Certification
Has anyone independent actually tested it?
This is “certification”. It’s the only one of the four you can’t check yourself. You have to ask the vendor. And the answers you need are: who tested it, against what, with what result, and when it was last repeated. A vendor’s own accuracy figure measured on their own test set tells you about their sample, not your books.
03Staff education and governance
Does your team know what it’s doing and what to check?
“Staff education and governance.” This belongs entirely to you. Most finance functions have never written it down, which makes it the quickest win on the list. One page: what the tool does, who’s allowed to accept its suggestions, and what gets a second look. What controls do you have to make sure this stays true?
04Human in the loop review and oversight
Is a human actually reviewing the output?
“Human in the loop review and oversight.” Trace five transactions back to source and you may have your answer. Not whether a human could review it. Whether one did, and you have evidence of it.
There’s no set pass mark across these four, a challenge for us numbers folk. The FRC says the mitigations are weighed together, and how much confidence is enough depends on professional judgement, case by case.
The bit that's easy to miss (and it maybe matters most)
Everything above is guidance. This next part is a requirement that predates all of it.
ISA (UK) 500, Audit Evidence, updated September 2025, says at paragraph 9 that when using information produced by the entity, the auditor "shall evaluate whether the information is sufficiently reliable for the auditor's purposes".
Nothing in there mentions AI and it doesn't need to.
A ledger line produced by software is information produced by the entity in exactly the way a line keyed by a person is. If a human coded it, there's a human to ask. If a tool coded it and kept no record of why, there's nothing to show.
Your auditor still has to satisfy that paragraph. What they end up doing instead is more testing. And more testing reaches you as more time and more fee.
The four categories above are guidance for audit firms. Paragraph 9 is a requirement of your auditor.
What to have ready (none of this needs a project)
Four things. None of them needs a budget line or anybody's permission.
An inventory. One list of every place where software proposes or posts something without a person deciding. Most finance leads can't produce this list on request (I know because I've asked). Producing it is often the whole exercise.
A rule. One page saying who may accept what, and above which value a second person looks. Date it, and revisit it when the tool changes.
A record. What the tool did, when, and on what basis. The stronger version also records what it didn't do, and why. A rule that stood down with its reason attached is evidence that the rule was considered at all.
A reversal. Whether a posting can be undone, and whether the undoing shows up as a recorded event rather than a silent edit.
That's the ground Finzu is built on. Every automated action is logged, explainable and reversible. How that works sits on the platform page.
What this won't tell you
Three honest limitations.
It won't tell you you're compliant. There's nothing here to comply with. Reading guidance for audit firms as a client-side check is for consideration rather than instruction.
It won't tell you the numbers are right. A system can answer all four questions well and still at times produce a wrong number. Mitigations reduce risk. 100% correctness is a different question.
And it won't tell you what your own auditor will accept. That's their judgement to make. But awareness and understanding of how they look at it is a very helpful step.
One practical note: the FRC publishes HTML conversions of these documents alongside the PDFs, and the conversions carry a note saying they were produced using AI and shouldn't be relied on as definitive. Maybe use the PDFs!
Quick answers
We're not audited. Does any of this matter?
Not as an obligation. But all of it is good governance to have confidence in the numbers you are using to run the business.
Does this create new rules for auditors?
No. The 2025 documentation guidance says the requirements against which firms are assessed remain only those in the ISQMs and ISAs (UK).
The AI is already inside our accounting software. Does it still count?
Yes. It still belongs on the list. You can still ask the questions and record the answer.
How much documentation is enough?
The FRC says proportionate rather than exhaustive. Here's a working test: could a competent stranger follow one figure from the report back to the source document without asking you a question?
Finzu is being built for UK founders who need finance data they can act on today.
