AI in finance: what to actually automate in your back office before dreaming of a robot CFO

Almost every conversation about AI in finance starts in the wrong place: models that predict the business, dashboards that narrate themselves, a CFO assisted by a copilot that knows everything. Meanwhile, someone on the team is three days into matching bank statements against invoices in a 4,000-row spreadsheet. The real value is down there, in the repetitive work nobody brags about on LinkedIn, and that is exactly where the technology already works with reasonable guarantees.

This article is what we tell a finance director who asks where to start. Ordered by lowest risk and highest hours returned, traps included.

What does AI in finance actually do today?

It helps to separate three families of technology that people lump together, because their maturity, cost and risk are very different:

• Extraction and classification. Reading a document (invoice, statement, contract) and pulling out structured fields. This is the most mature thing available. A model reads a scanned invoice better than the positional rules people used ten years ago, and it survives a supplier changing the layout.
• Prediction on historical data. Collections, late payment, cash burn, demand. It needs clean history, and it returns ranges with uncertainty, not truths. We cover it in predictive analytics.
• Language applied to data. Summarising a variance, drafting the month-end commentary, answering "how much have we spent on logistics this quarter?". Useful as a query layer on top of data that is already trustworthy. Dangerous as a source of truth.

The rule we use: start where the output can be verified in seconds. An extracted invoice is checked by looking at it. A six-month cash forecast can't be checked for six months. That detail sets the whole implementation plan.

Finance doesn't reward innovation: it rewards the number adding up. Any automation you can't audit backwards is surplus, however good its hit rate.

Where do you start: bank reconciliation and invoices?

Yes, and it's no accident that it's the least glamorous part. Reconciliation and document capture share three ideal properties: high volume, repetitive judgement and immediate verification.

Supplier invoice capture. The typical flow: a PDF arrives by email, someone opens it and types in supplier, net amount, VAT, ledger account and cost centre. With automatic extraction, the system proposes all of those fields and a person validates. The change of role is the key point: you move from typing to reviewing exceptions. What you should measure isn't "how many invoices it processes" but what percentage goes through untouched, and how many errors slip into the ones that did.

Bank reconciliation. Here the judgement isn't reading, it's matching: this €1,240.50 entry on the 3rd corresponds to that invoice, or to those three grouped together, or to an invoice minus an early-payment discount. Classic rules handle the clean cases; the model earns its keep on the dirty ones: grouped amounts, wrong references, partial payments, batched remittances.

Expense and card management. Automatic classification of receipts by category and cost centre, duplicate detection, out-of-policy amounts. This is the case with the least internal resistance, because the team that suffers it is the team asking for it.

Three things that always break if nobody decides them upfront:

• The confidence threshold. Below a certain level, send it to human review. Set it too high and you save nothing; too low and you push rubbish into the ERP. It gets calibrated with real data, not with the vendor's demo.
• Your company's odd cases. Multi-currency invoices, self-billing, suppliers with withholding tax, partial credit notes. Always ask for a test with your difficult documents, not the samples the vendor brings.
• The way back. If the system proposed wrongly and it got posted, how is it corrected and where is it recorded who approved it? Without that, you don't pass an audit.

Can AI speed up the month-end close?

It can, but rarely where people look. The close doesn't drag because humans type slowly: it drags because of waiting, data arriving late, and hunting down mismatches. AI helps at two specific points in that chain:

• Anomaly detection before the close. A model that learns the normal pattern of each account and flags the odd during the month: an entry with the sign flipped, a duplicated expense, an account moving 400% for no reason. Moving the error hunt from the 5th of the following month to the day it happens is what actually shortens the calendar.
• Drafting management commentary. The variance analysis is done by a person; the structured draft and the cross-checked figures are prepared by the system. It saves a Friday afternoon, it doesn't replace judgement.

What we do not recommend automating in the close: provisioning decisions, estimates that depend on information nobody recorded, and any entry with material tax impact that lacks explicit approval. Not out of fear: because the saving is small and the cost of an error is large. That asymmetry decides.

If your bookkeeping sits with an external firm, the conversation moves but the substance doesn't; we develop it in AI for accounting firms.

How do you build a cash forecast anyone will use?

This is the case with the most demand and the most disappointment. Cash forecasting almost always fails for the same reason: an elegant model built on data that doesn't reflect how the company actually gets paid.

What works is duller and more useful: a model of probable payment date per invoice, not a monthly aggregate. Every customer has a behaviour — the one who pays at exactly 30 days, the one who pays at 75 despite signing 60, the one who withholds 10% until the project closes — and that pattern is in your collections history. From that you build an inflow curve with a range, not a single figure.

Minimum requirements for something defensible:

• 24 months of history of issued invoices with their real payment date (not the due date: the real one).
• Known outflow commitments: payroll, rent, taxes, loan instalments, recurring costs.
• The order book or signed contracts, for what hasn't been invoiced yet.
• An owner, usually the controller, with authority to override by hand what they know and the model doesn't.

