Automating routine work with AI: six bookkeeping tasks and the line where AI stops helping

A bookkeeping outsourcing company split its own routine into six blocks and marked which ones it considered simple. Moving sums between spreadsheets. Issuing invoices from emails and chats, with a trip into the accounting system. Answering common questions. Payment orders. Shipping documents. Checking tax calculations before filing.

The project reached estimation and never became development, so this is a breakdown of a brief, not a case study. It shows the place where automation stops working, and that place is not technical.

Two kinds of work that look identical from outside

The first five blocks are moving and preparing. The work repeats, the data is machine readable, the result is verifiable: the document is either correct or it is not.

The difficulty here is access, not the model. No model removes it. Can the system read the mailbox and the chats? Does the accounting system allow writes or only reads? Who inside the company is authorised to issue those credentials? Until those questions have answers, discussing the interface is premature, which is why we start such projects with an access check and not with a design.

The sixth block is built differently even though it looks the same. Checking tax calculations before filing requires a willingness to sign off on the result, and the calculations there are secondary. The system will find a discrepancy. It cannot sign.

Check what the task competes with

The accounting system has a built in checking mechanism, and the client considered it weak. That detail matters for the estimate and people forget it constantly. You are competing with an existing tool and not with manual labour, so the difference has to be visible or the project will not pay for itself.

Ask about this on the first call. «We do it by hand» and «there is a function, it just works badly» lead to different projects. And to different budgets.

One sentence removes most of the fear

The main takeaway from preparing that conversation sat outside technology. When a non technical client hears the architecture explained in jargon, they do not relax. They tense up.

What works is different: the system prepares a draft, a human makes the decision. The sentence is honest, and it removes the biggest fear, that a machine will start filing documents with the tax authority on its own. It also sets a requirement for the interface. A person has to see what the suggestion was based on and correct it in one step, because automation where the draft cannot be fixed quickly turns into extra work and people go back to spreadsheets.

Where automation hits something other than technology

We met a similar boundary in a system for a college. Intake and processing automated easily. Anything involving judgement did not: changing a status, recording a reason for refusal, assessing a disputed case all require a person. The bottleneck there is the discipline of keeping data current, not the speed of entering it. Speed was fine.

That gives a rule I now check before starting. If a process runs irregularly today and depends on one employee’s memory, automation will not save it. The process has to exist first, and only then can it be made faster.

How we propose to approach it

One process at a time, with a measurable frequency: how often it repeats per week and how long it takes now. An access check before development, as a small paid step that answers whether data can be read and a document produced inside the client’s real system, which we describe in the article on spikes. A success criterion written down in advance, for example the share of documents a person accepts without edits. Without that number, two months later nobody can tell whether things improved or merely changed.

And an honest conversation about who is accountable for a mistake. That is a design requirement and not legal formality, because the answer determines how many manual confirmations the system needs and what the audit log looks like.

What I do not know

We never built a working system from this brief. How much time it would really have saved, I cannot say. Everything above is about framing the task, and measuring the benefit is separate work that we did not do here.

Now the uncomfortable question worth asking yourself before calling a vendor. How many times a week does the process you want to automate repeat, and how many minutes does one repetition take? Without those two numbers a conversation about automation is a conversation about feelings. With them, send them over and that is enough for us to say whether the thing is worth building.