CFO 2.0 explores how automation is transforming the role of finance leaders, highlighting the future of CFOs and the impact of technology in finance.
The finance leader's job has changed in a way that is easy to describe and hard to deliver. The expectation is now for forward looking judgement rather than accurate reporting of the past, and the compliance and control responsibilities that used to define the role have not gone anywhere.
Something has to give, and the only thing that can is the mechanical part of the work. Which is why automation, a topic that sounds like a systems concern, has become the central practical question in how a finance function is run.
This article covers what actually automates well, what does not, how to sequence it, and what the finance leader's job becomes once it is done.
Start with why the pressure exists, because it explains why effort alone cannot resolve it.
The scope of the finance function has expanded steadily. Statutory reporting, tax, treasury, business partnering, systems, analytics, and increasingly sustainability and supply chain disclosure.
Headcount has not grown in proportion, and in many businesses has not grown at all.
Meanwhile the transactional load rises with revenue, so the base workload increases even before anything is added.
The usual response is to work harder, which is not a strategy and does not scale. The alternative is to systematically remove the transactional work, which is what automation actually means in this context.
The candidates share a set of characteristics and it is worth being precise about them.
They are rules based, meaning the correct outcome follows from the inputs without judgement.
They are repetitive, so the effort of automating is repaid many times.
They are high volume, since the return scales with frequency.
And the exceptions are identifiable, meaning the process can route what it cannot handle to a person rather than guessing.
Accounts payable matching, bank reconciliation, expense processing, recurring journals, intercompany eliminations, standard report production and approval routing all meet those tests.
Accounts payable is where most finance functions start, and for good reason.
The volume is high, the rules are clear, and the manual effort is visible enough that everybody agrees it is a problem.
Capture handles the arrival of the invoice, extracting the data rather than having somebody type it.
Matching compares the invoice against the purchase order and the receipt, and where the three agree within tolerance the transaction proceeds without human involvement.
Exceptions route to a person, which is the important part, because the value of automation is not that everything is handled automatically but that people only see what actually needs them.
And approval routes by rule rather than by email, which produces both a faster cycle and an audit trail that exists by default.
Bank reconciliation is the second most common candidate and frequently the fastest to deliver.
Automated matching handles the transactions that correspond cleanly, which in most businesses is the large majority, leaving a short exception list.
The time saved is immediate and measurable, which makes it a good early project for building internal confidence in the wider programme.
Beyond reconciliation, the close itself contains a substantial amount of automatable work. Recurring journals, accruals and prepayments that follow a rule, depreciation, and intercompany eliminations.
Close management capability moves the checklist into the system, tracks who has done what, and holds the reconciliation evidence against the account rather than in somebody's folder.
Report production consumes a surprising proportion of finance time and it is almost entirely automatable.
The pattern to eliminate is the monthly rebuild, where somebody exports data into a spreadsheet, applies formatting and formulas, and produces a pack that is obsolete the moment anything changes.
Built in the system, the same pack refreshes against live data, which means it is available whenever anybody wants it rather than on a schedule.
That changes what reporting is for. A pack that arrives monthly is a review artefact. A view that is always current is a management tool.
The commentary still requires a person, and it should, because that is the part that turns numbers into information.
Being clear about the limits prevents both wasted effort and the disappointment that follows an overpromised programme.
Judgement does not automate. Provisions, estimates, the treatment of anything unusual, all require somebody who understands the context and can be accountable for the position.
Interpretation does not automate. A variance table can be produced automatically. Explaining why the variance occurred and what should be done requires knowing what happened in the business.
Relationships do not automate. Collections, supplier negotiation and business partnering are human activities where the system supports rather than replaces.
And exception handling does not automate by definition, since an exception is precisely the case the rules did not cover.
The most common failure in a finance automation programme is automating something that should not exist.
Many manual processes are workarounds for a system limitation, a data problem or a decision nobody made. Automating them entrenches the workaround and makes it harder to remove later.
Before automating anything, ask why the process exists and whether it would exist if you were designing the function today.
A surprising proportion of candidates disappear at that question, which is a better outcome than automating them.
The remainder should be simplified before being automated, since automating a convoluted process produces a convoluted automation that nobody can maintain.
Automation depends on data being reliable and consistently structured, which is why it fails in fragmented environments.
Where finance data sits in one system and operational data in another, any automation spanning the two requires an integration, and integrations fail quietly and need owners.
Where the same entity exists in multiple systems with different identifiers, matching is unreliable and the exception rate stays high enough to undermine the benefit.
Where dimensional coding is inconsistent, automated allocation and reporting produce results nobody trusts.
Which means the foundation work is frequently the first phase, and businesses that skip it produce automation that works in demonstration and generates exceptions in production.
Everything cannot happen at once and the order determines whether anything gets finished.
Start with the highest volume, most rules based process, which is usually accounts payable or bank reconciliation, because the return is largest and most visible.
Take one thing and finish it rather than starting three, since a completed automation changes what people believe is possible and three half finished ones do the opposite.
Measure the result, because the second project is considerably easier to fund when the first can be shown to have worked.
And choose by hours saved rather than by technical interest, since the unglamorous fix that returns four hours a month is worth more than the sophisticated one that saves an hour a quarter.
Automation changes the control environment rather than weakening it, and the change needs to be deliberate.
Rules based processing is more consistent than manual processing, which means fewer random errors and a higher consequence when a rule is wrong, since it applies to everything.
Which makes the review of the rules themselves the important control, rather than the review of individual transactions.
Exception rates are a control in their own right. A rate that suddenly changes indicates that something upstream has changed, and monitoring it catches problems earlier than transaction testing would.
And segregation of duties still applies. The person who configures a rule should not be the only person who reviews its output.
Any discussion of finance automation now arrives at artificial intelligence, and it is worth being precise rather than enthusiastic.
The applications that are genuinely useful today are narrow. Extracting data from documents, suggesting a coding based on history, flagging a transaction that looks unlike its peers, drafting a first version of commentary that a person then corrects.
What those have in common is that a person checks the output, and the cost of an error is a correction rather than a misstatement.
Where it does not belong is anywhere the output is relied on without review, because a system that is usually right and occasionally confidently wrong is considerably more dangerous in an accounting context than one that fails visibly.
The practical position is to use it where it drafts and a person approves, and to be sceptical of anything that proposes removing the person entirely from a process with financial consequence.
This is the question everybody has and few programmes address directly.
In most finance functions the honest answer is that nobody loses their job and everybody's job changes, because the function was already under resourced for what it was being asked to do.
The work that disappears is the work people least enjoy, which is the repetitive processing, and the work that grows is analysis and business partnering.
That transition is not automatic. Somebody who has spent years on transaction processing needs support to move into analysis, and pretending the transition is trivial is how automation programmes generate resistance.
Where a role genuinely reduces, say so early and specifically, because the person concerned works it out well before you tell them.
Freed capacity only produces value if the team can use it, which is a capability question rather than a time question.
Analysis is a different skill from processing. It requires knowing what question to ask, how to structure an investigation, and how to present a conclusion somebody will act on.
Invest in that deliberately rather than assuming it will emerge. Structured time with the business, exposure to how decisions get made, and practice presenting to people who will challenge the conclusion.
Systems capability matters too, since an analyst who can build their own saved search is considerably more productive than one who has to request a report.
And protect the freed time explicitly, because routine work expands to fill whatever space it is given.
Automation programmes are easy to claim success for and worth measuring against something observable.
Days to close, tracked over months, which is the most direct measure of whether the mechanical work has actually reduced.
Transaction volume per finance employee, which shows whether the function is scaling without headcount.
Exception rate and its trend, since a rising rate means something upstream has changed and the automation is degrading.
And the proportion of finance time spent on analysis rather than processing, which is the outcome everything else exists to produce and the measure nobody tracks.
The end state is worth describing, because it is the reason for the programme.
Less time producing numbers and more time explaining what they mean, which is the shift from reporting to influence.
A rolling forecast maintained continuously rather than a budget built annually, which changes finance from a scorekeeper into a participant in decisions.
Time with operational leaders, helping them understand the financial consequences of what they are doing, which is where most of the available value sits.
And a function that can absorb a new requirement without a crisis, because it is not already operating at capacity.
The obvious objection is that a finance function under pressure has no room to improve itself, which is true and is why so little changes.
The way through is to pick something small and finish it. Not a transformation programme, one process that is currently manual and could stop being manual within a month.
What that buys is hours, and hours are what the next improvement needs. Two or three of these compound into meaningful capacity within a quarter.
The alternative approach, waiting for a quiet period to start something large, fails reliably because the quiet period does not arrive.
And where the constraint is genuinely absolute, moving the transactional work outside is the other route to creating the same capacity.
The shift in the finance leader's role is only sustainable if the mechanical part of the work shrinks, and automation is the mechanism rather than the objective.
The practical starting point is to spend a week noting where finance time actually goes, at task level, because most functions have never measured it and the answer is usually surprising.
Then pick the largest rules based item on that list and finish it.
Our pieces on the challenges facing finance leaders and overcoming forecasting challenges cover the surrounding ground, and our guidance for chief financial officers covers what the platform makes possible.
If you would like help identifying where automation would pay in your own finance function, get in touch.
