Automation is quick at coding and matching. It cannot tell you that the coding was wrong.

A bank feed hands the software a date, an amount and a payee. From that it proposes a category, and the proposal is usually sensible.

Then there are the ones that look easy. A single payment to HMRC might be VAT, PAYE, Self Assessment, interest or a penalty. The software sees one payee and one amount.

Or a laptop bought on the company card. Office equipment is the obvious code. Whether it was wholly for the business, partly private, or bought for someone outside the business, the feed has no way of knowing.

So the category is right and the treatment is still wrong. Nothing on the screen looks out of place, because nothing is out of place as far as the tool can tell.

That judgement sits with someone who knows how the business runs. It is why we read bank statements and ask what a payment was for before we let a rule decide.

Pattern learning is the useful part and the risky part of the same feature.

Once a rule is set, it applies itself. Every future payment to that supplier lands in the same place, month after month, without anyone looking at it again.

A typing error damages one line. A bad rule damages every line that matches it, for as long as nobody checks.

By the time we see a file, the same misclassification can sit across dozens of entries. All consistent, all wrong, all reconciled.

Tidy output, thin trail

Reports out of these tools look finished. That tells you very little about what happened underneath them.

Categories get changed by hand. Totals get exported into a spreadsheet and edited there. Figures get carried from one system into another and typed in again.

The digital trail breaks in places the summary never shows. When a funder, a lender or HMRC asks how a figure was reached, the summary is no help.

We would rather see the working.

The most expensive errors we come across are missing entries, and there is nothing for a tool to find.

During a first bookkeeping clean-up at an owner-managed trading business, we reconciled the sales ledger against the delivery records. It is a dull job and it is the one that pays.

Goods worth £20,000 had left the premises and had never been invoiced. No transaction existed, so there was nothing to categorise, match or flag.

The ledger was internally consistent. It was simply short by twenty thousand pounds of sales, and every report drawn from it inherited that.

We raised the invoices, they were collected, and invoicing moved into the month-end routine so the gap could not open again.

This is the real limit behind the question. Automation improves what is in front of it. What never arrived stays invisible, however good the model is.

We start by asking how the file was produced and who touched it.

After that we build an exception list rather than reviewing everything. The list is short and it is deliberately awkward:

• High-value purchases and anything that might be capital.
• Suppliers appearing for the first time.
• Payments with any private-use element.
• Payments to related parties.
• Manual overrides and unusual descriptions.
• Anything dated close to the period end.

Then we trace a sample of those entries back to the document behind them. An invoice, a contract, a delivery note. Not another report.

Where something is wrong, we correct the underlying transaction. Adjusting the final total leaves the bad entry sitting in the ledger, and it comes back next period wearing the same clothes.

None of this is complicated. It takes time, which is the reason it gets skipped, and the reason we cap new clients at four a month.

Automation belongs at the capture end, with a person on the treatment.

It reads data off bills accurately, matches payments to invoices, spots duplicates, and takes the repetition out of reconciliation. That is real time saved, and we take it.

What stays with us is judgement. Private use. Capital against repairs. What a mixed HMRC payment actually settled. Whether the sales ledger agrees with what physically went out of the door.

Run in that order, the tools make a clean finance function cheaper to keep clean. Run in the other order, they produce management information nobody should act on, faster than before.

That is the whole of our data-quality principle. Records first, reporting on top, decisions after that. It is how we run the finance function for clients, and it is what the first ninety days are spent establishing before any reporting is promised.