Don't let AI do the books. Let it build the tools.

An LLM guesses. Your ledger can't.

The current AI hype is about one kind of AI: large language models. An LLM is a program trained to predict the next word. To get good at that it picked up grammar, reasoning patterns and a lot of code. But it still returns a likely answer, not a calculated one. It can look like it did the maths without running any. It will invent an account code or a dimension rather than admit a gap. And it tends to go along with however you framed the problem.

Finance processes have a low tolerance for error, must be traceable and auditable, repeat on a fixed cadence, and span several systems, often with Excel as the glue. Every item on that list favours a deterministic program over a probabilistic reply.

So have it write the program.

Don't hand a model a month of transactions and ask for journal entries. You can't audit how it got there. Have it build the pipeline instead: describe what you want in plain language, run it, check it, refine. That's vibe coding. Code is inspectable, testable and identical on every run, so the model's unreliability gets caught when you build, not when you close.

Then have it build the checks too. The simplest one is also the most useful: do the journal entries sum to the transactions in the source? Checks that fail loudly are what let you automate aggressively.

Three builds that work.

1. Bookkeeping for high-volume transactions

Before: the data team exported the month's transactions and split them into 500,000-row files so Excel could open them. Finance mapped and filtered them by hand; external bookkeepers did the VAT coding and the upload. After: SQL and Python map every transaction type to G/L and VAT codes, create missing customers, post journals through the ERP's API and reconcile every run. The work moved in-house, close got faster, and more than one full-time role was freed.

2. Bank reconciliation

The ERP's matching rules cleared only 30% of incoming payments. Unmatched payments were the top cause of finance support tickets and touched three people on the team. A colleague pulled bank lines from the data warehouse and had the model match them against open invoices, locally, connected to nothing. It quickly matched most of the rest, which justified a real tool: hosted behind a VPN, with role-based access, posting through the ERP's API and keeping a full audit trail. Two months to build. Almost one full-time role saved, and customers see their money sooner.

3. A fraud triage agent

An agent is an LLM running in a loop with tools: it reads the context, decides what to do next, and repeats. Here, threshold rules flag suspicious transactions: an implausible unit price, or one card used at two distant locations minutes apart. The agent gets a prompt of known fraud patterns, pulls whatever extra data it needs from the warehouse, and assesses each case. Only the likely ones reach a person in Slack. It runs on a small, cheap model.

How to roll it out.

Guardrails from day one.

• Scope ERP access. Start read-only. Test broader permissions in a sandbox.
• Separate journals for automated postings, so the audit trail is obvious.
• Limit what the assistant can touch. Trusted folders only, and guard your API keys.
• Decide how tools get deployed and who can use them. Governance and connectivity are usually the bottleneck, not the model.
• Match the model to the job. Expensive models for design, cheaper ones for implementation and high-volume runs.

The tools are here now. Don't wait for one magic AI product to automate finance. Turn the team into people who build their own.