Your management accounts are late again. Finance is waiting on job costs from operations, sales has a different revenue number in the CRM, and somebody is rebuilding the cash forecast in a spreadsheet because the one in the system does not include committed spend.
At some point in that month, someone suggests buying software to automate the reporting pack.
It might help. Automating the pack will make the last step faster, and the last step is genuinely slow. What it will not do is fix information that arrived late, was entered twice, or means different things in different systems. Those problems were all in place before finance touched anything.
That is the part of finance automation that is easy to miss. Better finance often starts somewhere outside finance.
What finance automation usually means
Finance automation means using software to take manual handling out of finance work: capturing supplier invoices without typing them, matching bank transactions automatically, routing approvals without an email chain, producing a reporting pack without rebuilding it by hand every month.
It is worth separating two things sold under the same word. Most of it is rule-based: the work follows a rule you could write down, and software follows that rule faster and more consistently than a person. Some of it is described as artificial intelligence, where the software makes a judgement about something ambiguous, such as which code an unusual invoice belongs to. The first is mature, predictable and usually the better place to begin. The second needs supervision and a view on what happens when it gets it wrong.
Both can be genuinely useful. Neither does anything about where the numbers came from.
The Office for National Statistics gives some sense of how far businesses have actually got. Its July 2026 release found that the proportion of UK businesses with ten or more employees reporting use of at least one AI technology rose from around 12% to around 35% between autumn 2023 and June 2026, while, among businesses reporting AI use, the average number of AI technologies used rose only modestly, from around 1.4 to around 1.6. Adoption appears to be broadening faster than it is deepening. Enabling a tool is one step. Building it into how information actually moves through the business is another.
Finance is the last stop, not the first
Almost nothing in your management accounts starts in the finance department.
It starts when a salesperson agrees a price, when an engineer books time to a job, when a manager approves an order, when someone adds a starter to the payroll, when a delivery gets signed for. By the time any of it reaches finance it has already been created, categorised and moved, usually by people who were not thinking about the month-end when they did it. Finance then reconciles it, corrects it, chases whatever is missing, and assembles the result into something you can read.
Which is why the same complaints keep turning up in businesses that already own perfectly good accounting software. The accounts are late because a job has not been closed. Margin gets argued over because sales and operations describe the same work differently. The cash forecast is approximate because committed spend sits in a purchase order system that does not talk to the ledger, or in nobody's system at all. Someone exports from one system, cleans it in Excel, and imports it into another, every month, and has done for two years.
And then there is the spreadsheet. A department stops trusting the central report and starts keeping its own version. It is quicker. It is closer to the people doing the work. It appears to bridge a gap, and then becomes load-bearing without anyone ever deciding that it should.
Automating the finance end of that chain makes the last stage faster. It does not make the information arrive any earlier, or arrive meaning the same thing twice. Occasionally it makes matters worse, because the manual step you removed was the step where somebody noticed the numbers were wrong.
There is a wider version of the same problem. The Department for Science, Innovation and Technology found in its 2026 business data survey that 86% of UK businesses handle digitised data, but only about a quarter of those that do analyse it to generate new insights or knowledge. Most businesses are not short of data. They are short of information they can act on.
Start with the decision, not the software
The useful question is not which product to buy. It is what you are trying to know or do that you cannot do reliably today.
Work backwards from there. What information would answer it, where does that information start, who enters it, where does it get copied or changed, and where does it go wrong? That takes an afternoon of asking rather than a project, and it usually produces a different answer from working forwards from a demo. Quite often it identifies a process that should be simplified or stopped rather than automated. Occasionally it turns out the report everyone complains about is not actually used for anything.
When you do have candidates, two tests will sort most of them. Can you describe the task as a rule, precisely enough to write down? If you cannot, it is not ready to automate, and automating it will lock in the confusion rather than remove it. And could you switch it off on a Tuesday without an incident? Early automation should be reversible. Edge cases turn up, assumptions change, and a process usually looks slightly different once it is running for real.
What that looks like in practice
Take an illustrative case. A business installs and services equipment. Sales records the contract and pricing in a CRM. Operations schedules the work and records engineer time in a separate system. Finance raises invoices from the accounting package. Every month, someone spends the better part of two days pulling all three together in a spreadsheet so that management can see which customers and which jobs actually make money.
The obvious question is how to automate the management accounts.
The better question is why the information needed for customer and job profitability does not reach finance reliably in the first place.
Once you ask it that way, the answers stop being about reporting software. Perhaps engineer time is recorded weekly rather than daily, so the month never closes cleanly. Perhaps sales and operations use different names for the same job. Perhaps the CRM already holds contract values that nobody has connected to anything. Perhaps two of the three systems can already exchange the data and simply have not been set up to.
Fix those and the monthly spreadsheet gets shorter on its own. Automate the reporting pack without fixing them and you have a faster route to the same unreliable number.
Five ways to fix it, only one of which is buying software
Use what you already have. Many owner-managed businesses use only part of the capability they already pay for. Approval workflows, project costing, recurring billing, tracking categories, reporting features that were part of the package and were never switched on. It is often the cheapest place to start. It is also easy to overlook, because there is no new product attached to it.
Configure it properly. The difference between an accounting system that produces useful margin reporting and one that does not is often the chart of accounts, the tracking categories, and whether people apply them consistently. That is a design decision and a discipline question, not a purchase.
Buy something. Where a process is standard, established software is usually the right answer, and the case for it is strong. Somebody else carries the development cost, the security patching, the compliance updates and the roadmap. Payroll, expenses, invoice capture and card spend are all well served, and there is rarely a good reason to build those capabilities from scratch. Off-the-shelf gets expensive in a different way when it accumulates: six subscriptions with overlapping functions, per-user charges that grow faster than headcount, and staff time spent maintaining workarounds around a product that nearly fits.
Connect what you have. Often each system does its own job perfectly well and the failure is in the gaps between them. Connecting them so that information passes without being rekeyed addresses the actual defect and keeps what already works. It is an option worth testing hard because it can produce a strong return without replacing systems that already do their jobs well.
Build something narrow. Bespoke does not have to mean a new finance system, and for a business of this size it usually should not. More often it means a small layer that moves information between systems that stay exactly where they are: the ledger remains the ledger, the CRM remains the CRM, jobs stay in the operational system, and something in the middle applies your rules, validates what comes through, flags the exceptions and prepares the one output nobody can get any other way. That is a modest piece of work, and it can remove a weekly Excel bridge permanently.
Be clear-eyed about what building means even at that scale. You take on the maintenance, the dependency on whoever wrote it, and the risk that it ages badly. The comparison that matters is not the build fee against a licence fee. It is the total cost over about five years, including maintenance and eventual replacement, against the cost of changing the process so that standard software fits.
For many businesses of this size, the honest answer is a mixture: core systems kept and configured properly, standard software for standard work, the parts connected, and a narrow piece of bespoke only where there is a specific gap worth owning.
What it costs, and what counts as a return
The costs that get quoted are licences, implementation and development. The costs that decide whether it was worth doing are usually elsewhere: configuration, cleaning the data before anything can move, the time of the people who have to explain how the process really works, training, the exceptions the automation cannot handle, and maintenance. Two questions are worth asking any supplier. What does annual maintenance run at as a proportion of the build cost? And what happens if the person who wrote this is not available?
On the other side, the distinction that matters most is between hours released and cash saved.
Suppose automation gives you back thirty hours a month in finance. If nobody leaves, no planned hire is avoided, and the time is absorbed rather than redirected, you have bought capacity. That may be exactly what you wanted, particularly if the alternative was another salary. But it is capacity, and it should be described as capacity rather than converted into a saving that never appears in the accounts.
Some benefits are genuinely measurable: an avoided hire, fewer agency hours, lower processing cost, fewer corrections, better debtor days, administrative headcount that stops growing in line with turnover. Others are real and should simply be stated rather than priced: better visibility, quicker decisions, stronger control, less dependence on one person who knows how the spreadsheet works.
A business case that puts a pound sign on every soft benefit is usually a sales document. The more useful question is narrower. What will be true in twelve months that is not true now, and how would we know?
Building for the business you might become
Two expensive mistakes are available here.
The first is installing something built for a business ten times your size. A £3m owner-managed business does not need the systems of a £100m group, and the implementation will absorb management attention the business needs somewhere else.
The second is choosing the cheap answer you will have to throw away at £6m. The second migration always arrives at a worse moment than the first, and costs more than designing sensibly once.
Which risk applies depends on what you actually expect. Another entity. An acquisition. Materially more transactions. More people, and managers who need to be accountable for their own numbers. Another location. A lender or investor who will want reporting you do not currently produce. Where those are credible within two or three years, they should shape the decision now, even if nothing gets bought yet. Where they are ambitions rather than plans, they should not.
Scalability does not mean buying the biggest system. It means having somewhere sensible to go next.
What should stay human
Automation is good at work that is repetitive, describable as a rule, and currently being done by somebody retyping it. It is not a substitute for financial judgement.
Reading what a margin movement actually means. Deciding which numbers matter this quarter. Challenging a forecast that looks optimistic. Pricing. Investment decisions. The exceptions that do not fit the rule. Being accountable for the advice given to an owner or a board. A business that automates well ends up with people spending more time on that, and less time assembling the pack.
Where this leaves you
If your reporting is late, inconsistent or hard to trust, the automation question is worth asking. It is just worth asking before you choose the software rather than after.
Sometimes the answer is a purchase. Often it is configuring what you already own, connecting two systems that should have been connected years ago, or simplifying a process so it stops needing a workaround. Sometimes it is to do nothing yet, because the process is still changing and automating it now would only make the confusion faster.
Before buying another finance tool, it is worth being clear about the problem you are actually solving. If that is not obvious from where you sit, that is exactly the point of looking properly before committing to software.
The Pelican Finance Health Check looks at cash visibility, reporting quality, forecasting, finance control and automation opportunity together, as one picture rather than five separate questions. Where systems or processes are getting in the way of useful financial information, it identifies what is actually wrong and what is worth fixing first. It is a fixed-fee review, with no assumption that you need anything more.