That last point is what separates a pretty chart from a living tool. And the bar for judging it isn't theoretical accuracy: it's whether the committee uses the number to decide. If nobody opens it after three weeks, the model didn't fail — the fit with day-to-day operations did. It's the pattern we analyse in why AI pilots fail.

What data do you need before automating anything?

Almost all the work in a finance AI project happens before the model. This is the checklist we run before promising anything:

| Use case | Non-negotiable data | Sign you're not ready | |---|---|---| | Invoice capture | Accessible original documents and a single supplier master | Invoices across three inboxes and one supplier registered four times | | Bank reconciliation | Normalised statements with description and reference; matching history | They're downloaded by hand as PDFs every week | | Anomaly detection | 24 months of entries on a stable chart of accounts | The chart of accounts changed six months ago with no mapping | | Collections forecast | Real payment date per invoice, not just the due date | The only field is "paid / not paid" | | Spend analysis | Mandatory cost centre and consistent categories | 30% of spend lands in "miscellaneous" | | Natural-language querying | One documented source of truth | Three reports give three different revenue figures |

If your table fills up with signs from the right-hand column, this isn't an AI project yet: it's a housekeeping project. It stings to say and it saves money. The short way to fix it is in data strategy, and the ownership scaffolding in data governance.

Which controls and risks can't you skip?

Finance is the department where improvisation lands worst, and rightly so. The minimum controls we require in any implementation:

• Full traceability. Every automatic proposal stores where it came from, with what confidence, and who approved it. If the auditor asks about an entry from eight months ago, the answer has to be one click away.
• Segregation of duties. The system proposes; a person with different permissions approves. Especially with payments: you don't automate the payment order, you automate its preparation.
• Hard limits by amount. Above a threshold, human review is mandatory no matter what.
• Data leaving the building. Before sending invoices or statements to an external service, check what it stores, for how long, and whether it reuses your information. There is personal data involved (sole-trader suppliers, payroll) and the framework we describe in GDPR and AI applies.
• A degradation plan. If the service goes down mid-close, how do you carry on? An automated process with no documented manual mode is an operational risk, not an improvement.

And one warning about fraud: the same technology that helps you helps whoever is trying to slip you a fake invoice with a changed IBAN. Approving a change of a supplier's bank account must stay human, verified through a channel other than email. No exceptions.

How do you measure the return without fooling yourself?

The classic mistake is counting saved hours in a spreadsheet and calling it done. A more honest frame measures four things per use case:

| Metric | What it answers | How it's measured | |---|---|---| | Straight-through rate | How much goes through untouched? | % of documents or transactions with no intervention | | Escaped error rate | What slips through wrong? | Monthly sampling of what was auto-approved | | Cycle time | Is the process faster? | Days to close, days from invoice to posting | | Total cost | Does it pay off? | Licences + integration + maintenance + human review |

That last block is the one missing from vendor ROI calculations: human review doesn't disappear, it shrinks. And maintenance is real, because formats change and models drift.

A sensible order for the first twelve months, no heroics: months 1-2, tidy the data and choose the case; months 3-4, pilot on a real subset with measurement from day one; months 5-6, decide to scale or stop with numbers on the table; the rest of the year, a second case leaning on the same infrastructure. The first one is the expensive one, which is why the first one should be the boring one. How to prioritise between processes is covered in AI process automation.

Frequently asked questions

Does AI in finance replace the back-office team?

In practice it changes the work mix, not the headcount. Typing disappears and exception review, control and analysis grow. The companies we've seen handle this well don't make redundancies: they stop hiring temporary cover for peaks and free up senior time that was going into administrative-level tasks.

What accuracy is acceptable for invoice capture?

It depends on the field. For supplier, date and total amount the bar is very high and any doubt should go to review; for ledger account or cost centre you can live with a proposal a person corrects. What matters isn't a headline accuracy figure but having a calibrated confidence threshold and measuring how many errors reach the ledger.

Do I need to change ERP to use AI in finance?

Almost never. Most useful cases are built around the ERP, reading and writing through its interfaces rather than living inside it. Replacing an ERP to add AI is usually a decision that was already made for other reasons; if someone sells it to you as a requirement, ask them to show why integration isn't possible.

And cash forecasting — how wrong does it get?

It gets things wrong, and that's the point: what you ask of a collections forecast is a range with a confidence interval and a list of the invoices that move it most, not an exact number. If it improves visibility over the next 8-13 weeks enough to anticipate a cash squeeze, it's already paying for itself.

If you have a finance department with more spreadsheets than you'd like and you want to know what can genuinely be automated in your case — and what shouldn't be, with reasons — that diagnosis is exactly what comes out of the audit: cases ranked by effort and return, starting from the real state of your data. If you'd rather sanity-check it in half an hour before moving anything, let's talk.