Services 01 Projects 02 About 03 Insights 04 Contact 05 Book a discovery call 06

Accountants ·

Automate Bookkeeping With AI: A Guide for Practices, Not Business Owners

Every article on 'AI bookkeeping' is aimed at a founder with one company. This one is for the practice doing it for fifty, where the question is not 'can AI do my books' but 'which parts of my team's week can a system take, safely, across every client'.

We run our own bookkeeping this way, so this is written from the inside. An accountant sends a weekly query sheet. A system reads it, classifies each row, raises the sales invoices, finds and files the purchase receipts, and writes back what it did. A person reads a plan before anything is created and answers the handful of rows the system was not sure about. The hours that used to go on it now go on the few decisions that need a human.

What follows is the honest version of what AI can and cannot do in a bookkeeping practice, with the lines drawn where we drew them.

Where AI helps: the language around the numbers

Bookkeeping is mostly deterministic. The parts that are not are the parts where a human has to read something and decide what it means. That is where a language model earns its place.

  • Bank descriptors to suppliers. "AMZNMktplace", "SQ *THE COFFEE", "DD BT GROUP". A model, or a maintained lookup backed by one, turns the descriptor into a vendor and a likely category. Unknown descriptors get flagged rather than guessed.
  • Client replies to queries. "That one's the insurance, and the £40 was for the office." A model turns the sentence into posting proposals that a bookkeeper approves in seconds instead of re-keying.
  • Receipt matching. Reading the receipt, extracting vendor, date, total and VAT, and matching it to a bank line on exact amount and date window. Anything ambiguous, including one receipt that could match two charges, goes to a person.
  • Narrative. The monthly commentary ("costs up because of the annual insurance; debtors improved; cash covers four months") drafted from the figures for the manager to edit.
  • Triage. Reading the mailbox and deciding which messages are receipts, which are "your bill is ready" notifications that need a portal login, and which are nothing.

Where it should not: the ledger itself

The model never has write access to Xero, QuickBooks or Sage on its own authority. Every posting, invoice and journal is proposed in a plan a person approves. This is not caution for its own sake. A model that is 97% right across a thousand postings produces thirty wrong ones with no way of knowing which. The human review is cheap when the preparation has been done; it is the preparation that was eating the week.

Three rules we keep:

  1. Exact matching for money. Two decimal places, date window, vendor. An early version of our receipt matcher matched £8.00 to any amount containing an 8. Never again.
  2. No guessing of account codes. If a client has history for a service, infer from it. If not, flag it. A plausible wrong code is worse than a question.
  3. Write back everything. The sheet, the ticket or the client file gets a note of what was done and when, so the team never redoes it.

The receipt problem is mostly a configuration problem

When we audited our own supplier receipts, the finding was not about AI. Of twenty vendors, one attached a PDF to its email, two sent a "your invoice is ready" notification that needed a portal login, and eleven sent nothing at all because their billing contact was an address nobody read. The software could only fetch what existed in the mailbox.

The highest-leverage fix for a practice's clients is therefore boring: get every supplier's billing email pointed at one address the system reads. Do that and most of the "needs a portal login" bucket becomes the "found it in the inbox" bucket. The automation is the second step; the first is plumbing.

What the team's week looks like afterwards

Monday, the query sheets arrive. The system has already read them and produced a plan per client: these rows are invoices to raise, these receipts were found and filed, these three rows need an answer from the client and the chaser has gone, these two need a bookkeeper's eye. The bookkeeper spends the morning on the two, not the two hundred. Anything sent to a client was drafted by the system and approved by a person. The ledger was touched only after the plan was read.

That is the pattern, and it scales with clients rather than with hours. The accountancy practices page covers what a build like this costs and the compliance detail, and the Xero workflow automation guide goes into the practice-side jobs in more depth.

Dave Crawford, founder of Anco AI
Dave Crawford

Founder, Anco AI. Builds the systems this site talks about, and runs his own business on them.

Fair questions.

No. Those help one business with its own books. A practice's hours are in the work across clients: query sheets, chasing, matching, packs. That layer sits above the ledger software and works whichever one a client uses.

The extraction can be imperfect because nothing is posted on it alone. Vendor, date, total and VAT are read, then matched exactly to a bank line. If the match is not exact, a person decides. Accuracy problems become questions, not errors in the ledger.

No. Business-tier services under contracts that forbid training on the data, with UK or EU hosting where the provider offers it. Nothing is pasted into a consumer chatbot, and the model never holds credentials for the ledger.

Keep reading.

Book a free discovery call.

Whether it's AIOS, consulting, software or automation, we'll map where the time and money are leaking and what would give you the most back. No obligation, you keep the map.

Book a discovery call →