Last reviewed: 27 July 2026.
The rule that decides every finance use case
Finance is among the best environments for AI and among the easiest to get wrong, and the reason is a single misunderstanding about what these systems do.
A large language model generates the most plausible continuation of a sequence. It does not compute. When it produces "£1,284,551", it has generated a number that looks right in context, not calculated one. Most of the time in simple cases it will be correct, which is precisely what makes it dangerous — the failure is silent, well-formatted, and carries no internal signal that anything went wrong.
That gives you one rule which resolves nearly every finance use case:
Calculation belongs in systems that are deterministic and auditable — the ledger, the spreadsheet, the reporting tool. AI belongs on the text: explaining, summarising, drafting, extracting and triaging. A use case that requires the model to produce a number that must be right is the wrong use case, regardless of how appealing it sounds.
Use cases that work
Variance commentary and board narrative
The numbers come from the reporting system. The model drafts the explanation: which lines moved, by how much, against what comparative. Finance teams routinely spend a significant share of month-end writing narrative that says the same things in a different order each period, and this is language work over settled figures — exactly the right shape. The reviewer still owns the explanation of why a variance occurred, which is the part requiring business knowledge the model does not have.
Document data extraction
Pulling structured fields from invoices, statements, remittances and expense receipts. This works well because the output is verifiable against the source document, and because the failure mode is visible — a wrong field is caught by the same validation that already catches keying errors. Match extraction to existing three-way-match controls rather than replacing them.
Contract and policy question answering
"What are the payment terms with this supplier?" answered against the actual contract set. High value because the alternative is someone spending twenty minutes in a shared drive, and low risk because answers cite a source document the user can check. This depends entirely on the underlying documents being current — a knowledge assistant over a superseded contract library produces confident answers about terms that no longer apply.
Credit control correspondence
Drafting chase sequences at the right tone for the relationship and the ageing. The amounts and dates come from the ledger; the model writes the message. Measurable against days sales outstanding, which makes the benefit case straightforward.
Month-end query triage
Routing and summarising the inbound queries a finance team receives during close — categorising, drafting responses to routine ones, escalating the rest. The benefit is concentrated in the busiest week of the month, which is also when it is most visible.
Use cases that fail
Anything requiring guaranteed arithmetic
Calculating balances, footing schedules, computing tax positions, deriving ratios. Use the tools built for this. If the appeal is a natural-language interface, the correct pattern is a model that writes a query which a deterministic system executes — not one that produces the answer directly.
Forecasting from thin history
Models will produce a forecast from almost any input, including inputs that cannot support one. The output is fluent and carries no uncertainty signal. Statistical forecasting tools at least fail visibly, with confidence intervals that widen. Where you do use AI here, use it to explain a forecast produced elsewhere.
Judgement calls dressed as classification
Provisioning decisions, going-concern assessment, capitalisation judgements. These have accountability attached to a named person. A model can assemble the evidence for such a decision; it cannot hold the responsibility for it, and a control that assumes otherwise will not survive review.
Anything in a consumer chatbot with real financial data
The use case may be sound while the deployment is not. Management accounts pasted into a personal account is a confidentiality and data-protection problem irrespective of how useful the output was. This is the most common way finance teams are already using AI, which is why discovering it early matters — our guide to shadow AI covers surfacing it without driving it further underground.
The controls finance actually needs
- Deployment boundary: which tool, on what contractual terms, covering training use, retention and data residency.
- Source citation: any answer drawn from documents should identify the document, so verification takes seconds rather than requiring a search.
- Review proportionate to consequence: a drafted chase email needs a glance; anything reaching an audit file or a board pack needs a named reviewer with time to do it properly.
- Audit trail: what was generated, from what inputs, reviewed by whom. Finance is already good at this discipline — apply the existing standard rather than inventing a parallel one.
- Segregation of duties: AI-assisted preparation does not change who is permitted to approve.
Formalise these with a structured AI risk assessment per use case, and set permissions with role-specific guardrails rather than one blanket policy — the appropriate latitude for credit control differs from that for statutory reporting.
Where to start
Take one use case, not a programme. The best first candidates share three properties: the output is text, the input is a document or a settled number, and there is an existing measure you can compare against.
On that test, document extraction and variance commentary are usually the two strongest openings. Both have a clear baseline — invoices processed per hour, days to produce commentary — and both fail visibly rather than silently, which is what you want from a first pilot.
Capture the baseline before you start. A finance function that cannot state how long month-end narrative currently takes cannot demonstrate that it now takes less, and a pilot that cannot demonstrate benefit gets cancelled by someone who cannot see it. Run the use case through a six-dimension readiness assessment first — in finance, the dimension that most often stops a pilot is data, and it is considerably cheaper to find that out in an assessment than four months into implementation.
Frequently asked questions
What are the best AI use cases for finance teams?
The strongest are language-layer tasks over numbers that have already been calculated: variance commentary and board narrative, invoice and document data extraction, contract and policy question answering, credit control correspondence, and month-end query triage. Each takes text or documents as input and produces text as output, with the arithmetic performed by systems that are deterministic.
Can AI do the calculations in financial reporting?
Large language models should not be relied on for arithmetic that has to be right. They generate plausible continuations rather than computing values, so they can produce a figure that is well-formatted, confident and wrong, with no internal signal that anything failed. Keep calculation in the ledger, spreadsheet or reporting tool, and use AI for the language wrapped around the result.
Is AI safe to use with financial data?
It depends entirely on the deployment. Pasting management accounts into a consumer chatbot is a data-protection and confidentiality problem. The same task through an enterprise deployment with contractual guarantees on training use, retention and residency can be acceptable. The question to resolve before any pilot is where the data goes and what the provider is permitted to do with it.
Where do finance AI pilots usually fail?
Three places. Choosing a use case that requires guaranteed arithmetic; running a pilot on data the finance team knows is unreliable, so the output is never trusted; and providing no baseline, so the pilot cannot demonstrate benefit and is cancelled at the next budget review.