Most finance teams at mid-sized companies do not have an AI problem. They have a transport problem. Invoices arrive as PDFs, photos, and email bodies. Bank lines need matching to open items. Month-end means pulling the same numbers from three systems into a spreadsheet and then explaining the variances. The accounting judgement in all of this is real, but it is often a small share of the hours.
That is the honest case for AI in accounting: it is good at moving, reading, matching, and drafting, and it is not a substitute for accounting judgement or for your control environment. This guide is for finance leads who want to use it without creating a problem for their auditors.
What "AI" means in a finance team
Four different technologies get sold under the same label, and they are good at different things:
- OCR reads characters off a document: invoice number, date, amounts. It does not know what the invoice is for.
- Rules and RPA move data along fixed paths: "this supplier always goes to account 6300". They are reliable until the first exception.
- Machine learning classifiers learn from your history to suggest an account, cost centre, or tax code, with a confidence score.
- Large language models (LLMs) handle language: they read an email, summarise a contract clause, draft variance commentary, or answer "why is this invoice on hold?" from the underlying records.
In practice a useful setup combines them. The important point is that each of them produces a suggestion, not a booked entry.
A published example makes this concrete. In the Bookkeepr project, Fraunhofer Austria developed and tested an account-classification method on a dataset of about 4,400 invoices. The first suggestion was the correct account in 75% of cases, and the correct account was among the top three suggestions in 94% of cases (Fraunhofer Austria). That is a useful assistant. It also means roughly one first guess in four is wrong, which is exactly why a person approves the posting.
Where AI helps
Invoice capture and coding
The strongest starting point for most teams. AI extracts the header and line data, matches the invoice to a supplier and, where you use them, to a purchase order and goods receipt, and proposes account, cost centre, and tax code. Clean, repeat invoices from known suppliers can flow straight to an approver. Anything unusual (a new supplier, mixed tax rates, a vague description, a changed bank account) goes to an exception queue with the reason stated.
Structured e-invoices will reduce the reading part over time. Under the EU's VAT in the Digital Age package, Council Directive (EU) 2025/516, e-invoicing and digital reporting become mandatory for intra-EU B2B supplies from 1 July 2030 (European Commission overview). The coding, matching, and exception work remains.
Bank and account reconciliation
Matching bank lines, payment-provider payouts, and open items is pattern work, and AI handles the messy middle better than rules: shortened references, batched payouts, fees netted off, a customer paying three invoices in one transfer. The design that works has three paths: confident matches are cleared automatically under a rule you approved, plausible matches go to a review queue with the evidence shown, and everything else stays manual. Measure false matches and reopened items, not only the automatic match rate.
Month-end close
AI does not close the books, but it removes a lot of the chasing. Typical uses: a close checklist that tracks itself from system data, flags for accounts whose balance moved unusually, lists of unbilled or unmatched items, draft accrual lists from open purchase orders and missing invoices, and first drafts of intercompany reconciliations. Each output is a worklist for an accountant, not a posting.
Reporting and variance commentary
This is where LLMs are most useful. Given the trial balance, budget, and last period's numbers, an assistant can draft variance explanations, answer ad hoc questions ("what drove travel costs up in Q3?") from live data, and prepare the first version of a management pack. The controller still owns the narrative, because only they know which variance is a timing difference and which is a problem.
What must stay human
Draw this line before any pilot, and write it down:
- Approving postings that touch the ledger, at least above a threshold you set, and always for new suppliers and unusual accounts.
- Judgement areas: accruals and provisions, revenue recognition, impairments, tax treatment of unusual transactions.
- Payment release. An agent can prepare a payment run; a person with payment authority releases it.
- Master data changes, above all supplier bank details. A request to change bank details is a classic fraud pattern, and it should be verified through a separate channel, whatever the AI thinks of it.
- Signing off the accounts. Responsibility for the financial statements does not move to software.
Controls: treat the agent as a user
A common mistake is to connect an AI tool with a broad technical account and forget about it. From a controls perspective, an agent is a user. It needs its own identity, its own permissions, and a place in your segregation of duties matrix.
The classic procure-to-pay conflicts still apply, and an agent can collapse them into one pipeline if you let it. The same identity should not be able to:
- create or change a supplier and post that supplier's invoices;
- post an invoice and release its payment;
- change a matching rule and approve the matches it produces.
In practice that means scoped permissions per task (read invoices, create draft postings, never release payments), approval steps enforced by the accounting system rather than by the agent's good behaviour, a documented owner for every rule and prompt that affects the books, and a way to switch an automation off quickly without stopping the rest of the finance stack.
The audit trail
Your auditor will ask where an entry came from. With AI in the loop, the answer should be a record that shows:
- the source document or data the system used;
- what it proposed, with the model or rule version and the confidence;
- who approved, changed, or rejected the proposal, and when;
- what was finally posted.
Bookkeeping rules already expect this kind of traceability. In the UK, companies must keep records that are sufficient to show and explain their transactions (Companies Act 2006, section 386). Germany's GoBD and Austria's BAO require that the original content of an entry remains visible after a change. A complete action log meets these expectations more easily than the manual reality it replaces, where decisions live in email threads and spreadsheets. Keep the log for as long as the accounting records it supports have to be kept under your national rules.
How integration with the accounting system works
A working setup does not start with a chat window next to the ERP. It starts with a controlled data path:
- Read access to the accounting system through its supported interfaces (APIs, data services, or a vendor-approved export), scoped to what the use case needs.
- An integration layer between AI tools and the ledger. We use the Model Context Protocol (MCP) for this, so any approved AI tool can use the same connectors and the same permissions. We explain the approach in MCP explained for the enterprise.
- Writes as drafts. The agent creates draft postings, a staged journal, or a booking batch that waits for approval in the accounting system itself, so every validation the system enforces still applies.
- Logging at the layer, so every read, proposal, and approval is recorded in one place.
The accounting system stays the system of record. The AI layer holds no figures of its own that someone could mistake for the truth. We go into the patterns in more depth in AI in ERP: what actually works. The same approach can work with DATEV, BMD, Microsoft Dynamics NAV and Business Central, Exact, weclapp, and older systems through custom connectors.
Data protection and the EU AI Act
Invoices and bank data contain personal data, so the usual GDPR work applies before a pilot: a data processing agreement with every provider in the chain, clarity on where data is processed and stored, and a contractual answer to whether your data is used to train anyone's models.
Most accounting uses of AI are not high-risk under the EU AI Act. One exception matters for finance teams: AI used to evaluate the creditworthiness of individuals or to set their credit score is listed as high-risk in Annex III (fraud detection is excluded), and those obligations apply from 2 December 2027. If you score individual customers, including sole traders, check that use with counsel. The AI literacy duty in Article 4 applies to every company using AI, including the finance team. We cover the wider governance picture in AI governance for mid-sized companies.
A sensible first 90 days
- Weeks 1 to 3: pick one process (supplier invoices or bank reconciliation are the usual choices), measure today's baseline (time per item, correction rate, days to close), and agree the human-approval line in writing with your auditor or tax adviser.
- Weeks 4 to 8: connect read access, build the draft-and-approve flow, and run it in parallel with the current process. Compare every result.
- Weeks 9 to 12: switch the routine cases over, keep the exception queue, and review the numbers against the baseline. Decide on the next process from your own data, not from a vendor benchmark.
Master data comes first in practice. Duplicate suppliers and inconsistent coding teach any model the wrong patterns, so a cleanup is usually part of the first month.
If you want your team to learn this on your own systems, our AI workshops for finance teams are built around exactly this setup.
Talk to us
If you have a finance process in mind and want a straight answer on whether AI will help and what controls it needs, talk to us.